[Top] [All Lists]

Re: variables: interaction with "require"

2003-04-14 12:07:34

[Ned Freed]:

  > 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

  > (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.