bug#47261: Fwd: bug#47261: Destructuring with Pcase without assigning values

[Earl Hyatt]

For the record, I am forwarding this reply to the bug tracker. I forgot
to send the original message to the tracker.

-------- Forwarded Message --------
Subject: Re: bug#47261: Destructuring with Pcase without assigning values
Date: Sat, 17 Apr 2021 18:50:10 -0400
From: Okam <okamsn@protonmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>

On 4/16/21 11:22 PM, Stefan Monnier wrote:
>
>>> The `pcase` macro itself uses this function, so it should hopefully be
>>> "good enough", but let me know if it's causing you trouble.
>> This seems to work well for my use case. Thank you for making this change.
>
> You're welcome.  It was actually a good change for the code's
> readability as well.
>
>> Are the variables always given in the order that they appear in the
>> pattern?
>
> I don't know.  Why? >
>> If not, is finding elements of the form "(\, SYMBOL)" enough to
>> identify variables in a Pcase pattern?
>
> No.  , is not even one of the core pcase patterns, it's only something
> used within the ` pattern (which is not a core pattern either; it is
> defined via `pcase-defmacro`).
>
>
>          Stefan
>

In the `cl-loop`-like macro that I am writing, things are currently set
up so that variables being assigned values in accumulation clauses can
be automatically used as the return value of the macro.

      ;; => ((1 3 5) (2 4 6))
      (loopy (flag pcase)
             (list i '((1 2) (3 4) (5 6)))
             (collect `(,a ,b) i))

This behavior requires finding the variables in the correct order.

The getting of the variables used ("a" and "b" above) can be done when
using the new `pcase-compile-pattern`, if the variables are fed to the
CODEGEN argument in the order that they are written, or I can try to
find them manually, if possible.

If neither are possible, then I will just remove this behavior.

Thank you.