GNU bug report logs - #75594
31.0.50; [FR]: Change equality test for Pcase non-linear patterns

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 75594 <at> debbugs.gnu.org
Subject: bug#75594: 31.0.50; [FR]: Change equality test for Pcase non-linear patterns
Date: Wed, 15 Jan 2025 19:48:14 -0500

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


Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.