Thanks for replying so quickly!

Am Sa., 5. Sept. 2020 um 20:48 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:

> I think the issues you want me to comment on can be summarized as:

> Eager binding of pattern variables and the issues that may go with it.

The performance of the resulting matcher should be an important factor.

> Implementing from the SRFI w/o using the current implementation
> The complications of the edge cases for the spec vs Wright.

> The desire for a spec oriented around semantics, not an implementation (perhaps a reiteration of 2)

Exactly. The simpler and clearer the semantics, the better.

> At this point, part of what seems to be at issue is, is converting the WCS pattern matcher into a SRFI a valid rationale? Or what exactly does that look like? A complete re-implementation of the library beyond my current level.

As I said, if no one else would volunteer, I would be able to write one.

> This is a property of the WCS matcher, so I did provide illustrations, although when I haven't found any examples like, say, fibby? when I've done a repo search, so I'm not sure how used this feature is.
> I would need more details on what sort of info is needed for this. I put in tail contexts, error conditions, side effects, missing parts of the grammar and more examples for this reason. I agree "subsequent" could be clearer and I will put not/ellipsis/or patterns on my todo list.
> I suspect if we were using a different matcher we would have a different set of edge cases; this is not my area of expertise.
> If there are aspects of semantics that could be added/taken away to make the spec clearer, let me know. I have read that the srfi process has moved away from the idea of a "reference implementation" and can incorporate bug-fixes after finalization as long as the spec doesn't change. It may be that documentation of the use of pattern variables in predicates/fields belongs outside the srfi (although I think as long as it is a property of the implementation it should be documented somewhere). I have really only heard two opinions on this and I'm not sure if it's something no one uses or some people use or what.

Arthur can probably say much more about this. What the current vision
of SRFI 204 seems to be (if I have understood you correctly) is to
document the particular implementation by Alex and to provide a
centralized repository for the code.

So far, I have understood that a SRFI should specify something that
Scheme implementations are encouraged to implement. For that, the
semantics of the specification should be clearly stated (and written
down independently of some particular implementation). The sample
implementation, on the other hand, demonstrates that the specification
is implementable. If in contradiction, the written specification
counts, not the sample implementation.

If we want a SRFI to become part of a future language standard (as it
happened with SRFI 9, say), I believe that the SRFI's specification
should compare with the specifications in previous reports. In
particular, overly complicated semantics is at least a hint to bad
design (or artifacts of a particular implementation).

That said, of course, previous implementations that solve a particular
problem influence the development of a new SRFI in that area.