On Thu, May 13, 2004 at 01:37:19PM +0200, Michael Haardt wrote:
[ skipping much that I have no quibble with ]
(That's not as thorny as self-modifying grammar of course.. a la
typedef in C)
Types are usually checked at the semantic layer, probably for just that
reason.
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.
This is different from, say, function prototypes, because a function
reference whose only error is that it doesn't match a prototype
is still syntactically correct.
Relatedly, the SIEVE RFC doesn't really specify whether "require"
enables an extension syntax or merely use of an extension at run time.
For example, given this complete script:
if false { fileinto "impossible"; }
else { keep; }
Is that a syntax error because it is missing the "require"? (I can't
imagine that it is: my own implementation says it's not. But that
would be a lesser example of a self-modifying grammar.)
Exists Test With Empty List Of Headers
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?
That's why I suggest to handle syntactic issues at the syntactic level:
Easy to use formal specifications exist, that don't leave anything
to guess, plus it makes an implementation easier.
Still no argument there :-)
mm