ietf-mta-filters
[Top] [All Lists]

Re: Sieve extensions

1998-01-20 10:38:18
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
Tcl has a quoting syntax; everything else is chaos and eval rules.  Tcl is,
uh, an interesting case considering the "syntax" of the language.

  I think the idea that control structures can be done as commands is
reasonable, though.

Scheme has had changes to it over the years; they're up to the Revised
Revised Revised Revised Report on Scheme.  It also has a macro facility.

  The Scheme semantics have changed, and I expect that the Sieve
semantics will change; this doesn't affect syntax.  The macro facility
is an extension, not part of the base spec.

Right now, the only control structure in Sieve is if, and changing if to
match a command means commands can take blocks, and that commands have to
end with ; so stupid interpreters can parse them.

That's
if = "if" WSP test WSP block [WSP "else" WSP block] [WSP];"

and that those have to be blocks, not commands.

  Or you can do it the C way:

  if = "if" WSP test WSP block [WSP "else" WSP block]

  Syntactically, a block terminates a command, and else is a new
command (this can be parsed by a parser which expects a block to
terminate a command, even if the interpreter will lose if it tries to
evaluate it).  Semantically, else only makes sense right after an if.
I can't think of a single control structure from any language that
*doesn't* work in this model (although C's "for" loops are a stretch :-)

  No.  I'm asking for syntax changes to be banned so that old parsers have
a *prayer* of figuring things out.

I'm not sure what this buys you other than subtly different error
messages.  It's unlikey that users who would write their own filters
wouldn't be able to understand "this requires an extension" in the
documentation.

  Ah.  The idea is that if a script contains extensions and extension
tests, it's *possible* to write a script which works with older
parsers, as long as the syntax doesn't change.

  It's highly possible that people will write scripts which require
certain extensions, without using extension tests, forcing sieve
implementors to implement some set of common extensions.  OTOH, this
can happen anyway - it's simply a question of whether you'll have to
go in and muck with your parser or not to deal with them.

  With extensions affecting language syntax, implementors must
incorporate extensions into their parsers; this isn't pretty even with
compile-time extensions, and if you want dynamic plugins (something I
don't think should be ruled out), it's *very* difficult to parse a
dynamic syntax, whereas if extensions are not allowed to affect
syntax, dynamicly plugging them in as extra commands is trivial.

  And lastly, it'd be nice to be able to do *some* checking of a
script without knowing exactly which extensions the final script
interpreter has available; if extensions are allowed to modify syntax,
one can not assume anything about the script without complete
knowledge of every extension in use, whereas without syntax
modification, many common errors ("You forgot a '{'") can be caught
immediately.

  )Rob

<Prev in Thread] Current Thread [Next in Thread>