From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#43100: 28.0.50; pcase not binding variables conditionally Date: Sun, 30 Aug 2020 16:21:42 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26724"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philipp Stephani , 43100@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 30 18:23:10 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 1kCQ6n-0006qX-L8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 Aug 2020 18:23:09 +0200 Original-Received: from localhost ([::1]:35148 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCQ6m-0006C2-Nc for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 Aug 2020 12:23:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38210) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCQ6g-0006Bi-De for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2020 12:23:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39103) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kCQ6g-0003Zw-3L for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2020 12:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kCQ6f-00075K-TL for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2020 12:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Aug 2020 16:23: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.159880454627176 (code B ref 43100); Sun, 30 Aug 2020 16:23:01 +0000 Original-Received: (at 43100) by debbugs.gnu.org; 30 Aug 2020 16:22:26 +0000 Original-Received: from localhost ([127.0.0.1]:50649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCQ66-00074G-Dh for submit@debbugs.gnu.org; Sun, 30 Aug 2020 12:22:26 -0400 Original-Received: from mail-oo1-f43.google.com ([209.85.161.43]:35447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCQ64-000743-OX for 43100@debbugs.gnu.org; Sun, 30 Aug 2020 12:22:25 -0400 Original-Received: by mail-oo1-f43.google.com with SMTP id k13so548235oor.2 for <43100@debbugs.gnu.org>; Sun, 30 Aug 2020 09:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w07nNXECaXWljAI84FYLJ8MZMakE00ftqm/8EmghEng=; b=Iu6h+3p8lYul7D1cYx7XnEb5vRxiXxQ6TNFAF3tzf/IQetE2nMgE+CUQ8Fm1wKTd27 zWxFIa/uJrU5ZcqMVqhWpZ2jQlQthuR0xULBHJ1A7YlwKvRMa/f1cbTXFtq6phmrRZUJ IOddHO9Lk57EGB01mJKQV6+dZFVOlbFVne5FQ60OJTRW76syrxTHE2OpgifFvE2ma96l Ciku9bSkuA3w5GmXbcxh1y0a0Uv8dNH6FMi17xsJVo9tIZ/VW/vLdjFiZTpBtuF1tCWE bsdz888irjxAOSWWkQR7uuNqZ23ZAHQIzn8HLnqwysIOCAObIe+v9HPyo7ujPSvgqsBZ ZyUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w07nNXECaXWljAI84FYLJ8MZMakE00ftqm/8EmghEng=; b=tVgjHouIwGpFi3L72EmQlvNLAjh5Xe45MR+yMjWxgBn3Zkd2oONYcYgLxoDCR3Z3Np 6LulY4hGnCjAnWEKGZjdLx0uJfJp6CsEQ2VVvY38H9ci2NUh0uBuTVT/IASf7QOKFuL0 hV/IztF+65jFchF4KN6u2/UWYmRbsXoyuldsxMRzL9mkids5RCfitb3XY/CqTl3ItfOn Y5qV6aKo4BQwsgVODxWuZa35swI4uE2Lhxw2vn8RS7j3mKu+8EuGkQNprkcStKXv//pB 3ftEEDxbjjQj+ytv0HPv8DEIwJb+ZaLkBCS2J5rjzSeSyClZScgWWqAjLEy3lZRPnUtQ rkEg== X-Gm-Message-State: AOAM531m7QnJUSFsY9qRMcbCA4pdGGaJW+JyhDactCCEBebOcASbxg/X Zd2QhMiVVsR1R5qyrIFXRvIFqejKj/hJgf0GEDs= X-Google-Smtp-Source: ABdhPJwzK9Q2Cc9qXRCviwjmV7Ht+7MSjinKq9nTotNWCdAXztHg//ui0DCCdl2yuKeFiESu9avmot02mOjGSlPSWx0= X-Received: by 2002:a4a:aa42:: with SMTP id y2mr5315735oom.88.1598804538893; Sun, 30 Aug 2020 09:22:18 -0700 (PDT) In-Reply-To: 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:186714 Archived-At: On Sat, Aug 29, 2020 at 4:06 PM Stefan Monnier wrote: > >> > 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? By repeating the pcase pattern's predicate, usually, or by relying on other knowledge about the previous value. That's in practice, in theory you can use gensym or an inaccessible cons. > 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)))) > > ? Yes, that's correct. It's also how (pcase V ((or (pred symbolp) name) name) behaves... > I'd rather not go there You'd rather have the behavior of (pcase V ((or pred symbolp) name) EXPR) depend on the complexity of EXPR? > 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. Well, I'm afraid pcase does smell of dynamic scoping :-) More precisely, to me, what pcase simulates is building a lexical environment, then evaluating the BODY argument with the environment as second argument. (pcase EXP (PAT BODY)) is very roughly: (for-each-possible-environment ENV (if (equalish (eval PAT ENV) EXP) (return (eval BODY ENV))) where for-each-possible-environment magically finds the smallest (or "best") ENV first. I think it would be nice to have a lexical three-argument version of pcase which specifies which variables are output values, treating the remaining ones as input values, to make it easier to build non-constant patterns. But that would be very different from what pcase does do today, which is closer to what I hinted at above. IOW, if you want to call a function with arguments determined by pcase-like patterns, why not introduce pcase-call so something like the following would work: (defun f (hello world) (cons hello world)) (let ((space " ") (hw "hello world")) (pcase-call 'f ((concat hello space world) hw))) (that would introduce named function arguments, which I think would be a nice bonus)? But it's not what pcase is! There's no function call or argument list in there, just expressions involved in environments. As for duplicating the body, that is an implementation detail. You can easily avoid it by producing (let ((name name)) (cond ((symbolp V) X) (progn (setq name V) X))) disallowing the modification of name in X. > 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))) I don't see where the nil comes from, or why it's a useful choice for a default value. > the fact that the behavior depends on the order of elements in `or` is > an undesirable side effect of the implementation technique. It also depends on the complexity of the branch. It seems to me there are at least three consistent ways of behaving (throw an error, bind name to nil, bind name to name), with an inconsistent fourth way being what's currently implemented. > > 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. Here's my better-than-nothing attempt. I don't think that's complex; if anything, it's too trivial. (pcase-defmacro append (&rest patterns) (if patterns (let* ((r1 (gensym)) (r2 (gensym)) (pat (list '\` (cons (list '\, (list 'and r1 (car patterns))) (list '\, (list 'and r2 (cons 'append (cdr patterns))))))) (f (eval `(lambda (l) (catch 'pcase--append (dotimes (i (1+ (length l))) (let ((l1 (seq-subseq l 0 i)) (l2 (seq-subseq l i))) (pcase (cons l1 l2) (,pat (throw 'pcase--append (cons ,r1 ,r2)))))))) t))) `(app ,f ,pat)) ''nil)) > > > so an error message would be acceptable, > > You're probably right. > > > Sorry for complaining. Here's a patch. > > LGTM, > > > Stefan >