bug#72328: [PATCH] Nested backquote in pcase

[Thuna <thuna.cing@gmail.com>]

>> > And this change would break the symmetry between `backquote' the macro
>> > and backquote patterns in `pcase'.  This is an important design idea.
>>
>> I am not quite sure why you think that this breaks symmetry with the
>> backquote macro;
>
> We want that something like this works as expected:
>
> #+begin_src emacs-lisp
> (let ((a 1) (b 2))
>   (pcase `(69 foo (97 ,a ((,b))))
>     (`(69 foo (97 ,a ((,b))))
>     (list a b)))) ==> (1 2)
> #+end_src

I feel like there is a possible misunderstanding.  I am not preventing a
backquote pattern from going deeper into a list.  Your example would
remain perfectly consistent under the new behavior.  What *wouldn't*,
however, is something like

(let ((a 1) (b 2))
 (pcase `(69 foo `(,bar ,,a ((,,b))))
   (`(69 foo `(,bar ,,a ((,,b))))
    (list a b))))

Which currently errors on two counts: 1. ,,a in the pattern first
expands the initial , as though it escape the backquote pattern (not the
one before (,bar...) but the one before (69...))  and tries to match the
object - which is (\, 1) - against the pattern ,a which is of course
nonsense so the macroexpansion fails.  2. ,bar in the pattern tries to
match the corresponding object - which is (\, bar) - against the pattern
`bar' which binds the object - once again (\, bar) - to `bar'.

Do you disagree that the result of this form should also be (1 2)?

> I think it's obvious what I mean with symmetry between backquote and
> pcase backquote without giving a formal definition.

Unless our definitions of symmetry are different, the example above is a
clear situation where the current behavior does not have symmetry with
the backquote macro.

> It indeed gets ugly when one wants to match a non-constant
> backquote expression using a backquote pcase pattern with partial
> unquotes (the "mixed case").
>
> But making pcase backquote patterns less expressive just to make this
> special case simpler doesn't make sense to me.  OTOH I agree that having
> a convenient solution for this kind of problem would be nice.

The drawback of this new behavior would be that you could not match,
say, the unevaluated object ``10 against ``<some-pattern> where
<some-pattern> indicates an integer, as ``,,(pred integer) would match
against a `(,'\` (,'\, ,(pred integer))).  We can still match it, but
only with the same ugly syntax as before: `(,'\` ,(pred integer)).

While this is not ideal, I still consider the new behavior an
improvement.