This page is part of the web mail archives of SRFI 85 from before July 7th, 2015. The new archives for SRFI 85 contain all messages, not just those from before July 7th, 2015.
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. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/