Am Fr., 4. Sept. 2020 um 19:46 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:

> I've just published draft #7 of SRFI 204. It was submitted by Felix Thibault, author of the SRFI.

Thank you again for your steady work with this SRFI.

> the behavior of pattern variables in predicates and fields.

I'd love it if you could comment on the issues I have raised on the
mailing list about the eager binding of pattern variables. Efficiency
is, by the way, another reason why it is probably a bad way to bind
the variables eagerly: For every variable matched, the current
implementation creates a new nested closure. Depending on the Scheme
implementation, variable access in nested closures is linear on the
nesting depth so it doesn't scale to long patterns. We shouldn't
specify something whose semantics are complicated, seldom needed, and
prohibit a fast implementation.

But even if you stick to the "new" behavior of pattern variables in
predicates and fields, a number of changes have to be applied to the
document. I am not the editor but as dictated by the SRFI process, a
SRFI must meet a number of requirements. One is: "It must contain a
detailed specification. This should be detailed enough that a
conforming implementation could be completely created from this
description." In its current shape, SRFI 204 however is not
implementable from scratch just by the text. In some sense, all that
an implementer could do is to copy the sample implementation.

I am mentioning this because it becomes apparent with respect to the
binding of pattern variables. In the current draft, it says "matched
identifiers [are available] for subsequent predicate and field
patterns". This, however, assumes some meaning of "subsequent", which
in turn assumes some order, in which patterns are matched. Such an
order is, however, nowhere detailed (except that I can check which
order the sample implementation uses). In particular, with respect to
not clauses or the ellipses, there are a lot of details missing. Also,
in or patterns, the implementation does something very specific not at
all covered by anything in the spec.

But when you fill in all the details trying to describe the behavior
of the current implementation in all edgy cases, what you will get is
a needlessly complicated spec, compared to the original clear
semantics of the Wright matcher. So, we should really write a new
sample implementation (or adjust the existing one) that follows the
original Wright semantics.

While every criticism has the danger of being disheartening, this here
is definitely not meant this way, quite the contrary. As the matcher
described here by you has chances to become part of R7RS (large), we
should try everything to get it right. The R7RS (large) effort has
started to become (together with R7RS (small)) among other things a
better version than R6RS, so it is crucial that the specs voted into
are self-contained and defined by clear semantics and not by a sample
implementation. And if it just clings at the availability of an
updated version of the library, I will write one if need must and no
one else volunteers.

Marc