From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Garreau\, Alexandre" Newsgroups: gmane.emacs.devel Subject: pcase ` meaning [Was: Re: Replace trivial pcase occurrences in the Emacs sources] Date: Sun, 28 Oct 2018 03:44:21 +0100 Message-ID: <87tvl6dc3e.fsf_-_@portable.galex-713.eu> References: <20151216202605.GA3752@acm.fritz.box> <568936F0.3060505@yandex.ru> <87wprqitj5.fsf@fencepost.gnu.org> <56893C8C.3060200@yandex.ru> <87oad2irtd.fsf@fencepost.gnu.org> <5689456A.1010601@yandex.ru> <87egdy8tyz.fsf@fencepost.gnu.org> <56895FDE.4060406@yandex.ru> <8760za8r4a.fsf@fencepost.gnu.org> <87h9iunkcg.fsf@web.de> <87h8hc4xw2.fsf_-_@web.de> <83tvlcsnee.fsf@gnu.org> <87pnw037ar.fsf@web.de> <83ftwvs7y9.fsf@gnu.org> <877ei7mkfh.fsf@web.de> <87a7mze7tl.fsf@web.de> <87zhuykjjh.fsf@web.de> <871s8aesdc.fsf@portable.galex-713.eu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540694596 6728 195.159.176.226 (28 Oct 2018 02:43:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Oct 2018 02:43:16 +0000 (UTC) User-Agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-15, modified by Debian Cc: Eli Zaretskii , Dmitry Gutov , Stefan Monnier , emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 28 03:43:12 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGb2l-0001eN-Lz for ged-emacs-devel@m.gmane.org; Sun, 28 Oct 2018 03:43:11 +0100 Original-Received: from localhost ([::1]:38528 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGb4r-0001ie-RT for ged-emacs-devel@m.gmane.org; Sat, 27 Oct 2018 22:45:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGb43-0000pk-3c for emacs-devel@gnu.org; Sat, 27 Oct 2018 22:44:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGb41-000668-4L for emacs-devel@gnu.org; Sat, 27 Oct 2018 22:44:30 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:55176) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gGb3z-00064t-F8; Sat, 27 Oct 2018 22:44:29 -0400 Original-Received: from localhost ([::1] helo=portable.galex-713.eu) by portable.galex-713.eu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gGb3t-0004wd-PR; Sun, 28 Oct 2018 03:44:21 +0100 PGP-FINGERPRINT: E109 9988 4197 D7CB B0BC 5C23 8DEB 24BA 867D 3F7F Accept-Language: fr, en, eo, it, br In-Reply-To: <871s8aesdc.fsf@portable.galex-713.eu> (Alexandre Garreau's message of "Sun, 28 Oct 2018 03:07:27 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:5884:8305::1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230749 Archived-At: On 2018-10-28 at 03:07, Garreau, Alexandre wrote: > On 2018-10-28 at 02:21, Michael Heerdegen wrote: >> Dmitry Gutov writes: >> >>> We could also assume that the silent majority is okay with the way >>> things are. For example, I like pcase, even if more complex cases >>> might look cryptic. >> >> I also like it, and your assumption could be true. Who knows. >> >> Pcase was a big improvement to what can be expressed with Elisp. And I >> think its syntax and semantics are quite straightforward. I doubt we >> will find something more simplistic that has the same power. >> >> Probably the main problem was that the documentation was originally >> written in a quite terse academic style. Also, the recursive nature of >> ` that makes it possible to combine it with all other patter types is >> hard to get, but also very natural and powerful. It's just consistent >> that when backquote is used to construct complicated lists, it is also >> used to build complex patterns to match such lists. Nonetheless it >> seems that ` is one of the main reasons for the bad feelings some people >> have about pcase. > > Isn=E2=80=99t ` needed in just the same cases you could as well use guard= or > predefined patterns? when you need to eval things? If there is some > redundance or covering between both, maybe ` could be avoided so it > confuses less? Nevermind, I just discovered that normally rar ` is mandatory for the main use case of pcase, pattern matching, which I find weird. So its normal syntax is what case should be, and its ` syntax is what pcase should be. Initially I expected this would have worked the same: #+BEGIN_SRC emacs-lisp (defun evaluate (exp env) (pcase exp (('add x y) (+ (evaluate x env) (evaluate y env))) (('call fun arg) (funcall (evaluate fun env) (evaluate arg env))) (('fn arg body) (lambda (val) (evaluate body (cons (cons arg val) env)))) ((pred numberp) exp) ((pred symbolp) (cdr (assq exp env))) (_ (error "Unknown expression %S" exp)))) #+END_SRC because intuitively, I thought what would apply to a raw top-level atom, would apply to it as a component of a sequence, but it seem I=E2=80=99m wro= ng. Which indeed is unreasonable, as it is incompatible with pcase non-pattern-matching own mini-language, which strangely seems to be more important to pcase than pattern matching. So know I understand why advocating for replacing case with pcase: pcase is not about pattern matching, it is just a correctly working case, except it only works for atoms, with an optional prevailing mini-language, and even more optional, additive and not straightforward pattern matching. Maybe that would make more sense if ` (and '?) were not part of pcase=E2=80= =99s own mini-language, redefined by pcase, but if pcase actually truly eval=E2=80=99d its pattern, defining pred, guard, etc. as real functions, defined with a cl-letf, using lexical scoping so to prevailably define all these + user-defined patterns. But even then, =E2=80=9C,=E2=80=9D I feel like would barely make sense=E2= =80=A6 it=E2=80=99s used the same way, but doesn=E2=80=99t mean the same thing. It doesn=E2=80=99t mean= =E2=80=9Ceval=E2=80=9D, as the thing after =E2=80=9C,=E2=80=9D, if not a function call, might be somet= hing not bound to a value, so it only means =E2=80=9Cundo the =E2=80=98`=E2=80=99, d= o like I didn=E2=80=99t do it=E2=80=9D, which is inconsistent with general use of =E2=80=9C`=E2=80=9D. When seeing =E2=80=9C,var=E2=80=9D, I=E2=80=99m thinking =E2=80=9Cthe actua= l value of var, or an error=E2=80=9D, so as I don=E2=80=99t see var defined anywere, I feel like an error is comi= ng, and as I know none is coming, I feel something is wrong. I don=E2=80=99t s= ee how to eval ,var without getting an error, except by redefining how to eval, or rather how to get a symbol value. It even more feel wrong that, this, doesn=E2=80=99t work, for no reason (it can=E2=80=99t be incompatible with the minilanguage): #+BEGIN_SRC emacs-lisp (pcase [1 2] ([a b] (+ a b))) #+END_SRC Yet that=E2=80=99s the most intuitive and straightforward way of using patt= ern matching.