From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Okam via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#47261: Fwd: bug#47261: Destructuring with Pcase without assigning values Date: Mon, 19 Apr 2021 22:10:28 +0000 Message-ID: References: <08c47ffc-58a3-d4f9-eae1-61a672d45b44@protonmail.com> <1dacded9-3e40-bc02-56c7-a157d739ffb7@protonmail.com> <4925d1a5-4669-8290-e534-1662f13ca183@protonmail.com> Reply-To: Okam Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10972"; mail-complaints-to="usenet@ciao.gmane.io" To: 47261@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 20 00:11:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lYc6q-0002ls-6y for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Apr 2021 00:11:12 +0200 Original-Received: from localhost ([::1]:50540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYc6p-0004ad-8d for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 18:11:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57878) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYc6g-0004aR-VO for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 18:11:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40749) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYc6g-0008Gb-Md for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 18:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lYc6g-0000wh-HH for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 18:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Okam Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Apr 2021 22:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47261 X-GNU-PR-Package: emacs Original-Received: via spool by 47261-submit@debbugs.gnu.org id=B47261.16188702423607 (code B ref 47261); Mon, 19 Apr 2021 22:11:02 +0000 Original-Received: (at 47261) by debbugs.gnu.org; 19 Apr 2021 22:10:42 +0000 Original-Received: from localhost ([127.0.0.1]:52295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYc6M-0000w7-2P for submit@debbugs.gnu.org; Mon, 19 Apr 2021 18:10:42 -0400 Original-Received: from mail-40133.protonmail.ch ([185.70.40.133]:29955) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYc6J-0000vs-Pd for 47261@debbugs.gnu.org; Mon, 19 Apr 2021 18:10:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1618870233; bh=5JOSoiPyztfACKFQrjhB9/jLsIzgKWvYQPQkhg/Qqcc=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=l1rbzJTyQMapBMO3svN5c021M1ayOk+B1LaULA9VktOmVDp8OhNi+Yen4i9BYLEX+ W45eT60ymPulBk7Y6nVb0a8ow6dJVvSguR7RJtbwy7N+tu42V/HS0BgBR/QoFU6iJ8 C7Miijbz6xvhNiUzb3hNAiL2YPr0fAGq/XHPu5d8= In-Reply-To: <4925d1a5-4669-8290-e534-1662f13ca183@protonmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" X-ACL-Warn: , Okam Xref: news.gmane.io gmane.emacs.bugs:204516 Archived-At: 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 To: Stefan Monnier 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. >> >> ;; =3D> ((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 ;; =3D> (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`.