[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
William D Clinger wrote:
Per Bothner wrote:
How difficult would it be to extend the matcher to pattern matching?
That would involve the design of a pattern language,
That's why I wrote "Ignore issue [sic] of syntax", and
suggested a "pattern variable box" as the run-time
representation of pattern matching. I.e. ignore the
user-level syntax or API of how patterns are writen,
but assume a pattern variable gets translated into some
kind of placeholder object.
Actually, you'd probably want the "pattern variable box"
to be an index into some external data structure allowing
the pattern to be constant.
Unification would allow placeholders in either operand.
which could be based on the pattern language used for
macros but with extensions for the unary predicates
that acts as guards for the match. If a pattern
variable is allowed to appear twice, then some kind
of equality test would have to come out true as well
as the guard predicate.
Yes. And if disjunctions are allowed then you have to
be able to undo bindings. Then you need a way to encode
disjunctions, too. Ah well, as you say probably beyond
the scope of this SRFI.
SRFI-85 might provide or make it easier to define the
equality test for such a matcher, but I think there
are enough new issues with matching, especially
matching of regular trees, to justify a separate SRFI.
You're probably right.