On Tue, 20 Jan 1998, Rob Earhart wrote:
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.
A client pre-processor does this better than mucking up the language.
Besides, I figure at most 5% of the users will write their own scripts and
probably 1% of those will have more than one server. This is such a rare
case it's not worth worrying about in the server. I want to see the
"support" command dropped from the language.
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.
Parsers are cheap and easy to build. Semantics are expensive -- if the
user doesn't like the semantics then the language doesn't get used.
Constraining the semantics to make the parser easier is backwards. I'm
not against trying to design commands that are easy to parse -- but it's
much more important that the commands are easy for humans to think about
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.
Just give the plugin access to the raw script, parsing callbacks and have
it return how many characters it consumed. Trying to layer the plugins on
top of a generic parser just adds an unnecessary layer. Unnecessary
layers are *bad* -- they produce layering violations and constrain what
you can do in the future.
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;
This isn't sufficient justification for restricting the future semantics
of the language. There's a big difference between a protocol (designed
with parsing as a primary goal and human readability as a secondary goal)
and a language (opposite priority). The power users who write these
scripts will get a client which supports the extensions they want to use.