Subject: Re: envelope test syntax?

From: Michael Haardt <[email-masked]>
Date: Wed, 12 May 2004 11:35:22 +0200

> > 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

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 12 May 2004 13:11:27 -0400

> 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.  

> is short and (hopefully:) correct.

    closer when "else" is quoted :-)

>  An ABNF extension for tagged

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)

> an addition to the RFC, that specifies a bunch of things, before

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