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 vs. case (where it could also be used) [Was: Re: Replace trivial pcase occurrences in the Emacs sources] Date: Wed, 24 Oct 2018 00:24:48 +0200 Message-ID: <87tvlcgv2n.fsf@portable.galex-713.eu> References: <20151216202605.GA3752@acm.fritz.box> <56892334.4000106@yandex.ru> <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> <87in1sjva6.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 1540333418 25927 195.159.176.226 (23 Oct 2018 22:23:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2018 22:23:38 +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: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 24 00:23:34 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 1gF55K-0006fE-2y for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2018 00:23:34 +0200 Original-Received: from localhost ([::1]:44492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gF57Q-00082t-Bn for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2018 18:25:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36137) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gF56g-0007YJ-4l for emacs-devel@gnu.org; Tue, 23 Oct 2018 18:24:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gF56c-00068w-Eq for emacs-devel@gnu.org; Tue, 23 Oct 2018 18:24:56 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:39290) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gF56b-00066o-W2 for emacs-devel@gnu.org; Tue, 23 Oct 2018 18:24:54 -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 1gF56W-0007Gt-Hf; Wed, 24 Oct 2018 00:24:48 +0200 PGP-FINGERPRINT: E109 9988 4197 D7CB B0BC 5C23 8DEB 24BA 867D 3F7F Accept-Language: fr, en, eo, it, br In-Reply-To: (Stefan Monnier's message of "Tue, 23 Oct 2018 16:19:33 -0400") 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:230611 Archived-At: On 2018-10-23 at 16:19, Stefan Monnier wrote: >> To push the reasoning on an extreme: > > Given Turing-equivalence, I don't think pushing the reasoning to the > extreme will be a good guide. Why? We=E2=80=99re talking about what=E2=80=99s standard or not (so what n= eed to be redefined or not), what is (to be) popularized, common, etc. or not: =E2=80=9Cif=E2=80=9D, simple lambda, etc. exist in ML, but according =E2=80= =9Cgood ML style=E2=80=9D are (almost) never used, and pattern-matching forms is prefered (even when there=E2=80=99s no destructuring). The question is: do we want the same for emacs-lisp? I=E2=80=99m not personally fond enough of pattern-matching. T= hat recalls me the kind of falsely consensual trends that created Rust. pattern-matching is more intuitive, familiar and straightforward to read to the unused user, but it is more complex (including but not limited to of implementation), and I believe its familiarity is subjective or at least deeply specific to the human cognition, not as systematically particularly interesting on a logical or mathematical level. As forms such as case/switch/etc. are simpler, with some habit you can get quickly get as much used to it as to pattern-matching, just like sexps: more simple, less familiar, but then not long to get used to it. Imho cases where simple `case' become unreadable and pcase becomes necessary are symptoms of trying to implement something too complex at once, that could be either breaked down into simpler and more meaningful parts, or themselves symptoms of a complex spec or interface (where pcase would then become a necessary evil, but it should be there to indicate it as such). But that might exit the subject scope. >>> - once you learn it, you can use it elsewhere, e.g. pcase-let, >>> pcase-dolist, ... >> >> Could have been the same for cl-destructuring-bind. > > Except cl-destructuring-bind only covers (a subset of) pcase-let. > It could cover pcase-let as well pcase-dolist, but not `pcase` itself. > [ And even then, it would be less flexible than pcase-let because the > syntax of cl-destructuring-bind's patterns doesn't leave much space > for extensions. ] pcase is about pattern matching, that implies conditions, or at least recognition or tests, pcase-let only does destructuring afaik, so shouldn=E2=80=99t cl-destructuring-bind be improved instead, and all the pc= ase-* functions actually only doing destructuring be based on it? >> For instance, I personally have my own case* implementation for using >> other test-fn than eql (such as equal, > > That highlights the problem that cl-case doesn't work with strings, > forcing users like you to write their own alternative. Ahh, that=E2=80=99s what you meant by =E2=80=9Cdoesn=E2=80=99t work=E2=80= =9D. Well, eq can still be useful, for strings, I believe, otherwise eq wouldn=E2=80=99t exist and we = would only have equal (though this is what pcase does), so I wouldn=E2=80=99t call that =E2=80=9Cdoesn=E2=80=99t work=E2=80=9D. But a * version that takes a = testfn as argument can improve expressivity I believe (what if you want to compare, dunno, hashes?) >> the only possible one for pcase, and I don=E2=80=99t even hope making my= own >> version for eq/eql/etc.). > > Could you show me a pcase pattern where pcase's choice of equality > is problematic? > [ FWIW, there's only one case to comes to my mind. ] Now I know about the (equal ) pattern form, I guess a (eq ) wouldn=E2=80=99= t be that difficult to add, and as one of these would be mandatory to specify non-constant (hence possibly same) strings (though maybe there=E2=80=99s a = way to trigger arbitrary computation from inside the pattern before another get tried), it stays under control, so I don=E2=80=99t have any (case) anym= ore.