| > Given that, I would still like to suggest that the tests "and"
| and "or" be
| > defined in the draft spec. as synonyms, if not the primary names, for
| > "allof" and "anyof", respectively. The former are almost universally
| > intuitively understood everywhere, whereas the latter are,
| let's say, unique
| > to this draft.
|
| This conflicts with one of the prime goals of Sieve, which is ease of
| implementation. It was also discussed very early in Sieve development.
| Can you elaborate on why you feel the alternate syntax is required?
I have two answers: a clarification and a bit of philosohy.
To clarify:
I am suggesting that "and" and "or" be defined as infix tests, with the
intentional side-benefit of avoiding the "short-circuit" evaluation problem.
In the test expression below:
test1 and test2
test1 would evaluate first, and only if its value is true, would test2 be
evaluated.
test1 or test2
The "or" test would similarly function such that test2 would only be
evaluated if test1 were false.
Using infix notation improves readability (it is more natural to read), is
not difficult to parse, and provides even simple parsers the side-effect of
being easy to skip evaluations.
Now the Philosophy:
A prime goal of sendmail.cf was that it be easy to parse. In hindsight, it
would have been better to have a more readable configuration language, even
if the computer had to work a little harder at parsing it.
Which is more important in the long run? Human time or computer time?
Let's suppose that the real goal of Sieve is to establish a usable email
filtering standard for the Internet, one which lets users across the
Internet easily define filtering rules. Given this supposition, is it
better that a few programmers work harder to write a good parser, or better
to have millions of Internet users work harder to write their filters in yet
another "easy to implement" but difficult to understand language?
If "easy to implement" is really the prime goal, then why not just use
"regex"? It *already* exists, is very fast and efficient. There are even
lots of users who are very comfortable with it. For those users who do not
understand it, there is lots of documentation all over the Internet on its
usage.
Since "regex" wasn't used, I suspect that there must have been a sub-goal of
"easy to comprehend" by the user.
I would rather have a language that is easy to write and comprehend by
humans, even if it is a LALR(1) language that requires a bit of effort to
parse. The parsing effort can be minimized by clever designs, such as using
good parsing technology (flex, bison), and precompiling the Sieve filters
into a byte-code (ala regcomp/regex). This may make the implementation more
difficult, but this extra bit of work now pays big dividends later.
We don't need another sendmail.cf.
--
Alan K. Stebbens <alan(_dot_)stebbens(_at_)software(_dot_)com>