[Ned Freed]:
[Jutta]:
> Now that the door has been opened to "strings that don't have
> variables expanded in them", can we consider using the same kind
> of strings as variable names in "set" commands and as match
> patterns?
I've thought about this and I believe I like it. I assume you're
talking about any match argument anywhere, not just when :matches
or :regex are in use. (The issue with body isn't addressed unless
you do this.)
REQUIRE is a special case in that it is only allowed as the first
action in a script. it therefore makes sense that all REQUIRE are
processed before any of them take effect. (this is also a useful rule
for resolving dependencies among extensions if that should occur in
the future.)
the parser/lexer will know which strings contain variable references,
and can easily set a boolean for "constant/non-constant". I suggest
we use terminology like "<argument> must be a constant string without
variable references". this makes "${foo}" an error, not a verbatim
value, in such a context.
Good point.
This needs to apply to the match argument in the string test as
well. It cannot apply to the source argument or the test becomes
worthless.
> (So they can be precompiled and don't change contents
> during program execution.)
Yep. Seems like a good idea to me.
why can't you optimise it only if the string is static? I can see
some utility in being able to match against a previous result.
require [ "variables", "fileinto" ];
if header [ "List-ID" ] :matches "*<*(_at_)*>*" {
set "listaddr" "${2}(_at_){3}";
set "listname" "${2}";
if address :is :all [ "to", "cc" ] "${list}" {
fileinto "INBOX.lists.${listname}";
} else {
fileinto "INBOX.possibly-spam";
}
}
Fair enough, but the case that breaks the bank is body. You really really
really want to do all your body search operations in a single passs. If you
don't you can easily write scripts that have serious performance problems.
I don't especially care about the case of optimizing the header, address,
envelope, and string tests, but body is a serious problem. And it seems fairly
awkward to say that the match parameter doesn't get expanded in body but
does elsewhere.
Ned