Chris Newman <Chris(_dot_)Newman(_at_)innosoft(_dot_)com> writes:
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.
Pre-processing is a good indication that one's language isn't
powerful enough. Supporting "support" in an interpreter is *trivial*
- it's just a table lookup. What's the problem?
In addition, I'd like to be able to write a client that
automatically generates scripts which use "support" to dynamically
discover interpreter capabilities. I like the idea of writing a
client which can take advantage of new features but can produce
scripts which work with older servers as well.
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
and understand.
I don't think anyone was trying to argue that we should restrict the
semantics of the language, merely the way in which they're expressed.
And frankly, I don't see what the problem is with the proposed
restriction; the tagged block model produces code which looks just
like C, and works with *every* control structure I can think of.
I'd personally much rather feed plugins a datastructure produced by
a generic parser. "Just give the plugin access to the raw script" is
just *begging* for disaster, IMHO - plugins *will* get the parsing
wrong ("Well, in a while() block, you can use newline and CRLF, but in
a try/catch block you can only use CRLF..." No). Having multiple
plugins trying to deal with each other when each one tries to use its
own little parser to do its own little thing will be a nightmare.
Having plugins do parsing is bad design (although you're welcome to do
it in your implementation if you want); defining Sieve in such a way
as to force server writers to have plugins do their own parsing seems
almost criminal.
)Rob