[Top] [All Lists]

Re: Sieve extensions

1998-01-18 22:20:14
  By "rigid", I assume you mean, "regular, such that the syntactic
rules are fairly simple, and there aren't any exceptions"?

No, by "rigid" I mean that there's some small set of syntatic constructs in the
language that provide the only possible extension facilities. The one proposal
I've seen on the list certainly falls into this category -- extensions are done
by adding things that look like functions, even when the semantics being
expressed would look a lot better as additional statement forms. 

In fact I see such things as irregular rather than regular. Having a language
where some forms of statements are "built in" and hence are formatted as
readily recognizable statements and others are "extensions" and have to appear
as functions (or expressions or what have you) is pretty irregular in my book.

This probably would not matter if the core lanugage had a complete set of
"statements" in it. But it doesn't, and shouldn't, because we need to KISS.
However, the limits of the core lanuage have considerable effect on how we do
handle extensions. I do not want to get stuck with a language where assignments
and loops have to end up looking like function calls.

  Actually, that's one of the big arguments in favor of having a
regular syntax.  A regular syntax doesn't imply that it's less
reader-friendly; it means that there's an abstract syntax for things
like "command" and "expression" which all extensions have to obey.

A fixed extension mechanism may be syntactically regular, but no more so than a
more general extension mechanism if extensions done with the latter are done
right. Nobody is arguing for poor or difficult to parse syntax, so this is
basically nothing but a strawman on your part.

  Historically, I can't think of a single language whose syntax had
lots of exceptions which didn't turn out to either be a miserable flop
for programming (the unix shells, most noteable csh, are a pretty good
example of the phenomenon), or which greatly cleaned up its syntax as
it evolved (perl's a good example).

This is not a reading of history I agree with.  The fact of the matter is that
I see languages all over the place that are riddled with screwy syntax rules,
are astonishingly difficult to parse, and yet are extremely popular and
enduring. FORTRAN is certainly a good example of such a language -- take a look
at a full FORTRAN parser sometime (or better still, try and write one). Or try
COBOL. Or how about ASN.1-1988, where you get to invent new BNF for the
language any time you want? (This doesn't really count as an extension
mechanism, however, since for all its syntactic flexibility ASN.1-1988 isn't
truly extensible. It's all the pain and none of the gain.)

And if you want something _really_ gross, take a look at the shell language
behind the ALL-IN-1 Office Automation System. Despite Digital's best efforts to
abandon it or kill it, it still accounts for millions of user seats and people
still routinely blort out tons of code for it -- code that has to fit in the
comment fields of FMS forms (!), code where practically every statement in the
language uses different quoting, structuring, and other syntactic convensions.
Actually, to call this gross is an insult to gross languages everywhere.

I would, however, count many languages with limited statement forms and which
extend solely through the use of rigid syntax mechanisms as failures, mostly
because people want to be able to control the "look" of basic operations and
won't accept having to do obvious stuff in non-obvious ways. Some languages of
this sort have succeeded, but not many, and I suspect that the ones that have
succeeded have done so in spite of, rather than because of, their rigidity.

One language that deserves special mention here as illustrative of the pitfalls
in this area is PostScript. PostScript has a rigid syntax and is carefully
designed so that each extension (and there are dozens if not hundreds of them
around) can be parsed even when a given implementation doesn't support it.
Facilities are also provided so that PostScript programs can test for the
presence of a given extension and "work around" its absence -- exactly the sort
of thing being proposed here. PostScript manuals even go to the trouble of
explaining in detail how to use these facilities to write more portable

And what has been the result? It has been a total disaster. Extensions,
including highly proprietary and nonstandard ones, are used willy-nilly with
absolutely no attempt to test and make sure support for them is present. Your
typical PostScript interpretor has to define at least a dozen obscure
nonstandard extensions if it is to have any chance at all of handling a typical
PostScript program. Heck, one of the most common extensions you run into is one
where 68000 machine code is loaded into the printer and executed by print jobs!
(Needless to say, "correct" implementation of this consists of ignoring it.) 

And perhaps worst of all is the fact that all this support for extensions
didn't satisfy anyone. It is by no means uncommon for PostScript programs to
piddle around with the interpreter loop in an attempt to enhance the basic
syntax of the language. And don't confuse this with languages like LISP with
"nice" facilities like reader macros -- this stuff is *ugly*. But people still
do it.

Speaking as someone who has spent way too much time dealing with support issues
for one such language, I will add that having Sieve turn into another one is a
showstopper for me. For the most part I'm pretty comfortable with what we
have now (modulo filling in a few blanks and maybe fiddling around with the
punctuation some) and I don't want to see it ruined.


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