Email list hosting service & mailing list manager

Re: Lexical scope of pattern variables is not strictly respected in the sample implementation Marc Nieper-Wißkirchen (02 Sep 2020 05:48 UTC)

Re: Lexical scope of pattern variables is not strictly respected in the sample implementation Marc Nieper-Wißkirchen 02 Sep 2020 05:47 UTC

Am Mi., 2. Sept. 2020 um 00:08 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Tue, Sep 1, 2020 at 11:08 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>>
>> (1) We lose compatibility with the original Wright matcher and other
>> descendants like Racket's.
>
>
> We've already broken compatibility with Wright in unlikely cases by
> adding new matching rules (***, *.., =..).  This is I think also an unlikely
> case in practice and so the decision should be what is more useful in
> practice.
>
> The Racket matcher already differs wildly in almost all cases (except
> when the entire pattern is quasiquoted), so any compatibility there is
> pretty meaningless.

Both true for concrete macros that use extensions of either matcher.
But while there are differences in the details, the overall semantics
(and the mental model) have been compatible so far.

>> (2) The Wright matcher has clear semantics. The semantics currently
>> implemented by your match is hardly that clear. For example, in a list
>> pattern that contains a predicate, the pattern variables on the left
>> will be available, but not those on the right.
>
>
> Yes, it would have to be specified as a letrec*-style semantics.
>
>>
>> (3) The proposed new semantics is complicated even more by the
>> presence of ellipsis patterns.
>
>
> That is a little weird but could be specified.

And you have to add another exception for "not" patterns.

> Anyway, I'm not arguing for this, I was just stating my preference.
> I won't be the one writing the spec or fix either way :)

One day I may find time to write match.

Marc