Date: Mon, 19 Jan 1998 08:46:32 -0500 (EST)
From: Rob Earhart <rob(_at_)andrew(_dot_)cmu(_dot_)edu>
On 18 Jan 1998, Tim Showalter wrote:
You are proposing one or more of
* prohibiting future extensions from doing anything to change the grammar
* the addition of macros
Which one?
Prohibiting future extensions from doing anything to change the grammar.
I don't think it's a horrible limitation if the fundamental grammar is
reasonably flexible.
Tcl and Scheme come to mind (although one could argue that Scheme's
learned from all the mistakes made in various LISPs). Tcl, for all its
grossness, hasn't changed its syntax (AFAIK). It's changed its semantics
quite a bit, but the syntax has been the same, and extensions don't mess
with that syntax.
Tcl has a quoting syntax; everything else is chaos and eval rules. Tcl is,
uh, an interesting case considering the "syntax" of the language.
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.
As an example: one common thing to both languages is the ability to pass
a block of code to some command; this means that Tcl's and Scheme's loops
aren't actually syntax elements, they're just commands, like everything
else. Adding this notion to Sieve would make adding structures such as
loops, exceptions, functions, and macros in the future trivial, without
changing the language's syntax.
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.
Other languages have changes to their syntax. Many have macro facilities
for this purpose, some cleaner than others. You're asking for this to be
banned forevermore in Sieve in the interest of having old parsers be able
to give subtly different error messages.
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.
Incidentally: what happens when there're two extensions out there which
define new syntax elements which are mutually incompatible?
There's no way to work around this. We have to establish some procedure
for extensions and hope that the peer review is clever enough to note a
direct conflict.
And you have a single script interpreter which needs to understand
scripts which use one or the other? If you allow extensions to define
new syntax, I'll bet that this'll happen...
If you allow the syntax to ever be changed, it's equally likely.
(Including definition of new commands.)
Actually, I think that if we don't allow some extension, including
arbitrary additions, someone else will probably it for us. In fact, if
HTML is any like this, we have no choice in the matter.
--
Tim Showalter
tjs+(_at_)andrew(_dot_)cmu(_dot_)edu