bug#70597: Problem in pcase-let?

[Bruno Barbier <brubar.cs@gmail.com>]

Hi Marco,

Marco Antoniotti <marcoxa@gmail.com> writes:

> Hi Bruno
>
> Thank you for the reply, but sorry.  IMHO it is a bug,  At a minimum,
> because pcase and pcase-let behave differently.

> I may be inclined to accept the explanation that the documentation about
> pcase-let allows for the behavior I find incorrect; that does not mean that
> the behavior is what is normally expected.
>
> Pattern matchers do ... pattern matching.  If you allow quasiquotes or
> "incomplete specifications" (pick your preferred pattern matching
> terminology), then you should honor the expectations; hence two symbols
> that are not eq do not match.

So, you would prefer for pcase-let to always signal an error if a
pattern doesn't match.  It makes sense.

And it looks like the issue has already been raised: see bug#19670.
   (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19670)



> Also note that I do not have any star (*) operators in my examples.

Thanks for mentionning this.  I now see that you carefully crafted
your HTML version, but, I only used the text version (that is less
readable and contains plenty of stars).  Sorry about the noise,
explaining how to parse generated lightweight markup as elisp :)


> Again, the machinery is there, cfr, the example below, which selects the
> second clause.
>
> ELISP>
>
> *(pcase '(1 2 3 4)           (`(1 2 ,x 5) (list 42 x))           (`(1 ,x 3
> 4) (list 666 x)))*
> *(666 2)*

I'm not sure it's that obvious: pcase doesn't really make a difference
between match and no match:

     (eq (pcase 'b (`a t) (`b nil))
         (pcase 'c (`a t) (`b nil)))
     ==> t


If your request is really like bug#19670, further discussion should
probably go there.

All the best,
Bruno