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.
Are you aware of any languages that didn't have some changes made to their
syntax? Why should we be any different?
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.
Scheme's model is simply (commmand stuff...), where "stuff" is atoms,
lists, strings, and numbers. It's fairly simple, fairly clean, not
exactly easy to read or write (although I still don't think it's as hard
as people make it out to be, and I think it's *much* easier to write
parsers and generators which read and write it), but it's general enough
and flexible enough that extensions can be done simply by adding commands.
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.
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.
Incidentally: what happens when there're two extensions out there which
define new syntax elements which are mutually incompatible? 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...
)Rob