Am Sa., 29. Aug. 2020 um 02:46 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> Well, it will go in the ballot, where you may certainly vote against it.

I'd rather hope that we can find a technically convincing solution
while this SRFI is still in draft mode.

Marc

> On Fri, Aug 28, 2020 at 3:22 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> 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.