Subject: Re: bug#75594: 31.0.50; [FR]: Change equality test for Pcase non-linear patterns

From: Eshel Yaron <[email-masked]>
Date: Thu, 16 Jan 2025 07:50:39 +0100

Stefan Monnier <[email-masked]> writes:

>> I want to use non-linear pcase patterns to match against source code
>> with el-search, and I find the existing equality test that Pcase
>> generates in such cases too strict (it uses eql, and I need equal).
>
> Funny, I was reminded yesterday that this equality test is `eql` whereas
> Pcase uses `equal` "everywhere else".
>
>> What do you think about (1) switching to equal,
>
> On the principle, I'm in favor (I think that's what we should have
> used all along), but the problem is the risk of breaking existing code.
>
>> or (2) allowing pcase callers to specify the equality predicate?
> [...]
>> The patch below adds a pattern (cheq EQ) that succeeds while changing
>> the equality predicate to EQ for subsequent patterns on the same branch.
>
> Making the semantics of the VAR pattern depend on whether some other
> pattern has been seen earlier or not strikes me as hideous (tho clearly
> the non-linearity-becomes-an-equality-constraint is exactly doing that).
>
> I can see two possible syntax options:
>
> 1- some kind of "contextual" pcase macro like
>
>     (with-equality-predicate #'equal
>       `(,foo ,foo ,foo))
>
> 2- some kind of VAR pattern but annotated with an equality predicate in
>    case this is not the first use of this identifier, so you'd write
>
>     `(,(var foo #'equal) ,(var foo #'equal) ,(var foo #'equal))

Both options sound good.  The need to repeat the equality predicate
multiple times in option 2 makes it slightly less preferable, but it
maybe it'd be easier to document/explain.

Thanks,

Eshel