On Wed, May 12, 2004 at 11:35:22AM +0200, Michael Haardt wrote:
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.
I assume you're referring to the confusing text that includes things
like "else" being a separate command, and "'elsif' must only follow
'if'" which is obviously incorrect. OTOH I think the incorrectness
there is not due to the documentation method, but in errors in the
description. i.e. the description could be corrected.
The ABNF
if-command = "if" test block *( "elsif" test block ) [ else block ]
is short and (hopefully:) correct.
closer when "else" is quoted :-)
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
That's all very good and very clear. I'm not arguing against it.
However there's still the issue of extensions: the syntax varies
depending on what extensions are enabled. Each extension can probably
be specified via BNF, but how would you address optional grammar (i.e.
as distinct from grammar that includes optional elements)? Particulary
when the syntax doesn't change when a capability is enabled, but it
depends on whether a capability is supported (whether enabled or not).
(That's not as thorny as self-modifying grammar of course.. a la
typedef in C)
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.
Do you think that SIEVE is unimplementable based on RFC3028? I won't
disagree that there are narrative errors, but I don't think there is
anything that truly isn't understandable. Again I'm not arguing against
a formal syntax specification: I'm just wondering about the claim that
the RFC is unusable.
mm