True, type checking is a semantic issue (some of which can be done at
parse time), but that isn't what I was getting at. "typedef" modifies
the language syntax. Consider:
/*1*/ typedef unsigned int myint;
/*2*/ myint x = 3;
Without line 1, line 2 has an invalid syntax. This isn't a
semantic typechecking problem, it's strictly a syntax issue.
To avoid that, C defines "typedef-name" to be an identifier, thus avoiding
a self-modifying grammar by a more generic grammar with semantics checks.
Relatedly, the SIEVE RFC doesn't really specify whether "require"
enables an extension syntax or merely use of an extension at run time.
Indeed, the "require" description refers to section 2.10.5:
If an extension is not enabled with "require", implementations MUST
treat it as if they did not support it at all.
But it does not say if this is to be understood strictly or lazy.
For example, given this complete script:
if false { fileinto "impossible"; }
else { keep; }
Is that a syntax error because it is missing the "require"?
It is as much a syntax error as the following:
if false { foobar "impossible"; }
else { keep; }
That does not mean the parser must not parse the above. It may parse
it and during semantic analysis, the Sieve implementation should treat
a disabled "fileinto" the same as "foobar", which is very easy, since no
flag "fileinto-is-fine" was set by a "require". A strict implementation
would barf, a lazy one wouldn't, because the unknown command is never
executed. I will update the Exim Sieve implementation notes to cover
this.
To a certain amount, you can move things between syntax and semantics,
as you can move things between scanner and parser. Usually, you advance
to the higher layer, if the task becomes too hard or even impossible
at the current layer.
A self-modifying grammar is not context free, so it is usually made
generic enough to become context free, moving additional contraints to the
semantic analysis. The semantic analysis error handler is of course free
to output "syntax error", if the specification says that it should do so.
The "exists" test only suceeds if all specified headers exist. RFC 3028
does not explicitly specify what happens on an empty list of headers.
This implementation evaluates that condition with true, interpreting
the RFC in a strict sense.
How would you arrange to get an empty set of headers?
exists [ ]
That's an empty list of headers.
Michael