Am Mo., 7. Sept. 2020 um 11:14 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Sun, Sep 6, 2020 at 11:30 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>>
>> But I have to admit that I am not totally convinced about multiply
>> occurring pattern variables. For simple patterns, it looks like a
>> clear case but for more complicated patterns like those we are
>> discussing here, it is not at all clear. Moreover, picking out
>> `equal?` to compare two bindings is a bit arbitrary (yet likely the
>> best arbitrary choice).
>
>
> It's the same comparison used for literals.  If you want a method
> to override one, it should change both.

For literals, the situation is slightly different. At least as for the
literals defined in R7RS, the equivalence predicate `equal?` is fully
defined and does the expected (I guess so) thing. General duplicated
pattern variables could be bound to records or one of the many new
data types found in R7RS (large).

Allowing just any equivalence predicate for literals would be highly
counter-intuitive the way literal patterns are written.

>> Explicitly writing down the comparison and
>> using an explicit failure continuation (through =>) looks like a
>> better, clearer approach to me. Perhaps, non-linear patters could be
>> made into an optional feature of this SRFI.
>
>
> Optional features still need to be specified, that doesn't really help you.

What I mean is that if it is an optional feature, it still leaves some
room for experimentation. It doesn't feel like there has been enough
experimentation/discussion going on so that duplicate pattern
variables suggest themselves for mandatory standardization. Are there
any real-life use cases where they are really needed?

> You could restrict its use though.  In Wright's match, any duplicate
> reference is an error, in the current draft none is.  But we could say:
> "it is an error to refer to the same pattern variable both inside and
> outside an ellipsis or not pattern."
>
> With that restriction, no double ellipsis', and clarifying that side-effects
> in ? preds and = accessors are errors, the matching is deterministic.
> I don't think there is any need to specify order (except for `or' clauses,
> where order also matters for Wright's original match).

When the lexical environment where `pred` is evaluated depends on
which matchings have already taken place, an order has to specified.
But I still think that this change from Wright's matcher is a mistake.
Not only but also for performance reasons: an implementation should be
possible that binds all pattern variables in one single `let` around
the body.