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
xxxxxx@bothner.com   http://per.bothner.com/