GNU bug report logs -
#70597
Problem in pcase-let?
Previous Next
Full log
Message #14 received at 70597 <at> debbugs.gnu.org (full text, mbox):
Hi Marco,
Marco Antoniotti <marcoxa <at> 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
This bug report was last modified 1 year and 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.