From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: cond* vs pcase Date: Wed, 07 Feb 2024 14:14:41 +0100 Message-ID: References: <822c332c-1a85-4454-8978-0b1491981058@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37961"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Adam Porter , "ams@gnu.org" , "emacs-devel@gnu.org" , "philipk@posteo.net" To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 07 14:18:54 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rXhpF-0009fa-T5 for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Feb 2024 14:18:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rXhoi-0006go-TE; Wed, 07 Feb 2024 08:18:20 -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 1rXhlK-0005Z1-Lg for emacs-devel@gnu.org; Wed, 07 Feb 2024 08:14:50 -0500 Original-Received: from mail-db3eur04olkn2106.outbound.protection.outlook.com ([40.92.74.106] helo=EUR04-DB3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rXhlI-0003Zj-3Y; Wed, 07 Feb 2024 08:14:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ex0aKGQ54NoK9LGvAQEcS9s1BADOE7naPQhQD8b1Q/NbSXKGyrvShESPqnEDoFF0ktSFZP39Retd3h/geWY8t8QOFQOQZK2E8D6a0zMw8Apl2Z2+Lo+yqICGIhjegR84wzhuYStDpsSOfe6W1nE+ikkeFD/7rVOCaTkENKt3lM1pY7lA8MnLZs0eQXg6BWqUiVOJwYXeYgykIyjc418OMi3b9BRUxK4rIcfMgcI8VjPMsTdq/0lLmgcjPmUTYdNw0GBSg53IklWiXfh3GWV4kSXThEobRbjgYhP6ycGBbgJZRMB9Uij3pKg5Olf3E+EqHtwP+y1/QK4+DHg0PPv1bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wF6nyMj84wYhNqMQ/Q9uU+V7Bml1UzMwlk+y4oxTou4=; b=lzk6yL800UDQYLJOSri1FDkU6cVqW5SH97xCbKoWwveMYPsxdyj9YxIhujAiFF1gVbyiS/hK7l3eMEtw3aYxO+hTToN9WmGgZw1q/W10YMlZPT97QD9eLnsV5KPPmexvmrrXIQozQ0riQC5T8lVd/fQKk8J1ExfC5Gl3YWXCVeOsozhb8zYPAhnaR3cemPjIecQTbFqnaCngH38CtEy3DNJWQAtGlZZsDm452F1P3J7VzJsMzBsJDSI2pEMSjLnxJB+l83jSKJ5xEN7W2ACe3Wqz/+IiG0F0FuffzksFE1VedyOE9Ta6/9lomLLAsvm6YBZPJoC5D/wfAL8Bb6PbZw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wF6nyMj84wYhNqMQ/Q9uU+V7Bml1UzMwlk+y4oxTou4=; b=EXHPwEbYNiAzdGhsXm3ZcfN6VGO5gbw1hisrdx7uqMKRyfYm9w+/dirKHjeT6jptBr+meCt/229usyfZ/Cwl9PpWQtRS5y8kDxjpoq/79VgjJ107xLaQYeczVyU39/Ej24/wWUO5cP3Sb5SU3YFtH9t4ZehTSMawSGyg7CPF5CF4DmXNFrZnD1Yte839ZzgWvpShrabgbK1IJ5rq1PyuCtOlwoo57oWu3z/yY8u60poMRPf9Lb6SZBb0L0BcnVHcsx6QLOIMwytTiBit3L+RKRKyz36XrYDV0cH1J0tFQJvrtNk2yAiifd/qiOuKIkBt9umeeQfl4HzHAwTC4ctlAQ== Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) by GV2PR02MB8627.eurprd02.prod.outlook.com (2603:10a6:150:7a::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.36; Wed, 7 Feb 2024 13:14:44 +0000 Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::b91:5e3:fb4a:3b2c]) by DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::b91:5e3:fb4a:3b2c%3]) with mapi id 15.20.7249.035; Wed, 7 Feb 2024 13:14:43 +0000 In-Reply-To: (Drew Adams's message of "Tue, 6 Feb 2024 23:32:25 +0000") X-TMN: [7YGc8BInrBY8c0wl0G26k7gESaWffxKPP0O335ehCmU=] X-ClientProxiedBy: FR4P281CA0450.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:c6::11) To DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) X-Microsoft-Original-Message-ID: <871q9os9fi.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR02MB10109:EE_|GV2PR02MB8627:EE_ X-MS-Office365-Filtering-Correlation-Id: 186e6e9b-6c3c-43a3-e3a3-08dc27debf94 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UNHqmKPhimJ/mmITjXt+qxTuxOoWsLZAeCS4XuA23q0mz0HKbxUSme4hY1dybks0NP9ON5oiyFgxheqLLcJN8wsjGRrjBEJa091IvJGIsdHt6UeV+yrT3YbdXJ8KlHp0S4F22TWHxeLbBnzSNtr1MPKspogsdo+YMkqzL1GE0PHdvTHdVQJ3IihFS1GXSi6jRHAo3ysXxchQ8kaboh0E1D0xOQhQWhHe7KPI8YIWqyc7z3a6DQ1qH+gpwAp8+xlxnVGnUiuaCpmr9mKR2cxxz1iD5mUkvFvk1EMcHzvM2iLtRWfeC99XsAUwmbUeiq1Okb7WtJPjAwe9bJRjvA6WsZmBKtHi1nGNY0z65COM5fzrZ6ZusO/npm69hFuFa3mBR52g9tKG2qgUmk5Htn94Sd/KYHiVPcMIPGWEQv5XH1UHzEbmWC1lr7i/Ed15PtybZ1Xld1tfs5+uGv4ePFhIGXseggFOThjt+hBXCyuCu16HFgdOa5ase4G7p/BuTtllpzTeo+GCRaHtsx1sXbE6f94qWy9vaW+Ga9SxUhkE1M9y7sYRnM4M8JYTxeAhJBaE9vlnlkggLuqLyqTvDk6pBcX5mQbLj4k384xuvLk8ILA= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RLVC7YzEcnQjpyReai203ZphOSVxLu8pgubqCYTkHXR18F2rLSvxAUafrBMa?= =?us-ascii?Q?xkLYSPPLBHH2ncwOswzAtlG+bylRDGMo+W8AKXMju2M/ZIJggOXAIDrUqvG9?= =?us-ascii?Q?desnuJfAAneVwqPwdmMdl+NSWr4DEgBI7THswTW38nCgCMXfI6Y7RMvrvfzl?= =?us-ascii?Q?N8vnjKR2SyqekG+4Z1AiBOlexzRDAYN90yYRroxdAO1rHxR/DUi6IUd5GXzk?= =?us-ascii?Q?1u8FUkFtyjqrJM6o7MwKlvTdacQ03mMFkJU3GiXDurM7Qxa0IRFw19WLZPnA?= =?us-ascii?Q?SR4rl8dq2VvYS0XFF044bBj8onMd57rMnjZbtz7wqnP9gfTdSCI93KrYRlWr?= =?us-ascii?Q?xP70d2f0i9rXdK5eF2jxbggXQDXxy9LK7JmqDbxj+HmwTVHQaXMD2WA239NV?= =?us-ascii?Q?8zv6A5vLd+1bsIS//z0vVsktK4uWLzms09oIXk0GHufpw12P54VjKSDC/zGk?= =?us-ascii?Q?7l8W6sJYNBpt9oLUN9DAXgtNyox8Jx1uQYmDuBp5wTS45LPGpDxADVEGiq3M?= =?us-ascii?Q?lYhtNOaNMRI3wckh6ee2D7ZIPzO7vUtetDbD+jefDSyE4x5/7NIbzYMDuD8E?= =?us-ascii?Q?b0WJzkJ2zAfXFXe39LC6X6gwGRvIp1SQB+jSo5PexZp1oqExOgh6e1/GS8aK?= =?us-ascii?Q?Yu X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-ab7de.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 186e6e9b-6c3c-43a3-e3a3-08dc27debf94 X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10109.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2024 13:14:43.4789 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR02MB8627 Received-SPF: pass client-ip=40.92.74.106; envelope-from=arthur.miller@live.com; helo=EUR04-DB3-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 07 Feb 2024 08:18:18 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315972 Archived-At: Drew Adams writes: >> (pcase foo >> ('bar (do-some-bar-stuff)) >> ('baz (do-some-baz-fluff))) >> >> is not more awful or wonderful than: >> >> (cl-case foo >> (bar (do-some-bar-stuff)) >> (baz (do-some-baz-fluff))) > > Exactly. The difference is tiny when the > two are, uh, doing the same thing. > > When `pcase' is used only to do what > `cl-case' is designed for, it doesn't > proclaim immediately to readers that > that's all it's doing. > ___ > > However, our doc actually claims that a > `pcase' version of a similar example is > _superior_ to `cl-case' (not just-as-good). > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68029 > > "This shows that you do need to use a `code' > variable (you named it `val' though), and > that the pcase version is indeed better." > > (The `pcase' example actually uses _more_ > variables than the `cl-case' example, in > spite of the doc claiming that it's better > because it uses fewer.) > > If our doc and a maintainer can mistakenly > think `cl-case' is required to bind more > vars in such an example, then imagine how > mixed up a reader might be. > > The point about using `cl-case' (or `cond' > or whatever else) in particular cases (vs > rather, using `pcase' in other cases) is > that doing so conveys the info that we're > talking about a simple or a not-so-simple > case. > > If you use `pcase' for something for which > `cl-case' easily suffices, that can be less > clear than reserving `pcase' for heavier > lifting (when it's really needed). > > Using them both, each for what it can offer, > can elucidate just what work is involved. > >> And neither of them is worse than what they expand to: >> (cond ((eql foo 'bar) >> (do-some-bar-stuff)) >> ((eql foo 'baz) >> (do-some-baz-fluff))) >> >> Nor is this: >> (pcase foo >> (1 'ONE) >> (2 'TWO) >> ((cl-type function) (funcall foo)) >> (_ 'SOMETHING-ELSE)) >> >> any worse than what it expands to: >> (cond ((eql foo 1) >> 'ONE) >> ((eql foo 2) >> 'TWO) >> ((cl-typep foo 'function) >> (funcall foo)) >> (t >> 'SOMETHING-ELSE)) > > Of course. Did someone argue that `pcase' > doesn't compile or macroexpand to efficient > code? > > It's a style/messaging question. Using > `pcase' for what `cl-case' can't do easily > and clearly can then say, "This here ain't > a straightforward `cl-case' thing." > > You don't have to adopt such a convention. > But you can. Then when your readers see > `pcase' they'll pay attention, looking for > what _particularly called for_ using it. > >> (pcase foo >> (1 'ONE) >> (2 'TWO) >> ((cl-type function) (funcall foo)) >> (`(,fn . ,arg) (funcall fn arg)) >> (_ 'SOMETHING-ELSE)) >> >> I cannot fathom how this optionally available >> "power" is a problem which should consign PCASE >> to only exceptional cases > > No one suggested that. Saying that it can > help to use `cl-case' when it perfectly fits > the bill is not the same as saying that one > should always use `cl-case'. > > The argument is against always using `pcase'; > it's not for always using `cl-case' (or `cond' > or...). > > Use each for what it can do well/better. And > yes, it's only about coding style; it's not > about performance differences. (Maybe ask > yourself why you'd think the question is about > performance?) > >> any more than Lisp's >> power should consign it to only a few libraries, leaving the rest to be >> implemented in lower-level languages; or any more than Emacs's power >> should consign it to only a few use cases, leaving the the rest to be >> implemented in utilities to be piped together in a shell. > > That's precisely the point. One size might > stretch to fit all, but it's not necessarily > the best fit for everything. > > Don't use a jackhammer to drive in a carpet > tack, if you have a tack hammer in your tool > belt. (But sure, you can always use the > jackhammer if you really want.) I think it is more important to be consistent and choose one form than many different if possible. This is a discussion like should I choose setq vs setf. I would agree with Norvig, check his guite to Lisp style from the PAIP book: https://norvig.github.io/paip-lisp/#/chapter3?id=_31-a-guide-to-lisp-style Prefering pcase over cl-case, mean you have one place to lookup the documentation, one "special form" to learn, and so for your users too. A flora and fauna of forms that do the very similar but slightly different is a *-case for future bugs and problems. I would be happy if we had only "let" with the powers of "let*" "set" with the powers of "setf", "case" with the powers of "pcase" and so on. Similar for del* and mem* funcitons. They are parametrized over comparison operator, (memq, memql, member for example). It would be much better to have one function that let us pass in comparison operator, say like this: (member element list &optional test-function) I would prefer it as a keyword argument so the API is similar to hashmap to be more consistent. Similar for delete. I understand those came historically, either as people discovered the usefullness of them, or because the computers from the past where not powerful enough so choosing one that cost least in terms of CPU or RAM resources was an neccessity. But today, I think it is more of peep-hole optimizing. I think Paul Graham is correct when he praises high-level "rapid-prototyping" features of Lisp (I guess he wrote it before the term "agile programming" become popular): https://sep.turbifycdn.com/ty/cdn/paulgraham/acl1.txt?t=1688221954& "Signalling" something to someone by carefully crafting use of cl-case vs. pcase sounds like a lot of cognitive load on all involved parties for very little benefit. You are basically saying that we should use a high-level construct that helps us structure our programs according to their implementation not for their higher-level feature of singaling intention of our code. As Adam point out; pcase let you specify the comparison function, is definitely better than if we had some hypothetical caseq, caseql and case-equal.