From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#67611: [PATCH] Add a Pcase pattern `cl-lambda` equivalent to `cl-destructuring-bind` Date: Fri, 12 Jan 2024 16:56:25 +0000 Message-ID: References: <277dd49a-e96d-4faf-a22e-aca952354a37@protonmail.com> <30f1bf76-1cf1-493e-be4f-38e405d0ecf6@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20768"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Okamsn , 67611@debbugs.gnu.org, Stefan Kangas To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 12 17:57:26 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rOKqT-0005BO-O5 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Jan 2024 17:57:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rOKqC-00071s-1S; Fri, 12 Jan 2024 11:57:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rOKqA-00071j-Ga for bug-gnu-emacs@gnu.org; Fri, 12 Jan 2024 11:57:06 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rOKq8-0007P2-6d for bug-gnu-emacs@gnu.org; Fri, 12 Jan 2024 11:57:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rOKq5-0004JE-Ur for bug-gnu-emacs@gnu.org; Fri, 12 Jan 2024 11:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jan 2024 16:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67611 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix notabug patch Original-Received: via spool by 67611-submit@debbugs.gnu.org id=B67611.170507860316531 (code B ref 67611); Fri, 12 Jan 2024 16:57:01 +0000 Original-Received: (at 67611) by debbugs.gnu.org; 12 Jan 2024 16:56:43 +0000 Original-Received: from localhost ([127.0.0.1]:37508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOKpn-0004IZ-Ec for submit@debbugs.gnu.org; Fri, 12 Jan 2024 11:56:43 -0500 Original-Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:58478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOKpl-0004IE-3N for 67611@debbugs.gnu.org; Fri, 12 Jan 2024 11:56:42 -0500 Original-Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2cd17a979bcso76174171fa.0 for <67611@debbugs.gnu.org>; Fri, 12 Jan 2024 08:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705078597; x=1705683397; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FoNKWG4Izd8aIedLLTrGBfdw+1jtA9M/SV+NoPvH9cw=; b=a6JXxFyKR2NL06WJzCwQjLd0BgXObd+CSbGQ+qI1pt3O2YVnZss1y9TvW7o02o/79d NluC/2UZwRVTpEkNJLsMym87usVql8oSpfTOAVE1qTlDa6fb3DpPROqfSIhAC0/0U4f7 QqIeZoCGesyJNn2Z2igtAGdBmEye5+kd3palL6+wDl0ZOSBufHHZD80WkNqgS4gvoPxS 4Mdt9ApHX+cvAQupKvZz70Qx0EbkY027fJ790v/XJYPCYTezvfXv5PCV1D53kxWY4Sd4 N/qGxN701V5fMpjzHdQCYwQduYhSuktEx5EeFMludt+aiUfXHo79tK9yeqQgL3IKySKa cFTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705078597; x=1705683397; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FoNKWG4Izd8aIedLLTrGBfdw+1jtA9M/SV+NoPvH9cw=; b=MZ1uTAjJIYGD3azvPKyMx9E4zwmY6ZwyMrCe3mALjocCLQIngILlrW+G8w+9kzr334 7jPhKfQG5iPr/pCZIBghC4flinaTzEbAKB03Ok5WNVFgLFdYDBPVpryYwowO2UkcwFtk XPFL2pfL5M+13/0p/cVKDqRGp+hSMqMTB1+KbLq6AvmgaPOMc1m9dViuUaNJ3QKgHfFZ f0J1Pa6B6JbPpq/rFSKO3DPP8I455pMlXfuGMmS2Qvq+cc+S8kX3iWNGjZGtibP1a63U ouH3Fqmit2Fb1S7TxLnXb8IGNB41tcva9mo4P6Gu5H0UAPR1MjYLCwrxLFPDpxNBxqEo 2kQg== X-Gm-Message-State: AOJu0YwDC59LWYFi1wOSw86mDHdqlHLLlH2mfwlQQz2Dk0IredCpgb09 S0Wl35cI/hRYRmKL9zD7foQ3FMUjJuOnGrxd/qc= X-Google-Smtp-Source: AGHT+IGE2Qd/raTw6Xw6SKhQRccHgOOV0aHbOOEzF9Hwr32WEGx53fAPNNc6sI7MNYR0XXZ3nyJohv7XERCX0Gii8Rw= X-Received: by 2002:a05:651c:1038:b0:2cc:94f6:bfc7 with SMTP id w24-20020a05651c103800b002cc94f6bfc7mr458418ljm.170.1705078596595; Fri, 12 Jan 2024 08:56:36 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:278055 Archived-At: reopen 67611 thanks On Fri, Jan 12, 2024 at 3:38=E2=80=AFPM Stefan Monnier wrote: > > >> I don't think there's a clear enough need for it right now in Emacs co= re > >> to motivate its integration in Emacs proper. Also, because several > >> people have expressed an opinion that leans towards recommending that > >> Emacs's own code should probably better avoid using this functionality= . > > Those people are trying to come up with alternative pattern-matching > > libraries which we start to see are not simpler or as powerful > > as pcase. > > Only some of them are. Others are perfectly happy with using `pcase` > but still aren't super happy about combining the complexity of `pcase` > with that of CL destructuring syntax. > > Personally I'm rather put off by the difficulty of figuring out which > part is using CL syntax and which part is using Pcase: the transition > from Pcase to CL is fairly clear (marked by `cl-arglist` or somesuch), > but the other is much less so. > I'd be happier with a `cl-arglist` which cannot contain nested Pcase > patterns (i.e. a one-way street from Pcase to CL) with > `cl-destructuring-bind` reimplemented on top of it. Can a pcase extension even be a one-way street? And if so, isn't that contrary to the whole purpose of pcase itself? Why have this ban specifically on a CL pattern (should really be called "lambda-list" by the way) when we have a cl library in core and so many uses of CL things that use CL-style lambda lists, with or without cl-*.el. We have so many other less commonly used extensions, some of them subtle performance problems, like seq extensions that rely on generic functions. Pcase is complicated and hard-to-follow yes. Becasue complex pattern matching is a complicated thing to express, just as regular expressions are such a thing (I for one do not think 'rx' makes things particularly simpler). If you ask me, we'd be better off designing an "explain pcase" utility or designing font-lock rules that helps explain it. The byte-compiler is already traversing that anyway and flagging unused variables and stuff. Can't we use this to mark what is a lexical variable and what is a literal symbol, for example? Can't we have a very clear highlighting of the pcase extension being used, like highlighting the '`' or the 'cl-arglist' or the 'seq'. > I'd also be interested in a new Pcase pattern that provides the part of > `cl-arglist` functionality that's missing from current Pcase patterns > (like "optional" elements in a list), but with a syntax that blends > better in Pcase patterns. I'd rather not reinvent half-baked CL things, as it's all too common to discover later we should have gone full-baked and we have digressed for no good reason. > > IOW there is no general purpose-util like Alexandria's > > 'parse-ordinary-lambda-list', and this could be it. It could > > not only be used to simplify and add coherence to many of these > > existing compile-time structures, for example helping simplify > > things and address FIXMEs in cl-lib.el. > > That's a different question: improving up cl-lib's implementation would > be welcome, yes. That's not what the current patch does, tho. It provides a tool to help do that, of course. Anyway if there's some common ground here, let's not throw the entire baby out with the bathwater. Maybe Okamsn can repurpose the helper function he created to parse lambda lists to be akin to Alexandria's parse-simple-lambda-list. It seems it already is fairly close (the alist retun type in Elisp is natural as we don't have multiple values). Also the function's implementaion should be changed to rely on as little as possible of existing cl-macs (cl-copy-list and cl-flet can maybe be skipped -- and maybe added back again later). Shoulnd't be a very hard job (I might be wrong). Then we can consider merging that including figuring out where to merge it. And then we can continue discussing about the usefulness the pcase patterns that can be built with it, sure. I've reopened the bug. Jo=C3=A3o