[Top] [All Lists]

Re: WGLC on draft-freed-sieve-ihave-02.txt

2008-09-10 16:07:29

On Wed, Sep 10, 2008 at 02:03:42AM +0200, Stephan Bosch wrote:

I just scanned though this draft specification and, although I like the 
potential of this new Sieve feature, I am very worried about the 
implementation of all this. The issue described here was already coined 
in November of 2006 (e.g., but to 
my knowledge it was never discussed further.

That one was my note.  My problem was mainly that, according to the
version of the draft I was commenting on, the capability would only be
enabled inside of a block where an 'ihave' test had contributed to a
conditional evaluating to true.  I thought it would be difficult to
coordinate the truth of the conditional evaluation, which might contain
a lot more than just an 'ihave', and the enabling of the capability.
(it's more than that, read the text at the link I guess, even though I
didn't elaborate at length I tried to present the gist of the problem.
I also would have prefered to have explicit enable/disable of the
capability, distinct from the test, but the way it evolved is ok).

This has been addressed in the later 'ihave' drafts by having it say
that a capability is enabled when a ihave test successfully operates on
that capability, given that an earlier definition says that an ihave
test is successful when all of the capabilities given to it are

Anyway, I think that was quite a bit different from what you are
saying here:

I've built a compiler that compiles Sieve scripts into a byte code 
representation. I'd like to see this ihave feature work for my 
implementation even when the compiler is completely oblivious of the 
extensions listed by the ihave test. Given the fact that most extensions 
introduce new language elements, the compiler must have some means of 
ignoring/discarding the regions of the script that need the obscure 
extensions. Alternatively, doing the actual ihave test at runtime 
requires that the compiler can distinguish between erroneous language 
features and features that would have been introduced by the unknown 
extension (in order to produce compile time errors or runtime errors 
respectively). This would require knowledge about that obscure extension.

As the document itself indicates, it will be very difficult to 'parse 
around' the script regions that depend on the obscure extensions listed 
by ihave   [...]

And yeah, that can present some difficulties.  But I think as long as
you know what the lexical elements of a test or an action are and how
each one is terminated, or the syntax of a comparator token, it's
possible to find a way to swallow an unknown element such as action,
test, comparator name, etc., and generate code with enough information
that it can resonably report an error at runtime should it be
encountered.  I'm looking forward to doing this myself :)

Here, the use of the fileinto extension is scoped within the block 
controlled by the ihave command and it is invalid outside that block. If 
the compiler is completely oblivious of the fileinto extension it can 
now safely discard the ihave command and implicitly be rid of all script 
regions (in this case the block containing the fileinto command) that 
depend on the unknown extension. It thus becomes similar to C's #ifdef 
for Sieve compilers that handle ihave at compile time.

FWIW, my implementation actually supports #ifdef-like constructs that
can be used to enable or disable code based on various capabilities;
I rather like putting that level of control at, well, that level, but
obviously one can't mandate that everyone implement things that way.