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: pcase vs. case (where it could also be used) [Was: Re: Replace trivial pcase occurrences in the Emacs sources] Date: Tue, 23 Oct 2018 16:19:33 -0400 Message-ID: References: <20151216202605.GA3752@acm.fritz.box> <877fjrkpdf.fsf@fencepost.gnu.org> <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: 8bit X-Trace: blaine.gmane.org 1540325900 1226 195.159.176.226 (23 Oct 2018 20:18:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2018 20:18:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 23 22:18:16 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 1gF383-0000Ci-Mi for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2018 22:18:15 +0200 Original-Received: from localhost ([::1]:44058 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gF3AA-0001L9-2T for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2018 16:20:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gF39Y-0001Kt-Pm for emacs-devel@gnu.org; Tue, 23 Oct 2018 16:19:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gF39U-0007B2-NN for emacs-devel@gnu.org; Tue, 23 Oct 2018 16:19:48 -0400 Original-Received: from [195.159.176.226] (port=32796 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gF39U-0007AF-Dz for emacs-devel@gnu.org; Tue, 23 Oct 2018 16:19:44 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gF37L-0007e0-FT for emacs-devel@gnu.org; Tue, 23 Oct 2018 22:17:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 97 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:43iBZjUFCo3ql3068nuGvMoUdRc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:230610 Archived-At: >> - if you forget to quote your constant symbols the code behaves >> differently (and arguably surprisingly for some user) rather than >> giving you an error, tho in many cases the macro will detect a problem >> and give you a warning about a subsequent redundant branch (but the >> unsuspecting user will likely find it puzzling and it will take >> a while for him to figure out what's going on). > Aren’t non-quoted for bind? what should give an error or a warning? > I didn’t understood? If the naive user wrote (pcase X (a fooa) (b foob)) when the intended behavior was (pcase X ('a fooa) ('b foob)) pcase will give a warning during macro-expansion that the second branch is redundant (since the first branch matches everything already). So, in a sense the user's error is detected, but the resulting warning is hard to understand if you don't know that the pattern `a` matches everything and binds it to the variable `a`. > Also, in either pcase or case: can’t they eval a symbol as a variable > value to be used in tests? Sorry, I don't understand what you mean: X can be a variable that's evaluated, yes. Or do you mean the case where we want to test equality with Y? `pcase` can do that with (pcase X ((pred (equal Y)) foo-equal-Y) ...) but I think this is irrelevant for the discussion at hand. > 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. >> - 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. ] > You forgot simplicity and concision of implementation: easier to > understand and reimplement, thus more hackable upon and widespread. I don't think it's particularly important, indeed. > 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. > the only possible one for pcase, and I don’t 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. ] >> - easier for people who already know Common-Lisp (or those who learned >> `case` from the cl.el package). > Also it is basically the equivalent of “switch/case/etc.” many will > search for, coming from another language such as C: and not everybody is > fond of destructuring and pattern matching pcase works just as well to replace "switch/case/etc." You don't have to use pcase's destrucuring, and this discussion is about the subset of case covered by `cl-case`, so destructuring is outside of its scope, AFAIC. >> - in (case X (a fooa)), the syntax looks a bit like a call to the >> function `a`: emacs-lisp-mode gets confused in terms of highlighting >> and completion, last I checked. > case is a macro: why making assumption on calls in macros arguments? > from time case known as a macro (I’ve a hard time imagining what a > “case” *function* would be anyway)… Also, with an unquoted symbol (so > to bind the default case), you have this very same problem with pcase: > (pcase X (a (fooa))) (and emacs syntax highlighting is confused here Not again that the pattern `a` here is outside the scope of this discussion (except to the extent that user can write it by mistake). Stefan