From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#43100: 28.0.50; pcase not binding variables conditionally Date: Sat, 29 Aug 2020 12:06:15 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10496"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Philipp Stephani , 43100@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 29 18:07:14 2020 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 1kC3Np-0002d6-LT for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Aug 2020 18:07:13 +0200 Original-Received: from localhost ([::1]:53672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kC3Nn-0003cd-Qd for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Aug 2020 12:07:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kC3Nf-0003cN-9C for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2020 12:07:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37384) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kC3Nd-0003qD-ML for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2020 12:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kC3Nd-0003Rp-Hk for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2020 12:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Aug 2020 16:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43100 X-GNU-PR-Package: emacs Original-Received: via spool by 43100-submit@debbugs.gnu.org id=B43100.159871718613209 (code B ref 43100); Sat, 29 Aug 2020 16:07:01 +0000 Original-Received: (at 43100) by debbugs.gnu.org; 29 Aug 2020 16:06:26 +0000 Original-Received: from localhost ([127.0.0.1]:48930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kC3N3-0003Qz-SQ for submit@debbugs.gnu.org; Sat, 29 Aug 2020 12:06:26 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1054) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kC3N1-0003Qm-GV for 43100@debbugs.gnu.org; Sat, 29 Aug 2020 12:06:24 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 902B5809C0; Sat, 29 Aug 2020 12:06:17 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D8C788073F; Sat, 29 Aug 2020 12:06:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1598717175; bh=xgMP1NHOZG3DzJnMJY76YQsY+HSFbm1Uo+jTnoJCN6Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=o0phF5oC+k14y8i9f3DN3fsXdZvfo3iDDvNO7jMaahPklFwtV16GNIFjs711gCoTf 2j/y9ZP6W19xJ7kE2iPZDwakHlDZteyzKqMG2xcUgDwmT2NmUQgNAgJ8o2Fi7oIHfS 7g2koxQoWz6agns+YDxA2kTvirr/dGod5qo8BVye/sIpMRSbc+ShUJaDp8PluMQJ3x cflbpnpQCfbA8yCpeNKcoVtTya0VWFQg9VNfh1qZClP7aC8B5LsvL3o17PPozpdSyF WCQhXIs9TOUAivEaGnS2/BLvSn5p72w8wAxNaLckoA6JkCqyTSxhCwJKo0BY+dsEL3 B7K98U5nYt3Qw== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9EA1F120314; Sat, 29 Aug 2020 12:06:15 -0400 (EDT) In-Reply-To: (Pip Cet's message of "Sat, 29 Aug 2020 14:27:51 +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" Xref: news.gmane.io gmane.emacs.bugs:186651 Archived-At: >> > I'm having trouble with pcase's behavior. >> > >> > (pcase "a" >> > ((or (pred symbolp) name) >> > (let ((foo 'bar)) name))) >> > >> > throws an error. It shouldn't. >> >> Isn't this case documented in the manual? The last section of >> https://www.gnu.org/software/emacs/manual/html_node/elisp/pcase-Macro.html >> states: >> "It makes no sense for each sub-pattern [in an `or' sequence] to >> let-bind a different set of symbols because the body forms have no way >> to distinguish which sub-pattern matched and choose among the >> different sets." > > Thanks for pointing this out. > > I disagree with what the documentation says there: it does make > perfect sense, to me, to conditionally shadow a (lexical) let binding > with a pcase-let one, and body forms will have no trouble in practice > distinguishing between the outer and the inner let-binding. How do you expect them to distinguish? IIUC you want (pcase V ((or (pred symbolp) name) (let ((foo 'bar)) name))) to behave like (cond ((symbolp V) (let ((foo 'bar)) name)) (t (let ((name V)) (let ((foo 'bar)) name)))) ? I'd rather not go there since it means that the single occurrence of the `name` identifier in the branch's body refers to two different variable bindings depending on which pattern was matched. It smells of dynamic scoping, tho it is admittedly compatible with lexical-scoping but only at the cost of having to duplicate the branch's body. The "intended" behavior instead would be to behave like (cond ((symbolp V) (let ((name nil)) (let ((foo 'bar)) name))) (t (let ((name V)) (let ((foo 'bar)) name)))) That's already the behavior you get if you switch the two: (macroexpand '(pcase V ((or (and (pred foo) name) (pred symbolp)) (let ((foo 'bar)) name)))) => (let* ((pcase-0 (lambda (name) (let ((foo 'bar)) name)))) (cond ((foo V) (funcall pcase-0 V)) ((symbolp V) (funcall pcase-0 nil)) (t nil))) the fact that the behavior depends on the order of elements in `or` is an undesirable side effect of the implementation technique. > Things like the behavior of > > (pcase-let ((`(,a ,@b) (list 3 4))) > a) > > just seem puzzling to me. There are good reasons not to implement > sublist matching (though I don't think those reasons are sufficient > not to have a simple implementation anyway), I don't know of a simple implementation. > so an error message would be acceptable, You're probably right. > Sorry for complaining. Here's a patch. LGTM, Stefan