On Fri, Aug 28, 2020 at 7:49 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

Dear all,

one of the main issues I have with the pattern matcher described in this SRFI is its extensibility.

Seemingly, it cries for being extended through new keywords. Recent examples are the "***" operator or the record extensions "struct" and "object". Specific implementations may want to extend it further.

The problem with SRFI 204's match, however, is that all these extensions are not backward compatible.

Consider, (match <expr> ((object <rtd> (field x)) <body>)), for example. With Gauche's object extension, <expr> has to evaluate to a record of type <rtd>. Without Gauche's extension, <expr>, however, has to evaluate to a list of three elements, of which the third is a list with two elements (and the pattern variables (!) `object', `<rtd>`, `field`, `x` will be bound accordingly).

NB The (less powerful) pattern matcher of syntax-rules/syntax-case does not suffer from this problem.

Marc

That was a limitation I had accepted when I took this on. I was aware that there are people who wanted a more extensible pattern matcher (like Racket's). The way I came to be involved in this project in the first place was bringing up my desire for a more full-featured pattern matcher in the srfi-200 forum. Panicz pointed out that that didn't really align with the rationale of the SRFI, which, after some back-and-forth, I understood. John volunteered that he was working on turning the WCS pattern matcher into a srfi, and that is how we came to be having this discussion.

Felix