Subject: Sieve Readability Suggestions

From: Chris Newman <[email-masked]>
Date: Fri, 25 Apr 1997 11:16:32 -0700 (PDT)

I finally made time to read the sieve document carefully.  In general, I
think the language is in good shape.  I've got a few suggestions which I
think may improve sieve's human readability without changing the
complexity of parsing much. It's not bad as it is, but these might make it
slightly better.

(1) Comments

I suggest using "--" instead of "#" as the comment introducer.  "--" is
what Applescript uses, and is more likely to make sense to the average
human (rather than a programmer) IMHO.

(2) The "header" test

I'd like it if the <header-name-list> and the <key-list> items could be
either a list or a single quoted string.  Thus you would get:

if header "Subject" contains "$$" then
    toss
endif

or

if header ("Subject" "From") contains "B1FF" then
    toss
endif

(3) The "header" -nocase arguments

I think nocase should be the default with -case as the modifier.  So you'd
get "contains", "is", "matches", "contains-case", "is-case",
"matches-case".  This makes it more readable, IMHO, and makes the
more common case easier to type.

(4) Trailing ";"

The grammar seems to require a trailing ";" after every command
(including an endif).  I'm starting to think it would be better to simply
have CRLF terminate a command as many of your examples do (and use "\"
CRLF to fold a line).

(5) Optional ","

I'm uncomfortable with "," being optional in any-of and all-of lists.  I
think it should either be required or unnecessary.

(6) Normal action

How about calling this "keep"?

if size under 1M then
    keep
else
    toss
endif

(7) Message introducer

You currently use "message" to introduce a block of text.  I'll point out
that this isn't really a message, as it's lacking headers.  I suggest
using "text:" instead of "message".

               reply text:
               You are not one of the people I regularly correspond with.
               I have deleted your message due to the large volume of
               email I regularly receive.  If you feel that you need to
               speak with me directly, and cannot find your answer in my
               web pages, please send mail with the word "URGENT" in the
               subject line.  Thank you for your time.
               .
               endif

---

From: Tim Showalter <[email-masked]>
Date: Fri, 25 Apr 1997 15:42:25 -0400 (EDT)

> human (rather than a programmer) IMHO.

I can see this, but I'd like a second opinion.  It seems a little strange to
me.

> if header "Subject" contains "$$" then

This is probably a good idea.

> more common case easier to type.

Ok, this makes sense.
 
> have CRLF terminate a command as many of your examples do (and use "\"

I'll fix the examples to reflect what's in the draft.  I'm not sure I like
this change, but it might clean things up.  I'd like a second opinion.

I would drop ; from the grammar entirely if this is the case, i.e., no more
than one command on a line.

> think it should either be required or unnecessary.

It should be required; I'll make sure the next draft reflects this.

> How about calling this "keep"?

Fine with me.

> using "text:" instead of "message".

Ok, this is an improvement.

-- 
                                           Tim Showalter [email-masked]

---

From: "David L. Miller" <[email-masked]>
Date: Fri, 25 Apr 1997 16:23:15 -0700 (PDT)

> I can see this, but I'd like a second opinion.  It seems a little strange to

Both are used in other languages, so there is a precedent for either
one.  I can see the argument for matching AppleScript, since there are
some otherwise novice potential users already familiar with it.  Do
any other languages targeted to novices use "#"?

> than one command on a line.

Single command/line is fine with me.  I don't think multiple
commands/line serve any particularly useful purpose in sieve... 

--DLM

---

From: [email-masked]
Date: 26 Apr 1997 15:54:55 -0000

>> > human (rather than a programmer) IMHO.

Only to those familier with applescript.

>> I can see this, but I'd like a second opinion.  It seems a little strange
>> to me.

>any other languages targeted to novices use "#"?

I'm not sure worrying about the familiarity of '#' to novices is a big
deal.  It's short and to the point and it's in wide use on at least one
platform (:-).  For users that are 'pathologically-novice' a GUI interface
is more in order anyway.
-- 
thx,
kjj

---

From: Ned Freed <[email-masked]>
Date: Tue, 29 Apr 1997 19:18:38 -0700 (PDT)

> I can see this, but I'd like a second opinion.  It seems a little strange to

"--" becomes problematic the minute you add arithmetic operators to the
language. Let's not make Ada's mistake here, OK?

I'm not wild about "#" but the only alternative I see is "!", which might
interfere with future operator extensions. So "#" really seems like the best
choice for now.

> this change, but it might clean things up.  I'd like a second opinion.

I don't like this change either -- we're making the mistake Praxis (and others)
made here. 

> Ok, this is an improvement.

I finally figured out why I dislike the use of SMTP-style message text: It is
because it makes the grammar context-sensitive: "message" (or "text:") has to
kick the lexer into a special state. I think this is fairly problematic
behavior at best. What happens when we want to extend the language by adding
some other construct that requires message text as an argument.

I think we really need to bite the bullet here and go back to some sort of
consistent quoting scheme. I'd recommend using C style string constants,
possibly with the extension of alloing a string to cross line boundaries.

				Ned

---

From: Tim Showalter <[email-masked]>
Date: Tue, 29 Apr 1997 22:52:55 -0400 (EDT)

I'm going to agree with Ned again because, uh, well, I like what's in the
draft.  I'll go with whatever consensus is, of course.

> interfere with future operator extensions. So "#" really seems like the best

I like this argument.  of course, I never used AppleScript and spend time
writing shell scripts.

> I don't like this change either -- we're making the mistake Praxis (and others)

I'm not familiar with Praxis.

The more I think about this change, the less I like it.

> possibly with the extension of alloing a string to cross line boundaries.

I agree with this; it'll make indentation prettier, but I can see it as
being a problem.  I opted for SMTP strings in part because mail and some
similar programs cope with them; while this is an awkward solution, it makes
the parser easier.  But if the theory is that novices won't write many
scripts, I can cope with C-style strings.  (The "reply" feature is one
that probably should be kind of difficult to use.)  If we don't use
backslashes above, we can use backslashes here, although I'm partial to
ANSI C-style string composition ("this is one" " long string").

---

From: Ned Freed <[email-masked]>
Date: Wed, 30 Apr 1997 08:42:14 -0700 (PDT)

> ANSI C-style string composition ("this is one" " long string").

The ANSI C way seems reasonable enough to me...

However, there is an alternative if you want to keep the SMTP style stuff.
Specifically, instead of making the message send operator special, you add
a lexcical component to the language that is equivalent to a string. For
example:

blah blah blah message text The text of the message starts
after the text token and continues until an SMTP-style end of string is
seen. The entire text object is lexically equivalent to having the same
thing in quotes; it does not imply any sort of operation. Here text is being
used as an argument to the message operator.
..
blah blah blah

I would also recommend that you make the following legal:

blah blah blah message "this is a one liner" blah blah blah

This way we could add, say, a mime_message operator later on:

blah blah blah mime_message text "Content-type: image/gif
Content-transfer-encoding: base64

--base64 encoded stuff here--
..
blah blah blah

				Ned

---

From: Chris Newman <[email-masked]>
Date: Wed, 30 Apr 1997 09:20:44 -0700 (PDT)

> language. Let's not make Ada's mistake here, OK?

Given this point, I withdraw the suggestion.

---

From: Rob Earhart <[email-masked]>
Date: Wed, 30 Apr 1997 13:18:06 -0400 (EDT)

> some other construct that requires message text as an argument.

  The grammar's still regular - when the lexer sees a "message" or
"text:" token, it switches states until it sees the end of the
SMTP-style message text; this is well within the capabilities of a
DFA.

  (By the same argument, you're against "'s, yes?  Because when a
lexer sees a " mark, it must enter a special state in which characters
are processed until a closing unescaped "... this is really no
different.)

> possibly with the extension of alloing a string to cross line boundaries.

  The problem with multiline strings is that either you wind up with
lots of backslashes at the ends of lines (which're a pain to keep
consistant when one reworks one's linebreaks), or you create a
situation in which there really isn't anything to keep a dropped
end-of-string character from causing your string to chew up far more
data than it really should, causing syntax errors far removed from the
source of the problem.

  I don't think we want lots of backslashes, and I think that a . on a
line by itself stands out much better than a " marks; much as I hate
special casing lexers, I think it's better to have two ways to quote
strings.

  (OTOH, with any non-backslash mechanism, you run the risk that it'll
still parse, potentially mailing pieces of your script and automated
responses to people who really shouldn't see it...)

  )Rob

---

From: Rob Earhart <[email-masked]>
Date: Wed, 30 Apr 1997 13:19:44 -0400 (EDT)

> have CRLF terminate a command as many of your examples do (and use "\"

  Do we really want to impose any particular line terminator on
scripts?

  )Rob

---

From: Chris Newman <[email-masked]>
Date: Wed, 30 Apr 1997 10:32:40 -0700 (PDT)

>   Do we really want to impose any particular line terminator on

Yes.  There should be a single canonical format for scripts so they can be
communicated from client to server without ambiguity.

---

From: Tim Showalter <[email-masked]>
Date: Wed, 30 Apr 1997 13:57:30 -0400 (EDT)

> communicated from client to server without ambiguity.

Hey, Rob, did you mean the CR/LF/CRLF thing, or are you worried about how
the script is encoded?

---

From: Rob Earhart <[email-masked]>
Date: Wed, 30 Apr 1997 14:08:27 -0400 (EDT)

> communicated from client to server without ambiguity.

  It's an interesting idea.

  Currently, CR and LF are treated as "whitespace" - if they're
present, they're only there *solely* for readability and comment
termination.  Your viewer could rewrap the lines and comments and come
up with something you could edit on any given platform.

  Why not go further?

  For instance, should people use tabs or spaces for indentation?  Or
a combination?  Should indentation be meaningful (if you don't think
so, look at the Python addicts in the CS community - I think they're
wrong, but they have some good points)?

  Maybe we should have one true indentation style - one tab per level,
no spaces.  Let the editor set tab stops where it wants...

  How about line length limits?  If we really want scripts to be
editable by all sorts of non-specialized editors, maybe we should
suggest (or impose) an 80-column limit on lines...

  Just some ideas - I'm far from wedded to any of these, but I think
they make about as much sense as requiring that lines end with CRLFs.

  (I'd argue that if we *really* want a single canonical format, we
should think about what a abstract syntax tree for a program in this
language should look like, write up the canonical way of encoding
those trees as text, and require that all programs be in that form
when returned from the server (since we're worried about
interchangeability, servers should be strict in what they send and
forgiving in what they accept, right?  Or should it be strict on both
ends?).  Permitting things like "one or more spaces" inbetween tokens
hardly leads to a single canonical form... (interestingly enough, the
grammar currently says that WSP is exactly one whitespace; I suspect
this will be changed :-) )

  )Rob