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: Fri, 23 Feb 2024 09:58:55 -0500 Message-ID: References: <87a5p5l3jm.fsf@localhost> <9bc2bd05-5fdb-9d5a-3d98-c344c7275027@gmail.com> <87sf2xjezi.fsf@localhost> <871q98hiqa.fsf@localhost> <8734to8gov.fsf@localhost> <87o7cbz21n.fsf@localhost> <87jzmzyxlv.fsf@localhost> <87y1berrh6.fsf@localhost> <87bk87i8dc.fsf@localhost> 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="15566"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Jim Porter , 68509@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 23 16:12:04 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 1rdXDY-0003nu-0l for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Feb 2024 16:12:04 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rdXDC-0005UE-Tx; Fri, 23 Feb 2024 10:11:43 -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 1rdX1X-0004W2-DG for bug-gnu-emacs@gnu.org; Fri, 23 Feb 2024 09:59:39 -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 1rdX1X-00079y-53 for bug-gnu-emacs@gnu.org; Fri, 23 Feb 2024 09:59:39 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rdX1u-00088A-8K for bug-gnu-emacs@gnu.org; Fri, 23 Feb 2024 10:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Feb 2024 15:00:02 +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.170870037131124 (code B ref 68509); Fri, 23 Feb 2024 15:00:02 +0000 Original-Received: (at 68509) by debbugs.gnu.org; 23 Feb 2024 14:59:31 +0000 Original-Received: from localhost ([127.0.0.1]:46021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rdX1O-00085u-LU for submit@debbugs.gnu.org; Fri, 23 Feb 2024 09:59:31 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39004) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rdX1M-00085V-Qg for 68509@debbugs.gnu.org; Fri, 23 Feb 2024 09:59:29 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DA27A4416AA; Fri, 23 Feb 2024 09:58:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1708700337; bh=xBjF6abgLZ2QAzJvsw24b4VjKpltBb/pgg5rbj8ZLe0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UdH/wxGW/UWu59mdZTP/CdnRiXdcrtoPTS1VT9b0Iu1AnnkVp1lQ6/oid48el5QVD yhCj9xvUXBYYbLIYUXDO6RRJzichifpMh+Mmt8GN7UUDJmGIRE9LNlnMTnkpIk2d/t 27xnRNmkK0JA7kA5LhKcaFVfUc1MB4Z9a3iBw3L2C8EuHaRnKZl6iyzm5rxOcX9py1 V+zLCTlr5qyBMcdmNYVfCqxGK5l49QjVAmtIBqtm8VMnwQTtly/lUX0kMZXh2TZsls MqAxBGACOYHPeieVUblfAIUikliXWZ+XKWxuFiQBnHwU5CLMGqbnf67bTDp0WEK0YH EM8r5zUZ6NjUw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4A6DD4416DB; Fri, 23 Feb 2024 09:58:57 -0500 (EST) Original-Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2B56D120679; Fri, 23 Feb 2024 09:58:57 -0500 (EST) In-Reply-To: <87bk87i8dc.fsf@localhost> (Ihor Radchenko's message of "Fri, 23 Feb 2024 14:05:19 +0000") 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:280497 Archived-At: >> How 'bout the patch below? >> ... >> +The precise behavior when the object does not actually match the pattern >> +depends on the types, although the body will not be silently skipped: ^^^^^ pattern >> +either an error is signaled or the body is run with some of the >> +variables bound to arbitrary values like @code{nil}. >> +For example, the above pattern will result in @var{x} and @var{y} >> +being extracted with operations like @code{car} or @code{nth}, so they >> +will get value @code{nil} when @var{my-list} is too short. In contrast, >> +with a pattern like @code{`[add ,x ,y]}, those same variables would >> +be extracted using @code{aref} which would signal an error if >> +@var{my-list} is not an array or is too short. > > This is confusing. In particular, "for example" implies that other > situations are possible. It is unclear how the reader will know when > "variables bound to arbitrary values" happen, when variables are bound > to nil, and when an error is signaled. This part of the doc is generic, so it can't guarantee anything: the behavior depends on the actual pattern and the way that pattern is defined. In order to intuit what will happen, the reader needs to guess which primitives are used to extract the info from value (e.g. `car/cdr/nth` for cons cells, `aref` for arrays, ...). > I would re-structure the paragraph, explicitly listing the possible > outcomes when the PATTERN does not match VALUE and stating that any > other non-matching PATTERN will lead to undefined outcome. Could you try to do that? [ I've found back-and-forth modifications of docs give better results than single-sided writing. ] > Also, with the current behavior of `pcase-let', it appears to be > impossible to distinguish between too short list (1 2 3) and > (1 2 3 nil nil) when assigning destructuring pattern. Destructuring by definition can't do "distinguish", so that's not a big surprise =F0=9F=99=82 But of course, this isn't really true, you can do: (pcase-let ((`(,x ,y ,z . ,tail) FOO)) (if (equal tail '(nil nil)) ... ...)) or you can get hairy and do things like: (pcase-let (((or `(,x ,y ,z ,a ,_) (and `(,x ,y ,z) (let a 'shortorlonglist))) FOO)) (if (eq a 'shortorlonglist) ... ...)) but that kind if Pcase pattern, while possible, is rarely worth the trouble. Stefan