From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thierry Volpiatto Newsgroups: gmane.emacs.devel Subject: Re: pcase bindings in patterns with complicated logic Date: Sun, 14 Jan 2024 06:58:13 +0000 Message-ID: <875xzwjta2.fsf@posteo.net> References: <87il3xt38w.fsf@localhost> 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="39417"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 14 07:59:29 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rOuSu-000A5W-ST for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Jan 2024 07:59:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rOuS4-0003Fb-SB; Sun, 14 Jan 2024 01:58:37 -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 1rOuRt-0003Af-GY for emacs-devel@gnu.org; Sun, 14 Jan 2024 01:58:27 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rOuRr-0002Q0-FV for emacs-devel@gnu.org; Sun, 14 Jan 2024 01:58:25 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 40C73240027 for ; Sun, 14 Jan 2024 07:58:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1705215499; bh=qOWYxAXLOm+2dRfbXTeucCglNAoQ9Yi3Lc30DmUYiMs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Autocrypt:OpenPGP:From; b=jvhqKueoS0JvDThvkhzNySivRcOcF4pP7moIxElPBnxBTcDkB8jT8VfRi+ZShJ3kZ Ph1GvQ80fqE/EahXV1T2ffZ47T3tSYhCkMZQpVjt1VtHQ9JFfp/PblhLit1Gqmlp1W pytsVp1r7NgJjUyij3RqwVMxpl0joQphc+D902ko038KqETsDCMFhuukEtrq3NDBjJ ckwhCIgM58NLvVMLGK4KIr+/11m76SkRDdEyFyPySMNsCuwHTUjpWwHI8eG2bOB111 FWkjEQS4CB9scT173mUB3sPIi6y1AUA6BWlMLQJlmMkANGHUhB4jrGDbPeSDi5Wehz ESZDZjQKxGRlw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TCR1j5JTRz6twf; Sun, 14 Jan 2024 07:58:17 +0100 (CET) In-Reply-To: <87il3xt38w.fsf@localhost> (Ihor Radchenko's message of "Sat, 13 Jan 2024 19:58:07 +0000") Autocrypt: addr=thievol@posteo.net; prefer-encrypt=mutual; keydata=xsDNBF8ylcIBDADG+hy+zR6L4/vbdDDZuSaMmSrU3A5QZJpeBCvxTr7MpzzruZbhLPW1K3R6N2MA edi8Y+C8o27FVRIjpdbaKMGu9je7JV/TbUQYo3SOwCK1vM4LUn4V6ZLzSYkuiEt4eyMoiDdyvN0p kcK6P9x9DCetcEVszXzQg+yzCVrQ2hXWDXWT4M18EC3wtO7RHPouMqGiwBFhBAYErCqFWFxQHkfb tG/4yGyJ58rglb65O3qijjMWvYwcWZun9/7qm8Z4/4mHopmo2zgU+OrptnLSZfkZGz3Y7Uf452xQ GVq0Fv75NPvQru7y+DYVhuVXXyAmGxt+vf4rIiixMBbhKEPjcxEPAa2LTzex2IsTZR+QVG9uDnqC WcgaOEQ58fzXNvNhtwwF/Rgio2XWAJVdmFWS59/k9W58CIUSNKBMZh2XeGdEmtHvDtCxW3z6FJha 36RzOM3fMNNiAGdFZJA84gcdloJR+sHCDTTPT3784fjr+V8An7sI581NGFzkRQqPvEQCZbUAEQEA Ac0SdGhpZXZvbEBwb3N0ZW8ubmV0wsEOBBMBCgA4AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA FiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmL3HCoACgkQDsVtFB0W75OVEAv/f6XxmtIFz08fUb8h Bp/zJP6IC4/rhhh+0GMRIRzLN8DK0jV8JCzYdFHiRJOy2lNIOpmrrCmjRRxferc2G42+ePFIsslx hU46VSz1Z83NwIG3mpdYNV5WUTUdgzxExHTNTFCd7NKv0nlHKQaA OpenPGP: url=https://posteo.de/keys/thievol@posteo.net.asc; preference=encrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=thievol@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314951 Archived-At: Ihor Radchenko writes: > Richard Stallman writes: > >> (pcase '(foo 5) >> ((or `(,(and (pred symbolp) a1) ,(and (pred symbolp) b1)) >> `(,(and (pred symbolp) a2) ,(and (pred numberp) b2))) >> `(,a1 ,b1 ,a2 ,b2))) >> >> =3D> (nil nil foo 5) >> >> That surrised me, since outside the pcase, all four variables >> are unbound and referring to them gets errors. >> >> So it seems that all the pattern variables in the curren clause are >> bound somehow if that clause succeeds, but only some of them get >> significant values. >> >> Is that an accurate general statement of how pcase handles binding >> pattern variables? > > This looks like a bug. This is not a bug, this is documented earlier in documentation: =E2=80=98(or PATTERN1 PATTERN2...)=E2=80=99 Attempts to match PATTERN1, PATTERN2, ..., in order, until one of them succeeds. In that case, =E2=80=98or=E2=80=99 likewise matches, a= nd the rest of the sub-patterns are not tested. To present a consistent environment (*note Intro Eval::) to BODY-FORMS (thus avoiding an evaluation error on match), the set of variables bound by the pattern is the union of the variables bound by each sub-pattern. If a variable is not bound by the sub-pattern that matched, then it is bound to =E2=80=98nil=E2=80=99. But I guess the rest of the documentation has not been updated. =20 > The manual has a dedicated paragraph explaining the above scenario. > However, on the latest Emacs master, "void variable" errors are not > thrown, in contradiction with what the manual states. > > 3. On match, the clause's body forms can reference the set of symbols > the pattern let-binds. When SEQPAT is =E2=80=98and=E2=80=99, this s= et is the union > of all the symbols each of its sub-patterns let-binds. This makes > sense because, for =E2=80=98and=E2=80=99 to match, all the sub-patte= rns must match. > > When SEQPAT is =E2=80=98or=E2=80=99, things are different: =E2=80=98= or=E2=80=99 matches at the > first sub-pattern that matches; the rest of the sub-patterns are > ignored. It makes no sense for each sub-pattern 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. For example, the following is invalid: > > (require 'cl-lib) > (pcase (read-number "Enter an integer: ") > ((or (and (pred cl-evenp) > e-num) ; bind =E2=80=98e-num=E2=80=99 to EXPVAL > o-num) ; bind =E2=80=98o-num=E2=80=99 to EXPVAL > (list e-num o-num))) > > Enter an integer: 42 > error=E2=86=92 Symbol=E2=80=99s value as variable is void: o-num > Enter an integer: 149 > error=E2=86=92 Symbol=E2=80=99s value as variable is void: e-num This should be updated to fit with the (or PATTERN1 PATTERN2...) documentation. I guess there is other examples in documentation that are mismatching with the actual behavior of pcase or are just confusing like this one in "11.4.4 Destructuring with =E2=80=98pcase=E2=80=99 Patterns": (pcase my-list (`(add ,x ,y) (message "Contains %S and %S" x y))) I guess this example has been added before the pattern `add` exists. Here `add` is a symbol like any other symbol and has no particular meaning but it is confusing for reader that has not completely integrated previous sections (I would use `foo` instead). [ BTW I don't understand why `add` pattern exists as long as now `pred` is supporting an extra arg ] Also I would give a warning to extensions developers that want compatibility with older emacs: pcase has evolved and doesn't behave as in older emacs, so try you pcase statements on each emacs you want to support, for example (pred (not ...)) is not supported in older Emacs. --=20 Thierry