More problems:
* Semantics
> Strings SHOULD be evaluated every time control reaches the statement
> it is a part of, to make sure the expanded variable values are up-to-
> date.
This is central to the semantics of the language; this isn't a SHOULD.
Agreed. This has to be a MUST. I will also point out that this has some
interesting implications when it comes to having a body test, implications that
may cause me not to support the use of string substitutions into body tests.
(Basically I want to be able to do a single scan of the message that does all
the body checks at the same time.)
It should also be made clear that variables are expanded once, not
repeatedly.
Yep. Thought of that one but forgot to mention it.
* Syntactic structure
The "set" action doesn't fit into the Sieve grammar, as something that is
identical to an "identifier" is not a valid argument.
I guess that means we have to quote it. Yuck, but we do what we have to do...
* Scope
--On Monday, April 07, 2003 2:39 PM -0700
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
> As for scope, I think global scope is the right, and indeed the only
> realistic, choice.
Global scope is a wonderful choice that years of programming language
theory has shown to be an extremely bad thing.
And as any Pascal programmer such as myself can tell you, the complexity
associated with scoped variables has been shown to be a bad then when it isn't
necessary.
When Sieve scripts are run in serial (as many implementations now allow) do
variables carry over from one to another? Why or why not?
I don't think they should carry over. As for why, it is because it makes
all sorts of unpredictable behavior very likely.
If and when people start thinking about includes and functions, scope
becomes even more important.
* Numeric variables
When does the side effect of tests have it's effect on numeric variables?
After the test? Only inside the if?
I would say after.
Does the ${1} in the second test refer to the variable set in the first
test? Or does it refer to the previously set variable?
Cute. My implementation currently does the former, but I have no strong opinion
here.
if (allof (header :regex "Foo" "${1}(.*)", header :regex "Bar" "${1}(.*)"))
{
}
* Numeric variables
What does nested grouping do?
header :regex "Foo" "((a|b))*"?
That IMO is an issue for the regex draft. As for how it should be handled
there, I think that we should find some set of consistent capture semantics
from some regular expression system we like and follow it. Does the
Posix regexp spec cover capture?
* Numeric variables
Does a failed matching clear all numeric variables?
My personal preference would be "no".
* Program analysis
I guess some of what's bothering me is that there are several invasive
language changes with this draft that make it significantly more difficult
to analyze the language to make sure it isn't mutually contradictory, and
more difficult to analyze a piece of a program without global analysis.
. Tests now alter global state (thus the short-circuit problem)
. Variable expansion can drastically change patterns to match against,
preventing certain pre-compilation strategies.
Agreed, but IMO the benefits far outweigh the disadvantages. Like it or
not, there is a large class of operations sieve currently cannot do and which
people really really really want to be able to do. I have to tell customers
"no, you cannot do that at present with sieve" at least a couple of times
every month, and that they have to use procmail or something similar instead.
This really isn't an acceptable state of affairs IMO.
Ned