The "FHD" matcher wins when it comes to simplicity and clarity with
respect to syntax and semantics, although it may not be the most
powerful matcher. On the other hand, it has no baroque syntax and its
catamorphism feature and multiple values awareness make it a great
tool for recursive use.

A syntax-rules implementation is possible and here is one:
http://snow-fort.org/s/rapid-scheme.org/marc/rapid/match/0.1.5/index.html.
(I thiunk

You can include it in your SRFI. Apart from that, I think it makes
sense to give that matcher its own SRFI.

Marc

Am Fr., 26. Juni 2020 um 23:12 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> Initial observations:
>
> 1) For "if the Friedman-Hilsdale-Dybvig matcher is available under the match/WCS binding" read "if the Friedman-Hilsdale-Dybvig matcher is available under the match/FHD binding", and eliminate the use of the subscript "WCS" in the Implementation section in favor of the slash.
>
> 2) A usual style of Acknowledgements sections is to mention the people that wrote the predecessor documents (F, H, D, W, C, S, and the Racket team) as well as the contributors to the SRFI mailing lists.  Then closer to the end add any specific contributors.
>
> 3) The bundled implementation should not use define-syntax-rule, as that is not part of R6RS syntax-case.
>
> 4) I think that the scope of this SRFI can and should be greatly enlarged by eliminating the attempt to be compatible with the Racket matcher.  This limits the available patterns severely, since the syntax of Racket patterns only accidentally coincides with the other two syntaxes.
>
> I have a lot of respect for the work of the Racket team, but they have their own way of doing things, and I think trying to import the Racket Way into Schemes with other ways is often a mistake, as it is often hard to pick just one feature out of it and integrate it into a different Scheme.
>
> When R7RS was standardizing define-record-type, we had two reasonable choices: the widespread SRFI 9 style or the R6RS style.  They were conceptually incompatible, although by good fortune it happens that you can write a macro that handles either syntax, as Will Clinger has done for Larceny.  But WG1 did not attempt to create a define-record-type that provided a subset of the capabilities of both definitions.  Instead it took just one of them (selected by vote), enhanced it a bit, and made that the way of defining record types in R7RS-small.
>
> I realize that point 4 will be controversial, but I want Schemers to have as much power as is feasible with as few limitations as are necessary.  It is not as if the WCS and FHD matchers *cannot* run on Racket, or that Racket programmers who wish to use portable instead of native matching are incapable of doing so.  (It would be worth checking if the portable implementation is notably less efficient on Racket than the native implementation.)
>
> An advantage of adopting the WCS matcher, or as much as is portable, is that it is implemented in syntax-rules, which makes it portable to R7RS-small systems, particularly since no decisions have yet been made about adopting syntax-case, explicit renaming, both, or neither as part of R7RS-large.  This does not of course mean that there cannot also be a syntax-case implementation.
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
> The native charset of SMS messages supports English, French, mainland
> Scandinavian languages, German, Italian, Spanish with no accents, and
> GREEK SHOUTING.  Everything else has to be Unicode, which means you get
> only 70 16-bit characters in a text instead of 160 7-bit characters.
>