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: Replace trivial pcase occurrences in the Emacs sources Date: Sat, 27 Oct 2018 19:48:05 +0200 Message-ID: <874ld7i8mi.fsf@portable.galex-713.eu> References: <20151216202605.GA3752@acm.fritz.box> <8760zakb7q.fsf@fencepost.gnu.org> <56892BDA.6060103@dancol.org> <871t9yk98g.fsf@fencepost.gnu.org> <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> <83r2geqe15.fsf@gnu.org> 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 1540662373 13323 195.159.176.226 (27 Oct 2018 17:46:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Oct 2018 17:46:13 +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: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 27 19:46:09 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 1gGSf2-0003NR-QA for ged-emacs-devel@m.gmane.org; Sat, 27 Oct 2018 19:46:09 +0200 Original-Received: from localhost ([::1]:37357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGSh8-0007rO-SL for ged-emacs-devel@m.gmane.org; Sat, 27 Oct 2018 13:48:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGSgz-0007rJ-J5 for emacs-devel@gnu.org; Sat, 27 Oct 2018 13:48:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGSgy-0003sG-Hu for emacs-devel@gnu.org; Sat, 27 Oct 2018 13:48:09 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:54602) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gGSgy-0003rz-9w; Sat, 27 Oct 2018 13:48:08 -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 1gGSgw-0003ZA-1F; Sat, 27 Oct 2018 19:48:06 +0200 PGP-FINGERPRINT: E109 9988 4197 D7CB B0BC 5C23 8DEB 24BA 867D 3F7F Accept-Language: fr, en, eo, it, br In-Reply-To: <83r2geqe15.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 25 Oct 2018 17:47:18 +0300") 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:230737 Archived-At: On 2018-10-25 at 17:47, Eli Zaretskii wrote: >> From: Stefan Monnier >> Date: Wed, 24 Oct 2018 16:52:23 -0400 > >> To me, it's more verbose and more complex because you need to double >> check that the same var is tested each time before you can know that it's >> equivalent to a C-style `switch`. > > But it isn't equivalent to C-style 'switch': it doesn't compare like C > does, and it doesn't dispatch like C does. Is this about the fact you need =E2=80=9Cbreak=E2=80=9D in C to get the sam= e behavior? Then a lot of programmers =E2=80=9Cas a good style=E2=80=9D put it at the e= nd of each case, because they don=E2=80=99t even know they can do otherwise, and what = does that actually mean. > (I find it generally not useful to think in C concepts when > programming in Lisp, because it might cause confusion and mistakes.) Maybe it=E2=80=99s more a matter of programming habits than of C concepts. = And factorizing conditionals seems to be a pretty common thing. > By contrast, with cond everything is explicit and self-explanatory. > The programmer decides which equality to use. Yes, that does come for > a price, but copy-yanking is cheap and fast, as is "M-/", and also > avoids typos. People also have a habit of defining macros to factorize code so that to match their thinking and expression of what they want to achieve: that=E2= =80=99s why I and many others end writing new personal conditional such as case*. But these not being standard, they=E2=80=99re way less explicit and self-explanatory, as each re-definition will potentially loose unaware people, be incompatible with others, and will be more of a burden for readers of programs using them. While encouraging mainline and standard forms for common subexpressions elimination make people use them instead of making up their own, and therefore make their software easier to read. >> We clearly have very different programming backgrounds: to me the "case >> style" is much nicer and easier to read, closer to what I think in >> my head, whereas the "cond+eq style" is like a "assembly-language" >> version of the same. > > This isn't about style, this is about using macro facilities to > significantly change the syntax of a language. > > E.g., what do you think about people who use cpp to define macros > BEGIN and END that expand into braces? One could argue that it is > "closer to what one thinks in their head", or being "higher-level", > and yet such practices are generally discouraged. Because each one of these have real advantages as well as disadvantages, and, more importantly, neither of them is more clearly expressible as a composition of the other, compared to the other way around (eg. you can translate BEGIN END to { } or the other way around, none of both is more simple, natural or straightforward than the other). While this is clearly the case for pcase, cl-case, and finally cond, as each one of them can be more easily defined on top of, respectively, case, cond, and if. So the former are higher-level while the later are lower-level. Level is more a question of abstraction rather than (subjective) thinking. >> I prefer pcase to cl-case but I even much more strongly prefer cl-case >> over cond+eq. > > The thing is, both cl-case and pcase are subtly different from the > "boring" cond, and from each other. E.g., cl-case uses eql to > compare, so works with floats, but not with strings; >> > (Quick: what's the difference between `require and 'require in this >> > case?) >>=20 >> Same difference as between 'require and `require in normal Elisp code. >> Why is that a problem in pcase and not in the rest of Elisp? > > Because people stumble on this and are likely to waste time trying to > understand what kind of magic hides behind this. Worse, they might > copy this without understanding (as we already see in our sources), > thus proliferating the obfuscation. > > Mind you: I'm not against pcase where its power is needed. It is IMO > needed where using the underlying core facilities would produce > something that is hard to follow and even harder to understand. > Simple comparisons against a collection of fixed values doesn't fit > that bill, IMO. cl-case does, imho. I=E2=80=99d appreciate, as well as others, I think, an official version with equal (case-equal, or casequal maybe?), or even a more general version (with as second argument the test function to use): either named case* (I recall having seen somewhere the convention of appending a =E2=80=9C*=E2=80=9D for the general version (that asked for a t= est function) of a comparision form, do anyone know where it might come from? as I=E2=80= =99m now unable to find it again), or maybe using a :test and :test-not keywords. Maybe even a version not quoting its keylists?