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.
It should also be made clear that variables are expanded once, not
repeatedly.
* 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.
* 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.
When Sieve scripts are run in serial (as many implementations now allow) do
variables carry over from one to another? Why or why not?
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?
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?
if (allof (header :regex "Foo" "${1}(.*)", header :regex "Bar" "${1}(.*)"))
{
}
* Numeric variables
What does nested grouping do?
header :regex "Foo" "((a|b))*"?
* Numeric variables
Does a failed matching clear all numeric variables?
* 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.
Larry