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: Re: pcase ` meaning [Was: Re: Replace trivial pcase occurrences in the Emacs sources] Date: Mon, 29 Oct 2018 11:22:57 +0100 Message-ID: <87lg6hxda6.fsf@portable.galex-713.eu> References: <20151216202605.GA3752@acm.fritz.box> <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> <87tvl6dc3e.fsf_-_@portable.galex-713.eu> <87efc9isxj.fsf@web.de> <87tvl5653j.fsf@portable.galex-713.eu> <87zhuxhbeo.fsf@web.de> 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 1540808503 6083 195.159.176.226 (29 Oct 2018 10:21:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Oct 2018 10:21:43 +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 Mon Oct 29 11:21:39 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 1gH4fy-0001Qv-CM for ged-emacs-devel@m.gmane.org; Mon, 29 Oct 2018 11:21:38 +0100 Original-Received: from localhost ([::1]:44542 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gH4i4-0005mR-6P for ged-emacs-devel@m.gmane.org; Mon, 29 Oct 2018 06:23:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gH4hv-0005l3-9H for emacs-devel@gnu.org; Mon, 29 Oct 2018 06:23:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gH4ht-0003eH-3H for emacs-devel@gnu.org; Mon, 29 Oct 2018 06:23:39 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:58104) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gH4ho-0003TZ-3o; Mon, 29 Oct 2018 06:23:33 -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 1gH4hd-0003XE-IF; Mon, 29 Oct 2018 11:23:21 +0100 In-Reply-To: <87zhuxhbeo.fsf@web.de> (Michael Heerdegen's message of "Mon, 29 Oct 2018 00:57:51 +0100") PGP-FINGERPRINT: E109 9988 4197 D7CB B0BC 5C23 8DEB 24BA 867D 3F7F Accept-Language: fr, en, eo, it, br 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:230763 Archived-At: Le 29/10/2018 =C3=A0 00h57, Michael Heerdegen a =C3=A9crit=C2=A0: > "Garreau, Alexandre" writes: > >> =E2=80=9C(var name)=E2=80=9D, as does racket and some common-lisp match/= unify >> implementations. And so to integrate with =E2=80=9C`=E2=80=9D: =E2=80= =9C,(var name)=E2=80=9D doesn=E2=80=99t >> disturb me, it is okay: will bind =E2=80=9Cname=E2=80=9D to something, p= retty >> straightforward. > > That would make totally sense to me. I often found it confusing that > using a symbol which is already bound (outside of pcase) isn't turned > into an equality test. Having an explicit `var' or `bind' for binding > variables would be nice. Mmmh, that=E2=80=99s what I thought initially, and why I regretted cl-case didn=E2=80=99t eval its arguments, but in reality, neither pcase does, thou= gh it gives this impression, since it requires quoting symbols for equality. =E2=80=9Cvar=E2=80=9D is to make explicit bind variable bindings where it c= ould not being done so otherwise, so to me ,(var name) looks less confusing, and, if lists and arrays out of the box matched lists and arrays, so that =E2=80=9C(pcase (list 1 2 3) ((1 2 3) t))=E2=80=9D was true, it would allow= to bind a list first element when it=E2=80=99s also the name of a predefined pattern,= like =E2=80=9C(pcase (list 1 2 3) (((var and) 2 3) and))=E2=80=9D would give =E2= =80=9C1=E2=80=9D (it looks silly to use a such name for a variable, but we never know, and at least it makes pcase not unable to match some patterns (without ` I mean), like guile=E2=80=99s match). Also, as to speak about common pattern matching facilities, and how they make patterns look related to their match: all of them make normal, unbound identifier, lead to binding, instead of evaluation and replacement by their bound value. I (strangely, I realize no), see no facilities in pattern matching in non-lisp languages to match the value of an already bound variable=E2=80=A6 or am I wrong? do they allow that? Even in pcase I don=E2=80=99t see how to do that except manually using (and= var (guard (equal var val))), which exactely looks like a cond, but more complex, embed in a, now uselessly complex pcase, which, then, defeat its purpose. And yet that=E2=80=99d been the behavior I=E2=80=99d imagine for ,var, in `= , that=E2=80=99s why it=E2=80=99s confusing. However, I cannot suggest to change it to lead ,va= r to be evaluated to its value bound outside of pcase, because the way pcase bind ` seems to already be used by several other pattern matching facilities, so that=E2=80=99d break compatibility and bring confusion, too, sadly (maybe a definable pattern could change the default ` behavior, so people could experiment this behavior at least? yet their code could lead to confusion then). >> Beside lisp, all pattern matching language make their feature serve >> one purpose: the pattern look like what the data should be. adding =E2= =80=9C`=E2=80=9D >> and =E2=80=9C,=E2=80=9D destroy this feature, because the pattern no lon= ger looks like >> what is matched. > > But with, for example, el-search, that suddenly looks very natural if > you can, for example, transpose the first two arguments of all `foo' > calls in your code with the rule. > > `(foo ,a ,b . ,rest) -> `(foo ,b ,a . ,rest) No it doesn=E2=80=99t look natural: the transformation does, the reading is straightforward, the result is, but making the first pattern isn=E2=80=99t, because a and b aren=E2=80=99t bound to anything, so the =E2=80=9C`=E2=80= =9D meaning is truly different (at least partially) than normal. > The pattern exactly looks like the matched data! Just with a different > point of view. Using ``' is not what most people would naively use to > implement destructuring, but I don't find it unnatural or not intuitive, > no. Afaik, the matched data, here, is =E2=80=9C(foo . )=E2=80=9D, like =E2=80=9C(foo 1 2 . 3)=E2=80=9D (unquoted), o= r, when quoted =E2=80=9C('foo 1 2 . 3)=E2=80=9D (or =E2=80=9C'(foo 1 2 . 3)=E2=80=9D if you want, but if = you ever changed to =E2=80=9C`=E2=80=9D here, you=E2=80=99d have to admit it doesn=E2=80=99t me= an the same as in pcase, and, obviously: the fact you maybe used it in the data you want to match, doesn=E2=80=99t mean you need to use it in the pattern (because the reader removes it) so the purpose is defeated), that=E2=80=99s not what I call =E2= =80=9Clook exactely like it=E2=80=9D: =E2=80=9C(foo 1 2 . 3)=E2=80=9D is =E2=80=9Cexac= tely=E2=80=9D, =E2=80=9C('foo a b . rest)=E2=80=9D would be enough. I find =E2=80=9C`(foo ,(var a) ,(var b) . ,(var rest))=E2= =80=9D is still understandable and not that confusing, but it *doesn=E2=80=99t* look = like the matched data, like it does in other languages, such as ocaml/haskell/rust/etc. > The above pattern would look different if we would have to write it as > > `(foo ,(var a) ,(var b) . ,(var rest)) > > so the implicit binding feature of symbols also makes patterns much more > readable in more complex cases, which is a big win. It is a big win only in terms of avoiding confusion (with =E2=80=9C`=E2=80= =9D), and allowing otherwise impossible stuff (without =E2=80=9C`=E2=80=9D), but I wa= sn=E2=80=99t proposing it to make more readable, only more powerful and less confusing. What would make more readable are directly matching them when they don=E2=80=99t correspound an already defined pattern (such as (1 = 2 3), since no pattern is defined after a number, or absolutely all occurences of [], since no pattern is defined after an array), like guile=E2=80=99s and racket=E2=80=99s matches, and some common lisp matches, do, and, otherwise, pattern named after type constructor such as `vector' or `list', as you suggested in the other thread, to correct me: #+begin_src emacs-lisp (pcase-defmacro list (&rest args) `(,'\` ,(mapcar (lambda (thing) `(,'\, ,thing)) args))) #+end_src I tried to adapt for arrays: #+begin_src emacs-lisp (pcase-defmacro array (&rest args) `[,'\` ,(mapcar (lambda (thing) `(,'\, ,thing)) args)]) #+end_src But it doesn=E2=80=99t work x), that, plus my initial non-working =E2=80=9C(pcase-defmacro list (&rest args) ``(,@args))=E2=80=9D, I must fin= d =E2=80=9C`=E2=80=9D, is, indeed, quite confusing (how is =E2=80=9C,'=E2=80=9D needed? how isn=E2=80= =99t =E2=80=9C,'\`=E2=80=9D equivalent to =E2=80=9C\`=E2=80=9D?), even in real life (or maybe here it is because o= f pcase it is that complex?), when it get complex, like used directly recursively.