That said, I have wondered for a while whether it would not be better to
have a formal ABNF syntax for the commands and tests. Would that
actually be possible or useful?
I don't think so. Programming languages are typically specified as
Sieve is, in terms of tokens, a formal grammar, and a standard library.
Not to forget semantics. Sieve (as defined by the RFC) uses a generic
syntax, and specifies the semantics for particularly formed words.
Despite labelled "Syntax", e.g. tests are really describing semantics.
It is common practice to define semantics very unformal and even with
natural language, so does the RFC.
Despite the RFC confusing syntax and semantics of the Sieve language,
the concept is easy to understand, but it asks for specification errors.
We could do what you suggest--in fact, the early drafts did so. It
was not very readable or particularly helpful. Extensions would have to
extend the grammar, and that's error-prone and not at all in line with
what programming languages usually do. Worse, you wouldn't be able to
parse the general language without knowing all the extensions a
particular script used.
The generic syntax is fine as it is, but it is not enough.
There is no reason not to specify tests and actions at the syntax layer
as subsets of the language generated by the generic syntax. That way
you move their syntax from the semantics analysis back to the syntax
analysis, where it belongs to. It is easier to understand a formal
syntax definition than a formal semantic definition, and you see what
you get from the current approach when looking at the "if" command.
The current section describing is it rather long, but not correct.
The ABNF
if-command = "if" test block *( "elsif" test block ) [ else block ]
is short and (hopefully:) correct. An ABNF extension for tagged
commands would solve the current specification problem. From
exim-4.33/doc/README.SIEVE:
----------
The grammar is specified in ABNF with an extension to describe tagged
arguments that can be reordered: { } denotes a sequence of symbols that
may appear in any order. Example:
start -> { a b c }
is equivalent to:
start -> ( a b c ) / ( a c b ) / ( b a c ) / ( b c a ) / ( c a b ) / ( c b a )
[...]
address-test = "address" { [address-part] [comparator] [match-type] }
string-list string-list
----------
Sieve is really great, but it should not be neccessary to write
an addition to the RFC, that specifies a bunch of things, before
implementing it.
Michael