From unknown Sat Sep 06 10:20:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns Resent-From: hokomo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Dec 2022 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 59887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 59887@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.167043297310821 (code B ref -1); Wed, 07 Dec 2022 17:10:02 +0000 Received: (at submit) by debbugs.gnu.org; 7 Dec 2022 17:09:33 +0000 Received: from localhost ([127.0.0.1]:51145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2xvJ-0002oT-2p for submit@debbugs.gnu.org; Wed, 07 Dec 2022 12:09:33 -0500 Received: from lists.gnu.org ([209.51.188.17]:53384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2xvE-0002oN-UW for submit@debbugs.gnu.org; Wed, 07 Dec 2022 12:09:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2xvE-0004Qz-Nm for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 12:09:28 -0500 Received: from [37.120.193.124] (helo=mail.cock.li) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2xvA-00061t-Ia for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 12:09:28 -0500 User-agent: mu4e 1.8.9; emacs 28.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1670432957; bh=Vv+K9mEPoe2Vp79v5QU9wVFtqjbfe/BMFG/gFvfvMtI=; h=From:To:Subject:Date:From; b=Za1n/FRpfRahUfa1jK2Gg5+z30gzxPNw+m8n7WMPjtIG+sW+myMQ6JxF/zX1FUqIB 9IubIQJblfJrkoP/amkTdpinuDk6zj+07uPKq6Xqwo8kSN0ewdZO0W8+W17Z0YP3WQ VA3kWhARwMTwek6DXJ6AHhULJJC4667rejpmXn0iSAqRyj66TRSjDtpa0eoW4ypKOE 1NI/YHM7urgiSDPWnKTuAO4L4BLyVPTTs0QBuQMp4vMwKrVNZloxjYfeQauAY4hrhH 9zrCpxmMR40WjQBOEhVuQt5kMkT7EYzU8LkkglDZ2Qu/s6UjCRhSGriOVswNftzT9h Tu9GcbLaebs1A== From: hokomo Date: Wed, 07 Dec 2022 17:28:57 +0100 Message-ID: <87sfhrqgxw.fsf@airmail.cc> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Host-Lookup-Failed: Reverse DNS lookup failed for 37.120.193.124 (failed) Received-SPF: pass client-ip=37.120.193.124; envelope-from=hokomo@airmail.cc; helo=mail.cock.li X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, How exactly is the underscore symbol treated in pcase's backquote-style patterns? Seems like at least pcase and pcase-let treat it inconsistently (I haven't checked the other pcase operators). pcase treats the underscore as a literal symbol to match, hence this fails: (pcase '(1 2 3) (`(1 _ ,x) x)) ;; => nil Adding the missing comma in front of the underscore gives us the expected behavior: (pcase '(1 2 3) (`(1 ,_ ,x) x)) ;; => 3 However, pcase-let is less strict about this, producing the same result with or without the comma: (pcase-let ((`(1 _ ,x) '(1 2 3))) x) ;; => 3 (pcase-let ((`(1 ,_ ,x) '(1 2 3))) x) ;; => 3 Additionally, I would think one would still be able to match a literal underscore symbol even with pcase-let, but the following still ends up matching: (pcase-let ((`(1 ,'_ ,x) '(1 2 3))) x) ;; => 3 I think that matching a literal underscore symbol is rare enough that the ideal behavior would probably be for an underscore within a backquote template to be treated as a wildcard whenever it appears literally (e.g., `(1 _)) or unquoted (e.g., `(1 ,_)). However, as soon as explicitly quoted (e.g., `(1 ,'_)), it should be treated as a match for a literal underscore symbol. In other words, I would expect the following would be different from the above: (pcase '(1 2 3) (`(1 _ ,x) x)) ;; => 3 (instead of nil) (pcase-let ((`(1 ,'_ ,x) '(1 2 3))) x) ;; => nil (instead of 3) I'm not 100% sure if these requirements would cause any backwards-incompatible changes or inconsistencies with the other pcase operators though. I'm also assuming that `(1 _) and `(1 ,'_) can be distinguished, but maybe this is not true? hokomo From unknown Sat Sep 06 10:20:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Dec 2022 02:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: hokomo Cc: 59887@debbugs.gnu.org Received: via spool by 59887-submit@debbugs.gnu.org id=B59887.16705546642932 (code B ref 59887); Fri, 09 Dec 2022 02:58:02 +0000 Received: (at 59887) by debbugs.gnu.org; 9 Dec 2022 02:57:44 +0000 Received: from localhost ([127.0.0.1]:60695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3Ta4-0000lE-E7 for submit@debbugs.gnu.org; Thu, 08 Dec 2022 21:57:44 -0500 Received: from mout.web.de ([212.227.15.3]:51435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3TZy-0000l5-VC for 59887@debbugs.gnu.org; Thu, 08 Dec 2022 21:57:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1670554652; bh=AlFW0mRP5TuqAwZRHVSYdXzRYkNMat2cV+eYUo+tYxo=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=EXQHivJI017f2s9RcNH/MVshkl8V9Z9vPEb8BBgJPQ9P3v78qtqCX7Kw3hDj6xQ/A et5O930s+MFTH9Cx3d2DDlpM7a+39GxBpAqj5s+uMwZ2nHe7hRyq3gSssGBo9OVYnU UdF+NYuKE/Bl02pJmnQXTHQly1EWbQBDeNeX+SlXj2OnatqGYOvWBlQpyJ590js/df GFKdMIUiw/wt1Qr9+rEDIYXxjdrEF/sDjmomrItghskW3GqguVWEhK5I1CCwOBo2fq seA3FY/NI1byYFs94AelZh+pkItlFxGLY+oyoEtoZ3nHkNRYcxm8bfmCF9G05nLAhO HYHEbyXfP0/mA== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([92.76.229.140]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MlsON-1ocdQ03zW7-00iyGL; Fri, 09 Dec 2022 03:57:32 +0100 From: Michael Heerdegen In-Reply-To: <87sfhrqgxw.fsf@airmail.cc> (hokomo@airmail.cc's message of "Wed, 07 Dec 2022 17:28:57 +0100") References: <87sfhrqgxw.fsf@airmail.cc> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 09 Dec 2022 03:57:31 +0100 Message-ID: <87edt9nv1g.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:PHHCEdeey8qSGKsIwuOKGP5V0MD+g3GFa20Fen2aO4MWVNv6gXI y14YmHNXSayPILyZu/eU6H3n3E164U6UiBOvmY0LjZnwmArvZx/yumDrO8rBG5YHg3hRYzZ JDoQhyGroNSK0uU4xsH6wqoLR2q+FXwkqsV9FgcU4HMqEYGpNp96q6WSHllXpSEkJJ6pi6G BRgYBCGCQFhJhCJ9LlwDg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:bb1KcLmidAE=;tV5JPZ6a+flxA6eEyngHB55tV72 tvgZyzhaFtUP/ndBKlnNzsr6t4zHQb2+PXYAeSwvEEoofAv7LWWdnYXPCcGDrmV84ukfpmBQ4 YEhiiMNbG/qEIwjLyzwtinUSX4gr8L51l9gF9gwox09s8bE9IIcNfs8163uEJeSSC7GlIiPMp rL0NSpJe/D+kMJ5dZyjnKFVYb+LQt6AB8xPzZBO87dIwTjzwNT67p7093RMv+ynhgJl3lrTdY kSARirgqPDJtJQeGoyjTkc9Xc2pMc9jHX6pVCJjX8JRm4SCpvEBEyS3KdeeDb2I9WgLmtFWTp zfCxNQcuNB8ZcHQ58NbK3NLC71htXIvdtHRaBwslaVd4rn0eH6orxCwODzhOt2fcVZpIAZ3n/ CQ/jONCqDl7dwLX6aE+Jdi0TiQPCg6EfBT1/nPUxzkjuypRAG0r/xSrxQacAPRodE3Y7drtdE xzNhunGgR2lcdwsCDlf4K4h60NxykofpUNF1IgTelGfvLFXDvQ1GaRVYeylCzXOvtyFMP8K9J pu2g5R41opSoGI2oaxqxrNuQZ6OPvLektoKICPQnm6OZlNYd3ut/+/p/LrAXMlpWmqup0VUgi jTCoTcZXjgmzfPlXttTsca1Ll6W4z6+OoB5Fb4P9tIxvucEEKmbPVyiVnQnQLwotNGYbNjb46 b+fdtwuHwhk2yACFpBSu5n4W79OKs4Fuer1RnKvyFIBSUyZfVVX1YGe3ZDmf0cTAyfRqwlLy+ UtBkdY1/fr+gME/lCTPROQSsTsD0EhsE6t9voBdi5Evt6BpRge1mJguzPPmL2BXAKGUgxMdB3 C6/Ni5Zy7bHJZ/szMdxGLUsal4x8/GI2ZYd0lyCHbCICcE1rqMKHZgAWFA/Mn3NiBcXyiP03+ ozs8jBpU9RBS8JdJ081NNYpzr9jbozaWM24KMONhI8XS1nQ/kLXxzuRpNKzx0LT4ggMTbUmlR zQI9dmC4sUutlf3n4nMBgMraUu8= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) hokomo writes: > However, pcase-let is less strict about this, producing the same > result with or without the comma: > > (pcase-let ((`(1 _ ,x) '(1 2 3))) > x) > > ;; => 3 > > (pcase-let ((`(1 ,_ ,x) '(1 2 3))) > x) > > ;; => 3 Note this part of the `pcase-let' documentation string: | Each EXP should match (i.e. be of compatible structure) to its | respective PATTERN; a mismatch may signal an error or may go | undetected, binding variables to arbitrary values, such as nil. Your first case is invalid because the pattern doesn't match the value. Here it goes undetected and bindings get established. This behavior is not perfect, but AFAIR it has been preferred over the less efficient code that better checks would mean. So it's the programmer's task to use only matching patterns. This is not really a restriction because `pcase-let' is intended to create bindings, not for testing whether a pattern matches some value. > I think that matching a literal underscore symbol is rare enough that > the ideal behavior would probably be for an underscore within a > backquote template to be treated as a wildcard whenever it appears > literally (e.g., `(1 _)) or unquoted (e.g., `(1 ,_)). However, as soon > as explicitly quoted (e.g., `(1 ,'_)), it should be treated as a match > for a literal underscore symbol. This idea had been discussed in the past. It had some votes but it had been decided not to implement such a feature because it would not really fit into the existing semantics, just for the sake of leaving out one ",". So I'm afraid I don't think we will change this. Michael. From unknown Sat Sep 06 10:20:41 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: hokomo Subject: bug#59887: closed (Re: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns) Message-ID: References: <87v8mhmj26.fsf@web.de> <87sfhrqgxw.fsf@airmail.cc> X-Gnu-PR-Message: they-closed 59887 X-Gnu-PR-Package: emacs Reply-To: 59887@debbugs.gnu.org Date: Mon, 12 Dec 2022 02:51:01 +0000 Content-Type: multipart/mixed; boundary="----------=_1670813461-25244-1" This is a multi-part message in MIME format... ------------=_1670813461-25244-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #59887: pcase vs. pcase-let: Underscore in backquote-style patterns which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 59887@debbugs.gnu.org. --=20 59887: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D59887 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1670813461-25244-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 59887-done) by debbugs.gnu.org; 12 Dec 2022 02:50:53 +0000 Received: from localhost ([127.0.0.1]:49751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4Yu5-0006Yv-Eh for submit@debbugs.gnu.org; Sun, 11 Dec 2022 21:50:53 -0500 Received: from mout.web.de ([212.227.17.12]:53787) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4Yu1-0006Yp-5a for 59887-done@debbugs.gnu.org; Sun, 11 Dec 2022 21:50:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1670813442; bh=FJnq60cuojeIrya5YDF75n65z339sVlzMWS4SDIdkrA=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=HCaLLU5GaX+Sm7ylGzrQqKxIWhZA8GA/2g3qccNjHzTMNlCUorNw8CBrV7Uw/bxa8 0OKqJevCroMr7fJmPSTDUcd1vz31GMdEZS7MLm+YvGN+vZ/bnIZO90pqxpC8tkGXav mHfIDAmEnIRDgIkhbZ8W92huC5FVG1861y93tHjcPHw0g2R1e+J3c6Zncg4ZbWhPuZ rw4ubPGa1QSiDxMFRf0INGyF85VC+1p0WWxGOhdNKbQTLcjEYdLZw6Uu2tCuGOHDxc YALBij172Z4Id+DONkJmRi3kp/C0uWgaB0MOexgznQMVG5MsDSFi/ZFcKIlgI9P81S sCicwQ5t/YEwQ== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([92.76.229.140]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MALeD-1pFKHZ14LD-00BlhF; Mon, 12 Dec 2022 03:50:42 +0100 From: Michael Heerdegen To: hokomo Subject: Re: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns In-Reply-To: <87sfhrqgxw.fsf@airmail.cc> (hokomo@airmail.cc's message of "Wed, 07 Dec 2022 17:28:57 +0100") References: <87sfhrqgxw.fsf@airmail.cc> Date: Mon, 12 Dec 2022 03:50:41 +0100 Message-ID: <87v8mhmj26.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:KgL1pFrytV6Ls263WL9yKSoLg10uL15yPewuVpVYZI7koWwiDbl /JDBxdTK/zFeyRbO8n21d2LeMMYYwh9WoZea8Y/CODxDrvsgJSYgJDEpwRoGDzL3L3DOJKS wmlmJmAW75wJrFP56vP+pW5BOGU7+g1m1Bc9ua0yE4LvgdUxj8obIP4wRzgrED2HHV/SN3y yLG6s0957CMkTW+IfYyCA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:xU2I0G1nnIE=;QmuDJrNrXUMzNkwomY/DGJh+pMb LKTOTlPGHfuPD4O2+u2BBBO5R1RiL0aa6HSVcnutwPl91WSwiNoVxwopEswUzydflFJN6FCWe VQVpYaMwXV4fGnTSnHEhxObZkFvGStMW+VtUV6SCJU+4zL1TEc2yRvWUSI24i+8QgCELVsA80 lUCHKKqM8XCIvSWzSkalbs3xr/TUxax1b0cmbouRw+G2AeujhDSFcFFcVsFe31n7CcZNONnTr c5hgDbi5rn1sV4nt1j4/deA7YW/cU8c5kEOO+29Msrhi8X+QR9H1Xyh4r3XAR86uF9CZTKWY3 pRV+d02hZfB8AQK3QLzoECJ4a5Oa+SI1Ke3vH9fbic11BVpYqsC0PSBGebUzX1UnCo+F+50N4 eS8oiCKD3Fbh0DWzOOKnwCoo5w0hpexhf2xGMv8MtZ7FHwTdXJsYyeihqM2NYp9rFljMgnI+P 1mK9GvLeRd2v+OWA4P8PU3xvqcH4m4/T6jelZo857+BQkx0HFE8QZbh36DpdoKBD4osnxIaWz wcsL8vPt9EbJ3gXhPHmOxH5jniX2LTHmooxnyvrfNsF0gvCyI6wifzzkla3etc8SYFAF2PeuC h6QxuC0PbQkMWOvjvCS2fv3j1/MIoT3rjHqtF5bS13OuVzyIHIJBfF/RWRrxlzlNyy5oyiSNo OnATeHl6RoJKPKtyv0l9ykSMT9JRt/SV3JWu1M3xrFRm5N81APe0WMhw2+8kQsZPye9XsVvQ9 tSr6gZ4dxSUY7OMduIBbvu2+61ZVoIf9rhTq9Pp1vFKIkcao+iHj+4tSk5y3roW4lEPsmYAq0 l3wQr0Lj0tMn8fo44ziHU+/qkj/RyRIBZ+/jvHO9czuKyn3OwTvVgjt/aTKNKzEUU3tws1Q8e IbLZelGLzKK404S1b2yg8yuewLt51FbHboq0cYus/gPKwRLSHswYTGVfEs35EImSvbA2Exw7u gY6pFQ== X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 59887-done Cc: 59887-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) hokomo writes: > How exactly is the underscore symbol treated in pcase's > backquote-style patterns? I think the current behavior can be understood and explained from the documentation quite well. If you can point to something concrete missing, please elaborate, and we can reopen this report. For now I'm closing it: everything works as documented, and we had decided not to complicate the semantics of `_`, so as far as I see it nothing is to be done here. Thanks, Michael. ------------=_1670813461-25244-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 7 Dec 2022 17:09:33 +0000 Received: from localhost ([127.0.0.1]:51145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2xvJ-0002oT-2p for submit@debbugs.gnu.org; Wed, 07 Dec 2022 12:09:33 -0500 Received: from lists.gnu.org ([209.51.188.17]:53384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2xvE-0002oN-UW for submit@debbugs.gnu.org; Wed, 07 Dec 2022 12:09:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2xvE-0004Qz-Nm for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 12:09:28 -0500 Received: from [37.120.193.124] (helo=mail.cock.li) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2xvA-00061t-Ia for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 12:09:28 -0500 User-agent: mu4e 1.8.9; emacs 28.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1670432957; bh=Vv+K9mEPoe2Vp79v5QU9wVFtqjbfe/BMFG/gFvfvMtI=; h=From:To:Subject:Date:From; b=Za1n/FRpfRahUfa1jK2Gg5+z30gzxPNw+m8n7WMPjtIG+sW+myMQ6JxF/zX1FUqIB 9IubIQJblfJrkoP/amkTdpinuDk6zj+07uPKq6Xqwo8kSN0ewdZO0W8+W17Z0YP3WQ VA3kWhARwMTwek6DXJ6AHhULJJC4667rejpmXn0iSAqRyj66TRSjDtpa0eoW4ypKOE 1NI/YHM7urgiSDPWnKTuAO4L4BLyVPTTs0QBuQMp4vMwKrVNZloxjYfeQauAY4hrhH 9zrCpxmMR40WjQBOEhVuQt5kMkT7EYzU8LkkglDZ2Qu/s6UjCRhSGriOVswNftzT9h Tu9GcbLaebs1A== From: hokomo To: bug-gnu-emacs@gnu.org Subject: pcase vs. pcase-let: Underscore in backquote-style patterns Date: Wed, 07 Dec 2022 17:28:57 +0100 Message-ID: <87sfhrqgxw.fsf@airmail.cc> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Host-Lookup-Failed: Reverse DNS lookup failed for 37.120.193.124 (failed) Received-SPF: pass client-ip=37.120.193.124; envelope-from=hokomo@airmail.cc; helo=mail.cock.li X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, How exactly is the underscore symbol treated in pcase's backquote-style patterns? Seems like at least pcase and pcase-let treat it inconsistently (I haven't checked the other pcase operators). pcase treats the underscore as a literal symbol to match, hence this fails: (pcase '(1 2 3) (`(1 _ ,x) x)) ;; => nil Adding the missing comma in front of the underscore gives us the expected behavior: (pcase '(1 2 3) (`(1 ,_ ,x) x)) ;; => 3 However, pcase-let is less strict about this, producing the same result with or without the comma: (pcase-let ((`(1 _ ,x) '(1 2 3))) x) ;; => 3 (pcase-let ((`(1 ,_ ,x) '(1 2 3))) x) ;; => 3 Additionally, I would think one would still be able to match a literal underscore symbol even with pcase-let, but the following still ends up matching: (pcase-let ((`(1 ,'_ ,x) '(1 2 3))) x) ;; => 3 I think that matching a literal underscore symbol is rare enough that the ideal behavior would probably be for an underscore within a backquote template to be treated as a wildcard whenever it appears literally (e.g., `(1 _)) or unquoted (e.g., `(1 ,_)). However, as soon as explicitly quoted (e.g., `(1 ,'_)), it should be treated as a match for a literal underscore symbol. In other words, I would expect the following would be different from the above: (pcase '(1 2 3) (`(1 _ ,x) x)) ;; => 3 (instead of nil) (pcase-let ((`(1 ,'_ ,x) '(1 2 3))) x) ;; => nil (instead of 3) I'm not 100% sure if these requirements would cause any backwards-incompatible changes or inconsistencies with the other pcase operators though. I'm also assuming that `(1 _) and `(1 ,'_) can be distinguished, but maybe this is not true? hokomo ------------=_1670813461-25244-1-- From unknown Sat Sep 06 10:20:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns Resent-From: hokomo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Dec 2022 18:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 59887-done@debbugs.gnu.org Received: via spool by 59887-done@debbugs.gnu.org id=D59887.16708704748843 (code D ref 59887); Mon, 12 Dec 2022 18:42:01 +0000 Received: (at 59887-done) by debbugs.gnu.org; 12 Dec 2022 18:41:14 +0000 Received: from localhost ([127.0.0.1]:54641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4njl-0002IZ-Ko for submit@debbugs.gnu.org; Mon, 12 Dec 2022 13:41:13 -0500 Received: from [37.120.193.124] (port=60274 helo=mail.cock.li) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4njg-0002IR-RF for 59887-done@debbugs.gnu.org; Mon, 12 Dec 2022 13:41:12 -0500 References: <87sfhrqgxw.fsf@airmail.cc> <87v8mhmj26.fsf@web.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1670870461; bh=8Uhp969u6iGVX4pdcqAdTSWQ4e+sz6+05NJ9fehD65g=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=L4s2NHAg+mr1Q2krNzG3FhO2KRaH+BOdy5Iu2vuFq79hP0uGdcuzgP6Kiwbz9WHIx KDd/BYM8ETOVH4h5UleUfM2E+XedBXvzGotZrYxBTgex/fFpTQ9WEyusjhWI9izg1M 76hwE7dXHu2NqkP2ee+1TLdcWyYvJ/UX1ynZ6km89i/rAOijUVmlx2TgfuLhCL/BBA I4VxQuiKc1Of6omaCu/AsFyk2dD/KPH3/UWTg2EINa5O5s1TJ0MlexWOcbPb+sSslW 2tTQXMm7ac1EECtj7rBPZYK8qmhkKOypH01DjkyAvbd3HCYau7Ug/Ngmd3AqQ+AuM6 6ra3tkf2YejRQ== User-agent: mu4e 1.8.9; emacs 28.2 From: hokomo Date: Mon, 12 Dec 2022 19:26:28 +0100 In-reply-to: <87v8mhmj26.fsf@web.de> Message-ID: <87pmco8nyc.fsf@airmail.cc> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Note this part of the `pcase-let' documentation string: > > | Each EXP should match (i.e. be of compatible structure) to its > | respective PATTERN; a mismatch may signal an error or may go > | unde [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [37.120.193.124 listed in wl.mailspike.net] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Note this part of the `pcase-let' documentation string: > > | Each EXP should match (i.e. be of compatible structure) to its > | respective PATTERN; a mismatch may signal an error or may go > | undetected, binding variables to arbitrary values, such as > nil. > > Your first case is invalid because the pattern doesn't match the > value. > Here it goes undetected and bindings get established. I see! That clarifies the behavior I was seeing. > This behavior is not perfect, but AFAIR it has been preferred > over the > less efficient code that better checks would mean. So it's the > programmer's task to use only matching patterns. This is not > really a > restriction because `pcase-let' is intended to create bindings, > not for > testing whether a pattern matches some value. I suppose that's a fair tradeoff. > This idea had been discussed in the past. It had some votes but > it had > been decided not to implement such a feature because it would > not really > fit into the existing semantics, just for the sake of leaving > out one > ",". So I'm afraid I don't think we will change this. Right, it doesn't seem like such a huge win now that I understand that the behavior of pcase-let was according to its specification and there was no inconsistency to begin with. It would maybe make the code a little bit easier to read in certain cases, but I can see your point. > I think the current behavior can be understood and explained > from the > documentation quite well. If you can point to something > concrete > missing, please elaborate, and we can reopen this report. Your quote above made everything clear, but I completely missed it since I was reading the Emacs Lisp manual's explanation [1] rather than pcase-let's docstring. Maybe it would be beneficial to include the above quote in the manual as well. [1] Thanks! hokomo From unknown Sat Sep 06 10:20:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Dec 2022 01:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: hokomo Cc: 59887-done@debbugs.gnu.org Received: via spool by 59887-done@debbugs.gnu.org id=D59887.167089429323555 (code D ref 59887); Tue, 13 Dec 2022 01:19:01 +0000 Received: (at 59887-done) by debbugs.gnu.org; 13 Dec 2022 01:18:13 +0000 Received: from localhost ([127.0.0.1]:56825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4tvw-00067r-H4 for submit@debbugs.gnu.org; Mon, 12 Dec 2022 20:18:12 -0500 Received: from mout.web.de ([212.227.15.4]:60107) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4tvt-00067j-8g for 59887-done@debbugs.gnu.org; Mon, 12 Dec 2022 20:18:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1670894279; bh=sFI9NSIpiPpumwEFxh40lOBe5qW8e5Rn6i5PzBY7McA=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=VUXkEHibUA7SQzHeBFjqMpRjW6aBKuPOx6lhvPj94jKR6ZHX6p+52tCWMBdXF4Ixd E8OBbAf7LJYiemJ8CLSqzBMQtJNMgemjEsyRiY+SiSHApyOk9Hy/0eImtaa/Xw3Q8i rD7BOQh0kPLtjjAryzhfKpYs29+kOmu7eSscSRvIhZZAoMn7olwuECXaSSnpXyMZ0P AdthxGb/YCx3V8uSTh/NVTgTe8pKwgpIQ9kcclwmMQRAf8/IeA01xqfV0tPoejK8EO qdNbsGSwoihjEg3qcnF4Ui2J8rGoY081IZyDaayVNpXAHeg/SfvgZEZhDfkgJVbj8Y jH60wwB6nGdbA== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([92.76.229.140]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MW9ra-1pSVKv1drG-00XdTs; Tue, 13 Dec 2022 02:17:59 +0100 From: Michael Heerdegen In-Reply-To: <87pmco8nyc.fsf@airmail.cc> (hokomo@airmail.cc's message of "Mon, 12 Dec 2022 19:26:28 +0100") References: <87sfhrqgxw.fsf@airmail.cc> <87v8mhmj26.fsf@web.de> <87pmco8nyc.fsf@airmail.cc> Date: Tue, 13 Dec 2022 02:17:56 +0100 Message-ID: <87edt42jaz.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:be11BG356nORjMjgdHZA72SKDzM15o2cwGahd9akdDxre9uEv5v Se0RdP2j6xy/c6juJkGaAZ3AvOSKSWP4VfkWZSsojjPrm/7+zAPHSIsyWqG6iuOKyUSrmRB nFjgq20SN/SZ5smDJOexHclNi9Jk7ZHkgCS4i/IqzYipjusckpNUG35yEeWdwZ1ASS/o2KH swapLfyMHyV4OnrAaPFvQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:oN92XXmUDpc=;qAhNrZ3Ry1qeLiJdlEIN8xG6Wau Pj4gNIJDGZcdlK6qSP8nG0U9z9TUDRRvfZGxGWWsMifx6Rtyb/sc9mVtDlQZ7wmG/kVN6mrid OR0T6lAUQt0HdWwpoSuTluV9KnCyjFhcYlqrZenNKG8/RB6e4GCJ/GgSA89s/yCRGI83tCsZm Y7zy3pbYkedWhDKjaOYxY/evRNhYjvxxmqzg9pGORmHS3Jd7/oHqfSJbL2vluPbNiX/NoldEG zUMz8MZesyGpNsQgqEf3DvbZULfWZSk1pQbNr6lY/OiWHboC37Y6F2qhVOUauJeQi1dFftmb2 j+3kJtCpozWju6gIB+v2jXuRrnc+/QbVBRq0cBJFa94IRNjV9GKcHNdDRxwux+GzpJ8Mktm4u tSIRZ6JmHLpu10r2lGGuorXVewsSProfUEHbWSLhIPTnegmHE1cX4tEt/o2kEh3MBkH9SIDzc I4yZH12HwkmXXSmLd8IkrYJILGkj3B1T1JD4qIjdYf7z8ogh3eAxh0FITEcTJRlBgsLSN2Krd YxAZT1b52H0WQhkI/QGScW276vPdzgiUUyj6939AoIigzQX1BgRMSHfFVLSkqei0DfagcovQO UTpcrE+dEC9WsDdHeWlc5CM8eniOwTezNfBbofLK8gwGBYEC08iFIrgjsLZg79pWenkxfEZSb s2LJa/wgcfLewdkWrp8rZyfNCobYSzyw1d/UR55ONjFHuFHdiC1S3FbIUFBrxzvND4sGJsBf2 Auz6F7Dn/9Z8evdLzrpRRuTy+qafPjdL1MTESboEgy0VPdV/i/7eAGsSWpRK0bRXRXBj3GwTZ oIgk2KwfdXOc0wFgao2AWNCiMGkky3syCdUXmesXWfrZKXs/prfKsTXvBjIcBWq4uLDTaQF5S V43fU1fBylaKsZIXvyeJUlHcGt3mhyAwn4R5+hqZkmuSt58uw4PQujtlUopuzbf4j1M0QBbDR Tgp4vA== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) hokomo writes: > Your quote above made everything clear, but I completely missed it > since I was reading the Emacs Lisp manual's explanation [1] rather > than pcase-let's docstring. Maybe it would be beneficial to include > the above quote in the manual as well. > That says: | The macros described in this section use =E2=80=98pcase=E2=80=99 patte= rns to perform | destructuring binding. The condition of the object to be of compatible | structure means that the object must match the pattern, because only | then the object=E2=80=99s subfields can be extracted. For example: |=20 | (pcase-let ((`(add ,x ,y) my-list)) | (message "Contains %S and %S" x y)) |=20 | does the same as the previous example, except that it directly tries to | extract =E2=80=98x=E2=80=99 and =E2=80=98y=E2=80=99 from =E2=80=98my-list= =E2=80=99 without first verifying if =E2=80=98my-list=E2=80=99 | is a list which has the right number of elements and has =E2=80=98add=E2= =80=99 as its | first element. The precise behavior when the object does not actually | match the pattern is undefined, although the body will not be silently | skipped: either an error is signaled or the body is run with some of the | variables potentially bound to arbitrary values like =E2=80=98nil=E2=80= =99. That explains the same thing quite broadly. Maybe you did not notice the implications when you first read it? I dunno, I'm not that good in writing documentation, but I can't find something to add from what we had discussed that would not be redundant. Or should we maybe just warn about the possible pitfall a bit more offensively? Michael. From unknown Sat Sep 06 10:20:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns Resent-From: hokomo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Dec 2022 01:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 59887-done@debbugs.gnu.org Received: via spool by 59887-done@debbugs.gnu.org id=D59887.16708958501553 (code D ref 59887); Tue, 13 Dec 2022 01:45:02 +0000 Received: (at 59887-done) by debbugs.gnu.org; 13 Dec 2022 01:44:10 +0000 Received: from localhost ([127.0.0.1]:57003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4uL3-0000Oz-Re for submit@debbugs.gnu.org; Mon, 12 Dec 2022 20:44:10 -0500 Received: from [37.120.193.124] (port=60902 helo=mail.cock.li) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4uKz-0000OV-8k for 59887-done@debbugs.gnu.org; Mon, 12 Dec 2022 20:44:08 -0500 References: <87sfhrqgxw.fsf@airmail.cc> <87v8mhmj26.fsf@web.de> <87pmco8nyc.fsf@airmail.cc> <87edt42jaz.fsf@web.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1670895838; bh=GUtLc+NnAsn8PIkg7VpFH38qoL4Zyr0i/piQlOFJKFo=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=dQJD7f5o6gpGrDMKNBKt04qk77KpkDZARKt1L85mbrkLIbPEeKAeJdDLWIHVHRHPG vsEhwWmfGoQbRjJOCL4E31ZUUL1AuveBhv21H13CHCyrQyUQGuwWS63R8kwFdf3XcP qzOB5bJzntMof00h1QHAkGRj1mDw3Iui3jqPRKYwwmi3UAkiAPJGJ2ALrdWJ/OnI54 JjX1143wLHO401WQYmLEbmlDEH3L9VTmBrmFGDA3t3oO71Mf3ucsPSc1Mdal4k7urw eyFA/jyVzmFj6asOETXjAMhKaxy0LEqJqtXXmVm7DGpyzUdb707uc84NRZW118h3/u WDCrEtdwsATUg== User-agent: mu4e 1.8.9; emacs 28.2 From: hokomo Date: Tue, 13 Dec 2022 02:19:22 +0100 In-reply-to: <87edt42jaz.fsf@web.de> Message-ID: <87lenc84df.fsf@airmail.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > That says: > > | The macros described in this section use =?UTF-8?Q?=E2=80=98pcase=E2=80=99?= patterns > to perform > | destructuring binding. The condition of the object to be of > compatible > | structure means that the [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [37.120.193.124 listed in wl.mailspike.net] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > That says: > > | The macros described in this section use =E2=80=98pcase=E2=80=99 pat= terns=20 > to perform > | destructuring binding. The condition of the object to be of=20 > compatible > | structure means that the object must match the pattern,=20 > because only > | then the object=E2=80=99s subfields can be extracted. For example: > | > | (pcase-let ((`(add ,x ,y) my-list)) > | (message "Contains %S and %S" x y)) > | > | does the same as the previous example, except that it directly=20 > tries to > | extract =E2=80=98x=E2=80=99 and =E2=80=98y=E2=80=99 from =E2=80=98my-li= st=E2=80=99 without first verifying if=20 > =E2=80=98my-list=E2=80=99 > | is a list which has the right number of elements and has =E2=80=98add= =E2=80=99=20 > as its > | first element. The precise behavior when the object does not=20 > actually > | match the pattern is undefined, although the body will not be=20 > silently > | skipped: either an error is signaled or the body is run with=20 > some of the > | variables potentially bound to arbitrary values like =E2=80=98nil=E2=80= =99. > > That explains the same thing quite broadly. Maybe you did not=20 > notice > the implications when you first read it? I dunno, I'm not that=20 > good in > writing documentation, but I can't find something to add from=20 > what we > had discussed that would not be redundant. That indeed describes it nicely. Somehow I managed to miss that=20 whole paragraph and instead skipped directly to the documentation=20 string of pcase-let. My bad... :-) > Or should we maybe just warn about the possible pitfall a bit=20 > more > offensively? Hmm, I understand the concern about being redundant, especially=20 since all four of the listed functions have the same behavior, and=20 documenting it for one would mean documenting it for each one. Perhaps including a variation of the phrase "Each EXP should match=20 (i.e. be of compatible structure)" in each of the four=20 descriptions would hint at this behavior while not being overly=20 verbose? From that point the user can search for "compatible" on=20 the same page and immediately find a match in the text at the top=20 that explains the constraints. hokomo From unknown Sat Sep 06 10:20:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Dec 2022 02:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: hokomo Cc: 59887-done@debbugs.gnu.org Received: via spool by 59887-done@debbugs.gnu.org id=D59887.167089811912066 (code D ref 59887); Tue, 13 Dec 2022 02:22:02 +0000 Received: (at 59887-done) by debbugs.gnu.org; 13 Dec 2022 02:21:59 +0000 Received: from localhost ([127.0.0.1]:57153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4uvf-00038Y-AX for submit@debbugs.gnu.org; Mon, 12 Dec 2022 21:21:59 -0500 Received: from mout.web.de ([217.72.192.78]:55433) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4uvc-00038S-Mu for 59887-done@debbugs.gnu.org; Mon, 12 Dec 2022 21:21:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1670898109; bh=staBi3cOG6/RVcBAe1HuiRfqq6Wk18owgkybodshDb4=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=fyUdo4WN9yKWtNeUrBchKm1HiNTV3flgNd1FRjPyeMg6xCCly2rqMyTp4CCLo7g6E r7XB6xBy6NjzR4tM3oIpLpBBE2JXWdtStp4TaMjrklOONkduBfvPWTDA7ZWh/jVjic P98v+WQZxaNTUGSoeQc5uh2NdV7SCXYrvplbxwgCe1LxdlAh4DbJUApXR89oKJOfH+ tWA/deOclTF4U0hwwCPZZ/+RM3oJJCTI55Gv4LyBgo5ydjtumkRF2mjlLAuRLwfoOI di3d4BaqYSn6F/ZwNIehTQmkedNFfN+ebTJWdvv//b43bBYtloVrBXvf0aQ7m3GUNh APGemHmi5/Z4A== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([92.76.229.140]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1M3Eut-1p5knp41TZ-003YGH; Tue, 13 Dec 2022 03:21:49 +0100 From: Michael Heerdegen In-Reply-To: <87lenc84df.fsf@airmail.cc> (hokomo@airmail.cc's message of "Tue, 13 Dec 2022 02:19:22 +0100") References: <87sfhrqgxw.fsf@airmail.cc> <87v8mhmj26.fsf@web.de> <87pmco8nyc.fsf@airmail.cc> <87edt42jaz.fsf@web.de> <87lenc84df.fsf@airmail.cc> Date: Tue, 13 Dec 2022 03:21:45 +0100 Message-ID: <87a63s2gcm.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:wUW3EyRQZWmJbMDLpVcXbIO8DZP4UoDU5XhyOzIP7a3p58A9kZz QfiSwudPuvhaaw+iA3n1Da4wyL1V33k1B64oKakdvPg8n+jZxQy5d3HyEbTEOcVM/C9rwKF ky+FM+hG6PGdYSMdI5UgVBGE2YkXNkIJXkDVWYQo2emIfCT/SyjSNOxiEnzMsuVUG6iAoSS wz1SsMSjv+p/E0uUy4WPg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:rZvGCGZsx8I=;X+ks/nZE+upv68CdnX7+hSiWNYS 2dMIMrKf/Wh9CSmQklHq26SCrusGEEsTa2AIghBHng5inH2SQyQy1dsA9jlgSZWIGn73NgS9R sKRdMA9QDtliSfA8wTlpcxelLH6OPkqT59hVllhuRiD/uhuubbU7QXOoo4I04cuKsF7h3jHHb A7JPmOJIClclixQanJNjyF8PURp43XyWcI5NVAnqBfCJ6BzJQtnaNB6cZsP53PN1LCh6eKQvk rczysxyw8Q7LWAeCGZ/6CLIAt6zaxJ0Vx2D8smNPocnJuS1bqo4KxW7qMYW+D2oy0+fpGsVEN ho2MNqGKAWqBEayU6c0ccmb7TIqtWFgNoEfjYPrHvmMO1Ye2DzctT1NE8qt8+Xj3zjMt1faZB zWJb+Q1L/1U5gtCc7VNOzTt4KaqVuq04Bdj3nEE/91Dx/2fpT3vCQH6ZubvPP3GQFECMPlVzS vyquboZIfe6/yjfmHxpwpNOdOv51q5vX/2zSrsX1VCBrkoapyt6qC5e9gTeFCKRQIPq4Bklb5 5+N1Lylp8aiCe5UGl1gSEJQtCcLxBln1jiW1E62AFcX2PvP8eakRll61V/PN3n1lwtn6QHu5k So0KhVd85FFeZJ3XQuiniyVgW7er0s7waG6aBWwe1osh0WorhZrYtyTibKXwIMwWyGBWIP4ha tLBvyiTMJPfWtZ0Y3Efi5zmtZWQEEkH7JAd76MOMQKwjzuh18G/xE25Y4si67mYVIvaF3pY1K QUGaZAEQzh2xNB3rKx/hU99nx9zSFcU5WRYIf4pK/wQZdxKB1J6e/eoZnf+mm0oaEuNg9nKIA vpbomAzRUWRFQW/HuK8PhvLvC4aoBj0VYR3GVj936tbiqihyNYxVliSXfzLhlpwC9Aie3FCcG 9R6Rcj9pAl73JmSjikQx1HlNWxN21IUxnhddONR42x9/BVXXv1Yzwobi+LrnDDC43C2lt788h p6R2ADvIFqhoT4H1wUJkUrsjij8= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) hokomo writes: > That indeed describes it nicely. Somehow I managed to miss that whole > paragraph and instead skipped directly to the documentation string of > pcase-let. My bad... :-) > > > Or should we maybe just warn about the possible pitfall a bit more > > offensively? > Perhaps including a variation of the phrase "Each EXP should match > (i.e. be of compatible structure)" in each of the four descriptions > would hint at this behavior while not being overly verbose? From that > point the user can search for "compatible" on the same page and > immediately find a match in the text at the top that explains the > constraints. My question is that when we make the text even longer, would that help people that don't read carefully (because we don't need to address others) at all? My second question is if that would have helped you at all, because your crucial misunderstanding was about the meaning of `_`. Using patterns in `pcase-let' that don't match generally doesn't make much sense, it's totally unclear what would happen in this case. That's another reason why I don't want to over-emphasize this case. Maybe saying that `_` is not special when used as a QPAT would make sense, in (info "(elisp) Backquote Patterns"). I mean in this paragraph: | =E2=80=98SYMBOL=E2=80=99 | =E2=80=98KEYWORD=E2=80=99 | =E2=80=98NUMBER=E2=80=99 | =E2=80=98STRING=E2=80=99 | Matches if the corresponding element of EXPVAL is =E2=80=98equal=E2= =80=99 to the | specified literal object. We could add that `_` is not special (no symbol is special as a qpat, actually). Would that give a useful hint? It seems that some people seem to expect that `_` is special everywhere in pcase. Michael. From unknown Sat Sep 06 10:20:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns Resent-From: hokomo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Dec 2022 02:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 59887-done@debbugs.gnu.org Received: via spool by 59887-done@debbugs.gnu.org id=D59887.167089958313102 (code D ref 59887); Tue, 13 Dec 2022 02:47:02 +0000 Received: (at 59887-done) by debbugs.gnu.org; 13 Dec 2022 02:46:23 +0000 Received: from localhost ([127.0.0.1]:57265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4vJH-0003PG-0h for submit@debbugs.gnu.org; Mon, 12 Dec 2022 21:46:23 -0500 Received: from [37.120.193.124] (port=36702 helo=mail.cock.li) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4vJ9-0003P7-VK for 59887-done@debbugs.gnu.org; Mon, 12 Dec 2022 21:46:22 -0500 References: <87sfhrqgxw.fsf@airmail.cc> <87v8mhmj26.fsf@web.de> <87pmco8nyc.fsf@airmail.cc> <87edt42jaz.fsf@web.de> <87lenc84df.fsf@airmail.cc> <87a63s2gcm.fsf@web.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1670899569; bh=ONQ9LCo46xmbLwVkRij+jjgrFst0+nDrc0kpasJ4u50=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=Wn5Kwcz30BG3kOpV6dmW8n0UhBPVakiIQc908BUHBA1ozgrFZBxLowvfqq1TDh2bC 81s6xP1758IdcxAe77TCAFdnOJ1LecH1E5CXJd82hU6k2AfG5KBQg9hQEdzByboDJy 0u37lrhdRJt7QEnBDuQGlV3Misu1a7RZaYBHHqHdZpIZ7jxIkcSg9CNbWH8rYHmart yxDyhVfwsgnQ1j0TwZ6qPCKw1f85BhF93it6fovXBI56P/vYqImIOdv/DYISF+jZu4 0Fs8h9IzU4QAJK9FGjKIjC+KG8IO761Qre0Q4juaipx3GePidUy7qP2RU69Mo2c4+8 OmsmKe/i0kpOw== User-agent: mu4e 1.8.9; emacs 28.2 From: hokomo Date: Tue, 13 Dec 2022 03:26:14 +0100 In-reply-to: <87a63s2gcm.fsf@web.de> Message-ID: <87h6y081hs.fsf@airmail.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > My question is that when we make the text even longer, would > that help > people that don't read carefully (because we don't need to > address > others) at all? I believe it would. Even though I should've been more careful with reading the whole page, one's first instinct (at least mine) when reading a reference manual is to jump directly to the operator in q [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [37.120.193.124 listed in wl.mailspike.net] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > My question is that when we make the text even longer, would=20 > that help > people that don't read carefully (because we don't need to=20 > address > others) at all? I believe it would. Even though I should've been more careful with=20 reading the whole page, one's first instinct (at least mine) when=20 reading a reference manual is to jump directly to the operator in=20 question and expect to find all of the necessary and essential=20 information there, whether it is a detailed explanation or just a=20 hint or short remark mentioning some concepts that were introduced=20 more thoroughly earlier in the manual. As an example, the beginning of the Handling Errors page [1]=20 describes, among other things, the meaning of the `debug' symbol=20 within a condition-case handler's condition list. However, the=20 description of condition-case specifically also includes the short=20 remark "which can include debug to allow the debugger to run=20 before the handler" which is useful to point the reader to the=20 description at the beginning (all it takes is searching for=20 "debug" on the same page after reading the remark). [1]=20 > My second question is if that would have helped you at all,=20 > because your > crucial misunderstanding was about the meaning of `_`. Using=20 > patterns > in `pcase-let' that don't match generally doesn't make much=20 > sense, it's > totally unclear what would happen in this case. That's another=20 > reason > why I don't want to over-emphasize this case. > > Maybe saying that `_` is not special when used as a QPAT would=20 > make > sense, in (info "(elisp) Backquote Patterns"). I mean in this > paragraph: > > | =E2=80=98SYMBOL=E2=80=99 > | =E2=80=98KEYWORD=E2=80=99 > | =E2=80=98NUMBER=E2=80=99 > | =E2=80=98STRING=E2=80=99 > | Matches if the corresponding element of EXPVAL is =E2=80=98equal= =E2=80=99=20 > to the > | specified literal object. > > We could add that `_` is not special (no symbol is special as a=20 > qpat, > actually). Would that give a useful hint? It seems that some=20 > people > seem to expect that `_` is special everywhere in pcase. That is indeed the core of the issue and I definitely think it=20 would be a good idea to have an explicit statement that the=20 underscore symbol is not special as a QPAT. You can sort of infer=20 it from the specification, but given the unspecified behavior of=20 pcase-let in the case of a non-match, making it explicit would be=20 nice. I think I would've ended up poking around pcase-let in any case=20 after being puzzled about its behavior, just out of curiosity.=20 Having a short remark about "structural compatibility" in the=20 documentation of the specific operator would then help me quickly=20 narrow down to what I need. hokomo