Hmm. Yes, this is a real problem. I don't suppose you'd prefer
that unknown extensions return 'true' instead of 'false', right?
No, I'd prefer that they return an error and leave the user's mail
unprocessed. They're essentially link errors and can be detected just
after you finish parsing the script.
Ok, this makes sense to me. The implementation needs to make sure
that any extensions that it doesn't support are guarded by the
appropriate 'support' tests *before* execution of the script commences.
(In the implementation I'm thinking of, where ACAP is used to store
the script on the server, the parsing happens when the script is stored,
and the error can be reported at that time, so a "bad" script will never
be executed by the filter agent. I like this.)
I would still argue that the behavior of trying to execute an
unknown extension should be as I've proposed, though.
I strongly disagree. This will result in unpredictable scripts. Every
**typo** is processed as an unrecognized extension.
Ok, I'm convinced....
[re: the mystery math extension]
But that is really pretty ugly, and I don't think we're trying
to make Sieve be Turing complete via extensions, so I don't
see this "lack" as a real drawback.
I consider ruling it out to be a serious drawback.
Well, OK. Let me make my concern clear -- It makes no sense
to specify a 'support' test, which implicitly recognizes the possibility
of extensions not supported by an implementation, if you don't
at least specify the syntax that such extensions must follow.
I'm not particularly wedded to the syntax that I originally proposed,
I just picked it as the simplest possible generalization of the syntax
in the current draft. If you want to propose a more general syntax,
that's fine. However, I believe that it is unacceptable to leave the
situation as it is, where an extension is free to specify its own syntax.
The base draft should specify the grammar for the base language and
for *all* extensions -- an individual extension should specify its own
syntax *as a proper subset* of the base syntax.
Stan