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: `pcase'/`case' implementation [Was: Re: Replace trivial pcase occurrences in the Emacs sources] Date: Tue, 30 Oct 2018 01:50:22 +0100 Message-ID: <875zxkqmup.fsf_-_@portable.galex-713.eu> References: <83tvlcsnee.fsf@gnu.org> <86mur137n8.fsf@gmail.com> <20181029130132.GB4195@ACM> <20181029134722.GC4195@ACM> <87lg6gifnb.fsf@web.de> <87muqwxs7m.fsf@ericabrahamsen.net> <87in1kxry1.fsf@ericabrahamsen.net> 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 1540860557 9948 195.159.176.226 (30 Oct 2018 00:49:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 00:49:17 +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: Michael Heerdegen , Stefan Monnier , emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 30 01:49:13 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 1gHIDW-0002RD-As for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2018 01:49:10 +0100 Original-Received: from localhost ([::1]:49892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHIFc-00022q-Bc for ged-emacs-devel@m.gmane.org; Mon, 29 Oct 2018 20:51:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHIEv-00022P-Id for emacs-devel@gnu.org; Mon, 29 Oct 2018 20:50:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHIEs-0006Ki-II for emacs-devel@gnu.org; Mon, 29 Oct 2018 20:50:36 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:59618) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gHIEm-0006IS-Ve for emacs-devel@gnu.org; Mon, 29 Oct 2018 20:50:31 -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 1gHIEg-0008Sm-Po; Tue, 30 Oct 2018 01:50:23 +0100 PGP-FINGERPRINT: E109 9988 4197 D7CB B0BC 5C23 8DEB 24BA 867D 3F7F Accept-Language: fr, en, eo, it, br In-Reply-To: <87in1kxry1.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Mon, 29 Oct 2018 16:18:30 -0700") 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:230790 Archived-At: On 2018-10-29 at 16:18, Eric Abrahamsen wrote: > Eric Abrahamsen writes: >> I wonder if the manual shouldn't have a section somewhere making >> explicit the difference between `pcase' -- where a single value is >> matched against many patterns, and may fail to match altogether, and >> destructuring is only one of the use-cases -- and the other >> pcase-derived forms, where many values are matched against a single >> pattern, which *must* match (or error), and destructuring is kind of the >> whole point. Conceptually, they're pretty different. > > In fact, when you think about it, the "case" nature of pcase is pretty > orthogonal to the "match/destructure" nature of pcase. If anything > fairly fundamental were to be done to refactor pcase, I wonder if it > shouldn't be to separate these two concerns. In a sense, we already have > `cl-case', why would we need another case-like structure? All we really > need are new _matching forms_, which could be used within `cl-case', > `dolist', `lambda'... I also believe this. We should, on one side, have a `match' function, that would do more advanced destructuring than `cl-destructuring-bind' (and, potentially, be based on it (so it could seeminglessly be used in `pcase-lambda' on whole argument list), or the other way around, so match returns an env (like other one-clause `match'), without having to execute body, so to be more composable, and only then it would be used in `cl-destructuring-bind' (which would then be accordingly more powerful (but potentially incompatible in some corner cases (or more than corner cases, if we don=E2=80=99t implement unquoted =E2=80=9C(a . b)= =E2=80=9D where =E2=80=9Ca=E2=80=9D isn=E2=80=99t a predefined pattern, to match a cons)))), preferably based o= n it (and potentially with an `unify' based on it). Then, on another, I strongly believe we need a `case' struct that takes a test function as an argument. That test function might be `equal', so that to make `case' generally more useful, but also `match', so now we got a neat composition of two orthogonal and separate functions to make a more complex one. Then, we might tweak `case' so that to take the result of the test function as an environment to be used for each BODY: most test functions returns t, and in emacs, that=E2=80=99s already the void environment referring to the global dynamical one, and `match' would return what it bound. Then `pcase' would simply be =E2=80=9Ccase :test #'match=E2=80=9D (like (se= tf pcase (apply-partially #'case :test #'match)), but with its defun, docstring, et al), get a simpler implementation, neat internal interfaces, and ends that sort of sterile and useless implicit fight between `case' and `pcase' (as they=E2=80=99re only two different levels). I like minimalism, composition and reductionnism.