bug#72328: [PATCH] Nested backquote in pcase

[Eli Zaretskii <eliz@gnu.org>]

> From: Thuna <thuna.cing@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>  72328@debbugs.gnu.org
> Date: Sun, 04 Aug 2024 23:27:52 +0200
> 
> >>> Thanks, but I think Stefan meant to say that we would need real-life
> >>> use cases to change the current behavior.  So if there are no such
> >>> cases, it makes the decision less likely.
> >>
> >> I don't see how Stefan's message could be interpreted that way.
> >
> > FWIW, I interpreted it that way too.
> 
> My understaning is that the utility of going through use cases for or
> against the new behavior is to determine whether it would be an
> improvement or not.  The absence of any such use cases does not mean
> anything in either direction, but simply that this is not a usable tool.

The existing implementation has an advantage up front, because it
exists and presumably can be used by some Lisp program.  We try very
hard not to break anyone's code, even if we are not aware of such
code, and therefore an incompatible change in behavior can be
justified only if there's a very good reason.  Thus the request for
real-life use cases.

AFAIU, those real-life use cases don't have to be from existing
packages, they can be from your own practice.  You just need to
explain why you needed the behavior you are requesting.

> Furthermore, just intuitively, why would the absence of users of a
> feature be a reason to not improve it?

Because the danger of breaking someone's code is not something we
ignore lightly.  So the improvement must be significant, and the use
case must be a practical one, to trump that.

> Note that I do not believe that there are no people who would be
> effected by this, positively or negatively.

We've learned from bitter experience that such arguments are usually
false.  IOW, we don't really know enough to make such assertions.

> > From what I understand, coming to decisions as a maintainer is not that
> > simple.  And Stefan had reasons to choose the current implementation.
> 
> The stated reasoning was that implementational simplicity was valued
> over symmetry with backquote.

That' too.  But the mere existence of the current behavior is also
important.

> Very well.  In that case, here's the original case which prompted me to
> look into how pcase's backquote behaves:
> 
> (defun macroexp-null (exp)
>   "Return non-nil if EXP will always evaluate to nil.
> This form does not take non-local exits or side-effects into account."
>   (pcase exp
>     ((or 'nil ''nil '#'nil '`nil ``,,(pred macroexp-null))
>      t)))
> 
> which without this change would read as:
> 
> (defun macroexp-null (exp)
>   "Return non-nil if EXP will always evaluate to nil.
> This form does not take non-local exits or side-effects into account."
>   (pcase exp
>     ((or 'nil ''nil '#'nil '`nil
>          `(,'\` (,'\, ,(pred macroexp-null))))
>      t)))

Thanks, now you just need to explain why you needed this code and what
did its caller do to require this.