Pardon if this has already come up. I only found one prior reference in
my search.
There's a section in S5 about "Matching against non-strings", but it
really only addresses matching against strings that are retrieved
dynamically from tied values.
Some operations in a rule operate on string values, so:
rx{a}
does a character match, but much of a rule is about grouping, repeating,
recursing and backtracking. These operations are universal. Also,
closures can perform a match against any kind of data.
So, if rules matched against strings only as a special case, and more
generically against any object which implements a role that defines a
set of access methods, then we *could* match against anything.
This moves us up a layer of abstraction and allows efficient matches
against data like piddles, databases, web sites and other such
abstractions that might occasionally CONTAIN strings, but have a higher
level against which to match more efficiently (and without costly string
conversion).
The role might look like:
role rx_tok_class {
method init(rx_tok [EMAIL PROTECTED]) {...}
multi sub infix:in(rx_tok $item, rx_tok_class $set) {...}
}
role rx_tok {
multi method compare(rx_tok $other) {...}
multi method compare(rx_tok_class $other) {...}
}
role matchable {
method index(int $n) returns (rx_tok) {...}
method length() returns(int) {...}
}
Of course strings will be special-cased and would bypass much of this
abstraction as an optimization.
Another way of saying this is: if rules are a grammar, then it might be
nice to be able to build a separate (very light, given that rules can
contain regexes) scanner.
--
â 781-324-3772
â [EMAIL PROTECTED]
â http://www.ajs.com/~ajs
