GNU bug report logs - #47261
Destructuring with Pcase without assigning values

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47261 in the body.
You can then email your comments to 47261 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Okam <okamsn <at> protonmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Destructuring with Pcase without assigning values
Date: Fri, 19 Mar 2021 13:47:29 +0000

X-Debbugs-Cc: monnier <at> iro.umontreal.ca

Hello.

For a Pcase pattern, it would be convenient to have Pcase destructure
the pattern and have a way to see what values Pcase would like to assign
to variables within the pattern.

This would allow one to know the variables found in the pattern and to
manipulate the values that Pcase would like to assign, instead of just
letting `pcase` assign them.

This was asked about on the Help mailing list:
https://lists.gnu.org/archive/html/help-gnu-emacs/2021-03/msg00089.html

Thank you.

Message #8 received at 47261 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Okam <okamsn <at> protonmail.com>
Cc: 47261 <at> debbugs.gnu.org
Subject: Re: bug#47261: Destructuring with Pcase without assigning values
Date: Fri, 19 Mar 2021 17:45:00 -0400

> For a Pcase pattern, it would be convenient to have Pcase destructure
> the pattern and have a way to see what values Pcase would like to assign
> to variables within the pattern.
>
> This would allow one to know the variables found in the pattern and to
> manipulate the values that Pcase would like to assign, instead of just
> letting `pcase` assign them.

I massaged the code so that it now exports the following function:

    (defun pcase-compile-patterns (exp cases)
      "Compile the set of patterns in CASES.
    EXP is the expression that will be matched against the patterns.
    CASES is a list of elements (PAT . CODEGEN)
    where CODEGEN is a function that returns the code to use when
    PAT matches.  That code has to be in the form of a cons cell.
    
    CODEGEN will be called with at least 2 arguments, VARVALS and COUNT.
    VARVALS is a list of elements of the form (VAR VAL . RESERVED) where VAR
    is a variable bound by the pattern and VAL is a duplicable expression
    that returns the value this variable should be bound to.
    If the pattern PAT uses `or', CODEGEN may be called multiple times,
    in which case it may want to generate the code differently to avoid
    a potential code explosion.  For this reason the COUNT argument indicates
    how many time this CODEGEN is called."

The `pcase` macro itself uses this function, so it should hopefully be
"good enough", but let me know if it's causing you trouble.


        Stefan

Message #11 received at 47261 <at> debbugs.gnu.org (full text, mbox):

From: Okam <okamsn <at> protonmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 47261 <at> debbugs.gnu.org
Subject: Re: bug#47261: Destructuring with Pcase without assigning values
Date: Sat, 17 Apr 2021 01:24:11 +0000

On 3/19/21 5:45 PM, Stefan Monnier wrote:
> I massaged the code so that it now exports the following function:
>
>      (defun pcase-compile-patterns (exp cases)
>        "Compile the set of patterns in CASES.
>      EXP is the expression that will be matched against the patterns.
>      CASES is a list of elements (PAT . CODEGEN)
>      where CODEGEN is a function that returns the code to use when
>      PAT matches.  That code has to be in the form of a cons cell.
>
>      CODEGEN will be called with at least 2 arguments, VARVALS and COUNT.
>      VARVALS is a list of elements of the form (VAR VAL . RESERVED) where VAR
>      is a variable bound by the pattern and VAL is a duplicable expression
>      that returns the value this variable should be bound to.
>      If the pattern PAT uses `or', CODEGEN may be called multiple times,
>      in which case it may want to generate the code differently to avoid
>      a potential code explosion.  For this reason the COUNT argument indicates
>      how many time this CODEGEN is called."
>
> The `pcase` macro itself uses this function, so it should hopefully be
> "good enough", but let me know if it's causing you trouble.
>
>
>          Stefan
>

This seems to work well for my use case. Thank you for making this change.

Are the variables always given in the order that they appear in the
pattern? If not, is finding elements of the form "(\, SYMBOL)" enough to
identify variables in a Pcase pattern?

Message #14 received at 47261 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Okam <okamsn <at> protonmail.com>
Cc: 47261 <at> debbugs.gnu.org
Subject: Re: bug#47261: Destructuring with Pcase without assigning values
Date: Fri, 16 Apr 2021 23:22:57 -0400

>> 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

Message #17 received at 47261 <at> debbugs.gnu.org (full text, mbox):

From: Okam <okamsn <at> protonmail.com>
To: 47261 <at> debbugs.gnu.org
Subject: Fwd: bug#47261: Destructuring with Pcase without assigning values
Date: Mon, 19 Apr 2021 22:10:28 +0000

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: Sun, 18 Apr 2021 15:15:00 -0400
From: Okam <okamsn <at> protonmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>

On 4/17/21 7:37 PM, Stefan Monnier wrote:
>
>> 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.
>
> I still don't understand.  AFAICT what the (collect `(,a ,b) i) above is
> expected to do is something more or less equivalent to:
>
>      (push (car i) a)
>      (push (cadr i) b)
>
> right?
>
> So a CODEGEN which does
>
>     (lambda (varvals _count &rest _)
>       (mapcar (lambda (varval)
>                 `(push ,(cadr varval) ,(car varval)))
>               varvals))
>
> should do the trick, regardless of the order in which the vars
> are passed.
>
> I think I'm still missing something in your explanation.
>
>
>          Stefan
>

What I mean to say is that, if possible, I would like to add the
variables in the pattern to a list of values to return.  This requires
identifying the symbols which represent the variables.

Using CODEGEN works for setting the values, yes, and is not sensitive to
the order in which it receives variables. However, I am currently using
the CODEGEN step to add the variables to a list of returned values,
since CODEGEN is already being given the symbol for each variable.

I am trying to have it so that these variables are listed in the return
value in the same order that they are listed in the pattern.

For example, this

      ;; => (4 6)
      (loopy (flag pcase)
             (list i '([1 2] [3 4]))
             (sum `[,sum1 ,sum2] i))

currently expands to

      (let ((sum2 0)
            (sum1 0))
        (let* ((list-108 '([1 2] [3 4]))
               (i nil))
          (cl-block nil
            (while (consp list-108)
              (setq i (car list-108))
              (if (vectorp i)
                  (let* ((x109 (length i)))
                    (if (eql x109 2)
                        (let* ((x110 (pcase--flip aref 0 i))
                               (x111 (pcase--flip aref 1 i)))
                          (progn
                            (setq sum2 (+ x111 sum2))
                            (setq sum1 (+ x110 sum1)))))))
              (setq list-108 (cdr list-108)))
            (list sum1 sum2))))

where `sum1` and `sum2` are in the same order that they appear in the
pattern.  This works with what I have tested, but I am unsure of whether
it is dependable.

So, I am asking whether the variables passed to CODEGEN can be relied on
to be in a particular order for destructuring patterns, or whether there
is a good way to find the variables and their order manually.

For example, for `seq-let`-like destructuring, my experience is that the
variables are given in the reverse order and that variables can be
identified as symbols that are not `&rest`.

Message #20 received at 47261 <at> debbugs.gnu.org (full text, mbox):

From: Earl Hyatt <earl.hyatt <at> protonmail.com>
To: 47261 <at> debbugs.gnu.org
Subject: Fwd: bug#47261: Destructuring with Pcase without assigning values
Date: Mon, 19 Apr 2021 22:06:51 +0000

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 <at> protonmail.com>
To: Stefan Monnier <monnier <at> 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.

Message #23 received at 47261 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Okam <okamsn <at> protonmail.com>, 47261 <at> debbugs.gnu.org
Subject: Re: bug#47261: Destructuring with Pcase without assigning values
Date: Fri, 24 Jun 2022 20:36:16 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I massaged the code so that it now exports the following function:
>
>     (defun pcase-compile-patterns (exp cases)
>       "Compile the set of patterns in CASES.

Skimming this thread, it seems like this fixed the request, so I'm
closing this bug report.  (The discussion then went on to discuss some
things related to this feature, but if I understood correctly, Earl
adjusted his code to fit it.)  If I misunderstood, please respond to the
debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.