Am So., 6. Sept. 2020 um 16:07 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Sun, Sep 6, 2020 at 12:35 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> In the following example
>>
>> (match '(1 2) ((a a ...) a)
>>
>> the sample implementation reports a match (and yields (2)).
>
>
> This was a bug (a premature optimization), fixed.

Thanks!

> Please file a bug report for Chibi in case I miss these mails.

Do you (anyone else) know whether one can CC Github when writing to
the SRFI 204 mailing list?

> There are more interesting cases you're not considering, like:
>
> (match '(1 2) ((a ... a) a)

Yes, I haven't checked all combinations yet.

> You might consider two interpretations, but what if there are more elements:
>
> (match '(1 2 3 1) ((a ... a) a)
>
> What is the second `a' compared against?
>
> 1. the first match (1)?
> 2. the last match (3)?
> 3. any of the matches?
> 4. all of the matches?
> 5. the list '(1 2 3)?
>
> The sample implementation does 5, which is at least consistent with any
> subsequent `a' in the body, but may not be the most intuitive.

As the first `a` is bound to the list (1 2 3), intuitively I would say
that the sample implementation does the right thing here.

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). 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.