Subject: Re: envelope test syntax?

From: Michael Haardt <[email-masked]>
Date: Wed, 19 May 2004 16:35:49 +0200

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

To avoid that, C defines "typedef-name" to be an identifier, thus avoiding
a self-modifying grammar by a more generic grammar with semantics checks.

> Relatedly, the SIEVE RFC doesn't really specify whether "require"
> enables an extension syntax or merely use of an extension at run time.

Indeed, the "require" description refers to section 2.10.5:

   If an extension is not enabled with "require", implementations MUST
   treat it as if they did not support it at all.

But it does not say if this is to be understood strictly or lazy.

> For example, given this complete script:
>
>     if false { fileinto "impossible"; }
>     else { keep; }
>
> Is that a syntax error because it is missing the "require"?

It is as much a syntax error as the following:

    if false { foobar "impossible"; }
    else { keep; }

That does not mean the parser must not parse the above.  It may parse
it and during semantic analysis, the Sieve implementation should treat
a disabled "fileinto" the same as "foobar", which is very easy, since no
flag "fileinto-is-fine" was set by a "require".  A strict implementation
would barf, a lazy one wouldn't, because the unknown command is never
executed.  I will update the Exim Sieve implementation notes to cover
this.

To a certain amount, you can move things between syntax and semantics,
as you can move things between scanner and parser.  Usually, you advance
to the higher layer, if the task becomes too hard or even impossible
at the current layer.

A self-modifying grammar is not context free, so it is usually made
generic enough to become context free, moving additional contraints to the
semantic analysis.  The semantic analysis error handler is of course free
to output "syntax error", if the specification says that it should do so.

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

  exists [ ]

That's an empty list of headers.

Michael

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 19 May 2004 19:49:36 -0400

On Wed, May 19, 2004 at 04:35:49PM +0200, Michael Haardt wrote:

   [ stuff about angels on heads of pins snipped ]

> That's an empty list of headers.

My reading says that a string list has to have at least one string,
thus the question of how you would get an empty list.  Am I reading
wrong?

mm

---

From: Tim Showalter <[email-masked]>
Date: Wed, 19 May 2004 17:14:29 -0700

> thus the question of how you would get an empty list.  Am I reading

I don't think so--the syntax does seem to require at least one.

Tim