From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Replace trivial pcase occurrences in the Emacs sources Date: Thu, 25 Oct 2018 11:32:39 -0400 Message-ID: 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 X-Trace: blaine.gmane.org 1540483055 27262 195.159.176.226 (25 Oct 2018 15:57:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 25 Oct 2018 15:57:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 25 17:57:31 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 1gFi0p-0006z8-8A for ged-emacs-devel@m.gmane.org; Thu, 25 Oct 2018 17:57:31 +0200 Original-Received: from localhost ([::1]:55354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFi2v-0005ve-Of for ged-emacs-devel@m.gmane.org; Thu, 25 Oct 2018 11:59:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFhcr-0004ay-T7 for emacs-devel@gnu.org; Thu, 25 Oct 2018 11:32:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFhco-00016F-RF for emacs-devel@gnu.org; Thu, 25 Oct 2018 11:32:45 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:57900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFhco-00014n-LF; Thu, 25 Oct 2018 11:32:42 -0400 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w9PFWdh9031734; Thu, 25 Oct 2018 11:32:39 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 651A7AE659; Thu, 25 Oct 2018 11:32:39 -0400 (EDT) In-Reply-To: <83r2geqe15.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 25 Oct 2018 17:47:18 +0300") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6404=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6404> : inlines <6943> : streams <1802344> : uri <2737733> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:230660 Archived-At: > Unfortunately, it makes the code more subtle and less > self-explanatory. Not for you and me, perhaps, but for quite a few > people who aren't as familiar with these macros, it seems. I can see why someone would feel this way when looking at a destructuring pcase macro. But for something like: (pcase this-param ('edit (todo-edit-item--text)) ('header (todo-edit-item--text 'include-header)) ('multiline (todo-edit-item--text 'multiline)) ('add/edit (todo-edit-item--text 'comment-edit)) ('delete (todo-edit-item--text 'comment-delete)) I have a hard time believing that there are more users who find it less clear than its cond+eq expansion. > 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; Right. > pcase decides what predicate to use according to the data, No: it uses `equal` (the implementation may optimize it to something else, but the documented behavior is that it compares with `equal` for all patterns of the form 'VAL and for the corresponding accepted shorthands (i.e. non-quoted strings, keywords and integers)). > so works with strings, but strangely doesn't work with floats. Actually it does for a pattern like '4.5 What it doesn't currently is provide the non-quoted shorthand for floats. Maybe it can be considered strange, but at least it rejects such a pattern upfront with an error. Of course, it's trivial to change it to accept non-quoted floats if we want to do it. > Again, perhaps this is not a problem for you and me, but newcomers > might well stumble on these subtleties, and at the very least will > have to consult the docs to know for sure. When reading pcase code, all they need to know is that comparison is done with `equal`, which AFAIK is always the most obvious and natural behavior. Restrictions like non-quoted floats only impact those rare people which will *write* a pcase pattern in which they want to put a float. > By contrast, with cond everything is explicit and self-explanatory. Every *step* is self-explanatory, but the overall goal is not: as a reader, I have to scrutinize every condition to see if the overall goal was indeed to "dispatch based on the value of X". >> 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. `pcase` doesn't just change the syntax of cond+eq, like your BEGIN/END example. Instead it provides a new abstraction. Stefan