There are several of these issues that I want to look back over the
forum discussion before I address, since they came up in earlier
discussions. I'll mark these below

On Fri, Aug 27, 2021 at 9:43 AM Marc Nieper-Wißkirchen
<xxxxxx@gmail.com> wrote:
>
<feedback is good>
>
> The following are a number of points that are not yet addressed by SRFI 204 (unless I have overseen something):
>
> - When and how often are the expressions that evaluate to procedures, predicates, etc. evaluated?

*review forum*

> - Syntax is often conflated with values.  Please use the entry format of R7RS (or R6RS) in the formal specification.

Could you point to a specific example so I would have a better idea
what I need to clean up.

> - What does <number> mean? A numeral? Of which kind? An expression evaluating to a number?

I can change this to <evaluates-to-integer>

> - What does the failure thunk do?  Does it abort the current continuation?  Or does it have to be called in tail position with respect to the pattern body?

*review forum*
> - The object record matcher is not compatible with R7RS record types (when the field names are <identifiers>, see SRFI 150 for some discussion).

*review forum*/ I will try some examples with code in srfi 150 or the
linked discussion

> - Remove tree patterns from the spec if they are not mandatory.

*review forum*/I remember asking about this at the beginning and I may do it

> - It seems that pattern variables are now bound (lately) in the body as in the original matcher by Wright (and which is, IMO, the right thing).  Is this correct?

The

> - (var ...), which seems important, is not described.

I never succeeded in implementing var so I took it out.

> - I don't understand the "Error" section.  What of it is part of the specification and what just describes the sample implementation?  The latter things should be moved to the section about the sample implementation.

I think I put errors in after I was lurking in guile-devel and read
the thread "Re: [PATCH] add SRFI: srfi-121; generators" and come
across this enumeration of things that were often missing from srfis:

- Questions of tail context are often ignored.
- Higher-order procedures are often silent with respect to call/cc,
exceptions or side effects.
- Formal syntax is often missing.
- Formal semantics are almost always missing.

so I just started putting in the things on that list I hadn't already covered.

> - How does `match' handle cyclic data?

I will have to look into that

>
> Minor points:
>
> - RnRS does not use the notion of "s-expression".  The correct terminology can be datum, constant, literal, etc.  Thus, "pattern s-expression" should probably be renamed.

Ok, pattern literal

> - The match-letrec sample implementation does not work in all corner cases (as was discussed extensively).  It's limits should be noted and also that a full implementation is, in principle, possible.

*review forum*

> - It would be nice to have some benchmarks between using match and direct implementation, e.g. for the transpose example.

There are some benchmarks under test/benchmark in the repo I made, and
I included their results. One was a chunker I used to see if some
changes I had made affected the speed, the other was a set of matchers
that profiled various ways of comparing two neighbors in a random
sequence for equality (in the body, using repitition , using
predicates, or using fields).

>
> Personal opinion:
>
> - The order in which the patterns and subpatterns are matched should be unspecified.  This improves the "declarativeness" of the matcher.
>
> -- Marc
>
> Am Mo., 23. Aug. 2021 um 23:45 Uhr schrieb Felix Thibault <xxxxxx@gmail.com>:
>>
>> I am going over the SRFI to see if there are any corrections I need to
>> make before I submit it for a final draft. If you have any feedback,
>> please let me know.
>>
>> Thanks,
>>     Felix Thibault