From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#68509: 30.0.50; pcase-dolist matches backquote pattern incorrectly Date: Mon, 19 Feb 2024 10:51:45 -0500 Message-ID: References: <87a5p5l3jm.fsf@localhost> <9bc2bd05-5fdb-9d5a-3d98-c344c7275027@gmail.com> Reply-To: Stefan Monnier 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="14182"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Ihor Radchenko , 68509@debbugs.gnu.org To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 19 16:53:35 2024 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 1rc5xX-0003Qt-7W for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Feb 2024 16:53:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rc5wk-0002B3-8K; Mon, 19 Feb 2024 10:52:46 -0500 Original-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 1rc5wg-0002AI-B0 for bug-gnu-emacs@gnu.org; Mon, 19 Feb 2024 10:52:43 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rc5wf-0002Az-VD for bug-gnu-emacs@gnu.org; Mon, 19 Feb 2024 10:52:42 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rc5x1-00076K-1Q for bug-gnu-emacs@gnu.org; Mon, 19 Feb 2024 10:53:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Feb 2024 15:53:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68509 X-GNU-PR-Package: emacs Original-Received: via spool by 68509-submit@debbugs.gnu.org id=B68509.170835793727179 (code B ref 68509); Mon, 19 Feb 2024 15:53:03 +0000 Original-Received: (at 68509) by debbugs.gnu.org; 19 Feb 2024 15:52:17 +0000 Original-Received: from localhost ([127.0.0.1]:43226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rc5wH-00074J-86 for submit@debbugs.gnu.org; Mon, 19 Feb 2024 10:52:17 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rc5wE-00073y-Jk for 68509@debbugs.gnu.org; Mon, 19 Feb 2024 10:52:16 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5C85080841; Mon, 19 Feb 2024 10:51:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1708357906; bh=HnwDE3qOsqFUF6iDe7RSQV628u7qjsYVDE6m+yh/gII=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nRdDw3lRv2qVGfxEONaSnuYV9rbLuBm3GRxWZZFvQJoRqsvh76vmm1xRW3P1J/2XR raUUrSaTSHXmqqQeAXAUSQMYsG83i4EiPjcpZfBNRyJ0ZnvWMSBtbSN0P3iu++P1Ex Y9LAmh0rluLKwNrwLN1rCg6+r4Q666O4jYD7L82ZOdT/eMeHCsIPD8942qCdc66NQO z1ynQ3uC1kgUuj+ZC5IVRxEINIuOIfpqgA5WzkVIBfgkNCYeGa6bwAt6Fwo2IaPAxy sQOrevskJU6+5K3YHiiZLjwmm89rIgXRQElOuFCztVOJxww7516jXStJWP1s/cskYd /Pu97eQ8LwUdQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 522548014F; Mon, 19 Feb 2024 10:51:46 -0500 (EST) Original-Received: from milanesa (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2976E12012E; Mon, 19 Feb 2024 10:51:46 -0500 (EST) In-Reply-To: <9bc2bd05-5fdb-9d5a-3d98-c344c7275027@gmail.com> (Jim Porter's message of "Tue, 16 Jan 2024 08:52:27 -0800") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280273 Archived-At: >> Consider the following >> (pcase-dolist (`(,(and (pred stringp) a) . >> ,(and (pred stringp) b)) >> '(("TODO") ("DONE" . "a"))) >> (warn "%S :: %S" a b)) >> Executing the above yields >> =E2=9B=94 Warning (emacs): "TODO" :: nil >> =E2=9B=94 Warning (emacs): "DONE" :: "a" >> even though ("TODO") does not match the pattern. > > This isn't an issue with 'pcase-dolist', but rather a known/intentional > limitation of 'pcase-let': Indeed, I consider the above a pilot error. `pcase-dolist` and `pcase-let` use Pcase patterns to do *destructuring*, which is a different task than the one done by `pcase` (which decides whether a value matches a pattern or not). >> 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. > I do think we should fix it somehow though. This behavior is > extremely confusing, and as much as I'm a fan of 'pcase', I'm > emphatically *not* a fan of how this part works. I'm quite happy with the way it works when you use it as intended. But I'm not really satisfied either with the way it behaves when the coder doesn't understand its semantics, nor about the way we document that semantics. The difficulty in resolving this can be illustrated with the following pattern: `(a . ,b) This pattern leads to two tests: (consp VAL) and (eq 'a (car VAL)). When destructuring, we want to throw away both tests (we want to throw away most tests, except those needed to choose between two `or` branches). We could decide to emit a warning because we silently skip the `eq` test, which would help the coders understand that the pattern doesn't do what they think. But emitting that same warning because we silently skip the `consp` test would be really annoying because rewriting the pattern to avoid this is impractical. For a human, it's pretty easy to distinguish those two cases. But it's difficult to provide a precise definition that distinguishes those two case= s. We could also keep the tests and emit a warning or even an error when they fail, but if that's the behavior you want, then you should arguably use `pcase(-exhaustive)` instead. Stefan