Thanks for your reply.

Am Fr., 28. Aug. 2020 um 20:06 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:

> 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.

While extensibility by the user always sounds like a good idea, my
concerns are not so much about this. My concerns are more about future
developments of this matcher. As struct/object/***/whatsoever showed
up later, the need for further keywords may arise. A future SRFI
adding them to this matcher, however, would be, strictly speaking,
incompatible to SRFI 204.

The main reason for this, in my opinion, is that the matcher of SRFI
204 does something no standard form of R7RS does: It is a binding
construct but whether some identifier appearing in the syntax will end
up as a variable being bound, not only depends on its syntactic
position but also on the state of whether it *happens* to coincide
with a keyword.

This is a design error of the original matcher that we are inheriting here.

A solution is a stripped-down version in that all patterns are
quasi-quoted so that pattern variables only appear in conjunction with
unquote where they can be easily detected. (For that to be fool-proof,
_ has to be forbidden (or rewritten) as well; see also my comment on
the SRFI 202 mailing list about.)

In any case, describing this matcher in form of a SRFI is certainly a
very good idea. But as it stands now, I don't think it is elegant and
future-proof enough to become part of R7RS-large. A binding construct
where it depends on its earlier binding whether an identifier becomes
bound or not cannot be quite the right thing.