Subject: evaluating tests when the result makes no sense

From: Дилян Палаузов<[email-masked]>
Date: Thu, 27 Nov 2008 13:52:46 +0100

Hello,

Are implementations permitted to stop evaluating a test, when the result 
makes no sense, e.g. in anyof(true, header "A" "B") evaluate "header"?

The point is, that Sieve-Variables, says (Sec. 3.2. Match Variables)

    The decimal value of the match variable name will index the list of
    matching strings from the most recently evaluated successful match of
    type ":matches".

However it is not very clear for me if every test needs to be evaluated, 
and thus if the last :match test was permitted to be evaluated, is it 
necessary to evaluate it? Consider a message

A: Xa
B: Xb
C: Mc

and
if anyof (header :matches ["A", "B"] "X*",
           header :matches "C" "M*") {
     //what is ${1}?
}

What would be the value of ${1}
* a - because after finding it out, the result of the first header test 
is clear.  Having true as the first parameter of anyof, then anyof stops 
evaluation.
* c - because this is the last matched test and the evaluation has not 
stopped after finding out that the first header test suffices for the 
result of anyof
* b - header evaluates all possibilities, and anyof stops when the 
result is clear.

Thanks in advance for your opinion,
	Дилян

---

From: Ned Freed <[email-masked]>
Date: Sat, 29 Nov 2008 13:37:51 -0800 (PST)

> Are implementations permitted to stop evaluating a test,

Yes. Not only are they permitted to do so, the variables extensions makes
short-circuiting a requirement - see RFC 5229 section 3.2.

> when the result

I think you meant "don't evaluate".

> However it is not very clear for me if every test needs to be evaluated,

Which is exactly why the specification requires short-circuiting.

> What would be the value of ${1}

It's required to be "a".

> Thanks in advance for your opinion,

This isn't a question of having an opinion, it's a question of what the
specification already requires.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 29 Nov 2008 23:02:52 +0100

Hi,

I _thought_ sieve required short-circuiting, but didn't feel courageous 
enough reply to Dilian's message...

The only occurence of "short-curcuit" in 3028 was removed in 5228, and I 
didn't see anything to replace it. Further, and perhaps more seriously, 
I don't see any requirement of order. As far as I can see, a sieve 
implementation can evalue header and envelope in either order in this 
case:

     if anyof ( header ... , envelope ... ) {
         ...
     }

Have I been smoking the good stuff?

Arnt

---

From: Philip Guenther <[email-masked]>
Date: Sat, 29 Nov 2008 14:25:54 -0800

> enough reply to Dilian's message...

The base spec doesn't require it because it's not observable without 
variables.

> implementation can evalue header and envelope in either order in this 

An implementation can do that only if the 'variables' extensions has not 
been required.  The variables spec, RFC 5229, says this in section 3.2:
   The interpreter MUST short-circuit tests, i.e., not perform more
   tests than necessary to find the result.  Evaluation order MUST be
   left to right.  If a test has two or more list arguments, the
   implementation is free to choose which to iterate over first.

Philip Guenther

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 30 Nov 2008 11:03:19 +0100

Philip Guenther writes:
>>  Further, and perhaps more seriously, I don't see any requirement of 
>>  order. As far as I can see, a sieve implementation can evalue 
>>  header and envelope in either order in this case:
>
> An implementation can do that only if the 'variables' extensions has 
> not been required. The variables spec, RFC 5229, says this in section 
> 3.2:

OK.

I had a vague intention of someday doing just that... "apply sieve 
script to all old mail", which would transmogrify the sieve script into 
a series of rather complex SQL queries and shuffle mail around from 
where it is to where the sieve script would have filed it. That would, 
among other things, make the RDBMS query planner choose evaluation 
order based on expected performance, and probably make the whole 
operation faster by a few orders of magnitude.

Arnt