[Lawrence Greenfield]:
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.
the wording isn't good, I welcome help. the intent was to allow
static analysis to optimise variable references away. perhaps an
"as-if" rule is understood, so changing the SHOULD into a MUST is a
non-problem.
It should also be made clear that variables are expanded once, not
repeatedly.
good point.
When the string is evaluated, substrings matching variable-ref shall
be replaced by the value of variable-name.
+ Only one pass through the string shall be done.
one of the examples ("${dollar}{beep}") demonstrates this.
* 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 don't understand what you mean here.
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?
does require carry over? I'd say "no". variables shouldn't either.
If and when people start thinking about includes and functions,
scope becomes even more important.
let's address that when the need arises. for now, consider SET to
implicitly declare the variable to have file scope. add LOCAL or a
generic DECLARE action if you want them. I think they are overkill
for Sieve, but we'll see.
* Numeric variables
When does the side effect of tests have it's effect on numeric
variables? After the test? Only inside the if?
after the test.
as it happens, I just rewrote that part of the spec to cater for
:matches as well as :regex. here's the new text:
3.2 Numeric variables
The decimal value of the numeric variable name will index the list of
matching strings from the most recently evaluated match of type
":matches" or ":regex". The list is empty if the match was
unsuccessful.
For ":matches", the list will contain one string for each wildcard in
the match pattern. Each string holds what the corresponding wildcard
expands to, possibly the empty string. The wildcards expand
greedily.
For ":regex", the list will contain the strings corresponding to
the group operators. The groups are ordered by the position of the
opening parenthesis, from left to right.
The first string in the list has index 1. If the index is out of
range, the empty string will be substituted. Index 0 returns the
number of strings in the list.
Example:
require [ "fileinto", "regex", "variables" ];
if header :regex "List-ID" "<(.*)@" {
fileinto "lists.${1}"; stop;
}
# this is equivalent to the above:
if header :matches "List-ID" "<*@" {
fileinto "lists.${1}"; stop;
}
if header :matches [ "To", "Cc" ] "coyote(_at_)**(_dot_)com" {
# ${0} is always "2", and ${2} is always the empty string.
fileinto "business.${1}"; stop;
} else {
# ${0} is always "0"
stop;
}
=== excerpt ends ===
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}(.*)")) {
}
it refers to the variable set in the first test.
* Numeric variables
What does nested grouping do?
header :regex "Foo" "((a|b))*"?
the traditional thing, see above.
* Numeric variables
Does a failed matching clear all numeric variables?
yes.
* 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.
there is no doubt optimisation becomes harder, but in the end system
efficiency could improve since some long Sieve scripts now can be
expressed much more compactly.
--
Kjetil T. | read and make up your own mind
| http://www.cactus48.com/truth.html