On Fri, Jan 22, 2021 at 7:57 AM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> We are back to the question whether an identifier appearing in a pattern should be bound to the match in subsequent patterns or just in the body of the match clause. To recollect, the original Wright matcher was clear about it: A pattern variable becomes bound in the body. This is also the behavior of the Racket matcher, which is another extension of Wright's original matcher.
>
> The implementation underlying this SRFI behaves differently. A pattern variable is bound as soon as it appears, which means that it is available in patterns standing right of the pattern variable. I don't think that this behavior is a good one. Firstly, it breaks compatibility with the original matcher and other descendants. Secondly, it entangles two very different orderings: The lexical order, in which variables are bound and the sequential order in which elements in a list to be matched are represented. For example, given a matcher M that matches lists, I may want to derive a matcher M* that matches the same lists but in reverse order. It should work just to reverse the top-level lists appearing in the matcher clauses, but with the current implementation behavior, it doesn't universally. Thirdly, the exact binding behavior of the current implementation is not even easy to grasp and looks more like an implementation artifact. In a pattern followed by the ellipsis, binding of the pattern variables is actually postponed. Fourthly, even with the `var` feature one cannot easily bind a pattern variable named `var` or `and` with the matcher's current implementation.
>

Well, I tried to write the spec so that it was general enough to cover
both the implementation we have, and an implementation that doesn't
allow non-linear patterns. I used Gauche's util.match (which is based
on the Wright matcher) to run all the code in the srfi with
non-linear-pred, non-linear-pattern, and non-linear-field all set to
false. I did run into some problems, but I can't remember if they were
all related to the new syntax (util match only has ... and ..k
ellipsis patterns and doesn't have unquote-splicing, I think) or if
there were other problems, I'll check again.

> Therefore, we should really correct the specification so that it matches the original one (and Racket's) and so that its semantics are easy and simple. When this is done, we can then correct the implementation. (I'm repeating myself here, but a given implementation should not be the driving force behind a specification, but it should really be the other way round.)
>

On the other hand, there is also an emphasis on having an
implementation. And the current implementation is pure syntax-rules
and works in R7RS small and R6RS. I looked at Wright's implementation,
at Gauche's re-implementation and at the Racket matcher and I don't
think any of them would work with R7RS small (I could be wrong). I
think there is a place for a pattern matcher that, even if it doesn't
have all the features one might like, is usable by a wide variety of
Schemes with only syntax rules (and three implementation-dependent
record introspection macros). It's also possible that there could be
SRFIs that implement/document other matchers with other features, and
then an all-in-one SRFI (like SRFI 211).

I do think if we should either fix var, specify that it is an error to
use it outside a macro, or get rid of it.

> Marc
>