while perusing the list archive, I found another point which probably
needs addressing in the draft. consider:
if address :matches ["To", "Cc"] ["kjetilho(_at_)*",
"k(_dot_)t(_dot_)homme(_at_)*"]
if a message contains both "To: kjetilho(_at_)darwin(_dot_)uio(_dot_)no" and
"Cc:
k(_dot_)t(_dot_)homme(_at_)hedda(_dot_)uio(_dot_)no" -- what's the value of
${1} ?
the current draft says:
The interpreter MUST short-circuit tests, ie. not perform more
tests than necessary to find the result.
so the behaviour is undefined.
I suggest that this case is best left undefined.
one suggestion was to specify ordering explicitly: for each pattern,
iterate over each header in the list. (according to this algorithm,
${1} holds "darwin.uio.no".)
the other view is that users which need determinism can write
if anyof(address :matches ["To", "Cc"] "kjetilho(_at_)*",
address :matches ["To", "Cc"] "k(_dot_)t(_dot_)homme(_at_)*")
in either case, I think the draft should make clear whether the result
is undefined or not.
I agree. I have no problem with requiring left to right short circuit
evaluation of anyof and allof since I suspect most implementations do it
this way already. Evaluating lists in order may be more problematic, and I
could easily see different implementations having done iterators over
multiple list arguments differently, and it is quite possible for
them to have good reasons for doing so.
on a slightly related note, the draft rules out cute tricks such as
if allof(address :matches ["To", "Cc"] "kjetilho(_at_)*",
address :is ["To", "Cc"] "abuse(_at_)${1}")
based on this wording:
The expanded string MUST use the variable values which are
current when control reaches the statement the string is part
of.
in other words, ${1} expands to the value it had before the first
address test.
This sort of thing can get to be so unclear I'm almost tempted to
leave it undefined as well so people won't write stuff this obscurely.
But that's probably a bad idea.
Ned