[Jutta Degener]:
On Tue, Apr 08, 2003 at 10:23:11AM -0700,
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
> > the match order for [ a, b ] [ A, B ] should be aA, bA, aB,
> > bB. this means that messages sent to both addresses will be
> > forwarded to <kjetilho+foo(_at_)ifi(_dot_)uio(_dot_)no>, i.e. the first
match
> > string has precedence. in this example, what the wildcard
> > matches is irrelevant.
>
> Cute. I can live with it.
I'm not happy. Before this, I could stop matching when any
combination matched.
Now I have to either keep reading to the end just in case a
variable assignment changes, or figure out in advance whether any
of the strings following use any variables and keep reading to the
end only if that is true.
okay, I see your problem. so which match is returned should be
undefined? that's fine with me. if the user needs a specific
ordering, he can split the expression.
By the way, coupling variable assignments and matches _really_
makes life interesting for anyone implementing streaming matches
such as "body".
Without them, it's possible to at least predict a finite number of
possible variable values and match those in parallel in one pass.
neat!
With variables, you may not be able to predict what string a later
match will match against, because the match pattern itself may contain
variables that are set as the result of previous match patterns.
if body :matches "*call(*,*)*",
{
if body :matches "*response(${3},${2})*"
{
...
}
}
These are extreme examples that don't affect the ability to
parallelize the more common fixed choices, but I'm not looking
forward to the extra complexity, and I don't think it's justified
by functional benefits.
one sledgehammer is to declare that no variable expansion is performed
on match patterns. it may seem a little arbitrary in the spec, and
indeed it can't be expressed in the grammar without _large_ changes to
it, but efficiency of implementation may trump expressiveness here.
since body isn't out as an RFC yet, an alternative approach is to
change _that_. for instance, implementations can be allowed to refuse
searches with non-constant matching patterns. (this can be determined
at script upload time, right?)
--
Kjetil T.