On Sat, Jan 23, 2021 at 4:03 AM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Sa., 23. Jan. 2021 um 00:34 Uhr schrieb Felix Thibault <xxxxxx@gmail.com>:
>>
>> 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
>
>
> The question of non-linear patterns is completely orthogonal to the issue we have been discussing.

I keep thinking that late binding is easier to implement if you don't
allow non-linear patterns, I thought that was a topic of discussion at
one point but maybe I just misuderstood.

>
>>
>> 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 don't understand this point. The original Wright semantics of late binding, which doesn't have the four problems I mentioned above, can be as easily implemented in a pure syntax-rules macro. In fact, it won't be too hard to adapt the current code to actually do this. There will be people to help you with it.
>

My general guide to what is easily implemented is what is implemented.
And to be honest, looking at the code for the Wright matcher, I'm not
the person to maintain a SRFI based on it. Someone else needs to do
that. Looking at Alex's code, it looks a lot like stuff I've seen
other places, and besides the documentation at the beginning, each
macro (most of which are just a few lines) is documented with
comments, so someone like me has a chance at getting some
understanding of what's going on.

On the other hand, all three (that is, the chez, slib, and scheme48
ones) versions of the WC matcher only have 145 lines of comments at
the beginning to explain matching to the user, and then there are
~2551 lines of uncommented code, most of which is one procedure that
snakes its way down the right side of the screen with an ocean of cxr,
gensyms, and (in the defmacros) variables with names like g261. And
since it contains syntax that is incompatible with R6RS for the same
reason the original version of this matcher was, there would still be
plenty to do inside that big procedure to fix that after converting.

I still don't see the problem with having one SRFI that covers this
matcher, since it is widely in use, and another that covers one or
more late-binding ones, and then an over-arching srfi that just
provides a framework for implementations to import whichever matcher
they are using. We already have this one done and a sexpr matcher done
with SRFI 200, and I think views is in the works.

>>
>> 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.
>
>
> The distinction of using it inside or outside a macro doesn't make much sense. What you would want to say, I believe, is that it can be made an error when `var` is used as a pattern variable. This, however, is opposed to the reason why `var` has been invented in the first place.

A big part of the reason for having var, I thought, was so you could
write a macro using match, and not have to worry about telling the
user about the excluded names. I mean, anyone using match has probably
seen the forbidden words list, and (var a), say, is kind of pointless.
So I was thinking it's only those people who are using match without
realizing it who are likely (well, slightly) to pass it one of those
forbidden words, like in the chunk macro. A lot of the syntax gets
sanitized with hygiene but not all of it, if you write:
(define-syntax test-no-var
   (syntax-rules ()
     ((_ syn ...)
       (begin
         (test-equal 1 (match '(1 1) ((syn syn) syn)))
         ...))))
a lot of things won't run [I'm not sure if anything will], whereas
wrapping syn in var makes everything run and all the tests pass
[except possibly ellipsis].

>
> Anyway, `var` just exhibits the symptom, so dropping it doesn't improve on the general problem.
>