From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Instead of pcase Date: Wed, 15 Nov 2023 22:04:37 -0500 Message-ID: Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24127"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 16 04:05:21 2023 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 1r3Sgx-00062D-03 for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Nov 2023 04:05:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3SgL-0001JO-6G; Wed, 15 Nov 2023 22:04:41 -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 1r3SgH-0001FU-TO for emacs-devel@gnu.org; Wed, 15 Nov 2023 22:04:38 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3SgH-0004lR-L3 for emacs-devel@gnu.org; Wed, 15 Nov 2023 22:04:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:Subject:To:From:mime-version:in-reply-to: references; bh=X8B2oQr0XcefiMVbOrLJo6JxwlqRVW2/h1TvX4QTNQM=; b=sK9qdIHp9TBu9H Xp/R7umt9oNjC9H5r8EdIvGITY8bh4+QD0JGPkHNHUnEsqgVrG22VsuVlvagkWAU30AgllK7pUJHB 3SC47LrdAt5HimhUqPDEgV4aHZBafCyedWOUjyhYVlUFQ2v/dTyzDkEcDJhA7uVfKAoD/dcsoxgqJ pF180vJgrM7PkN/85qLHInQtppDwH9ITzGKLsncDW2+kJDjICxeCXMUVIkxwFyb++TRZguXwOPcf3 rRLX+N9URSksRuIjyVD5YNaZES5hrlYeQZanUMAXTbxjTlrZ60qyHFzeiLLotVsvSWvtFHgODbDfu QQNbMSD8Alhe+Bt9Drhg==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1r3SgH-0007Rb-BU; Wed, 15 Nov 2023 22:04:37 -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:312778 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] `pcase' is a big and unnecessary complication on Emacs Lisp. I think its presence worse overall. One can easily think of `pcase' as "just another feature", like each of the thousands of other predefined functions and macros in Emacs Lisp. But that picture is incorrect for `pcase', because it does not count the cost of `pcase' in complexity. What makes `pcase' such a complication is that it introduces an additional "little language" that duplicates the functionality of part of Emacs Lisp. Even worse, that little language is so concise it is downright cryptic. I can see why people want something along those lines. Using `cond' and `let' to do these jobs feels long-winded and cumbersome; they were not designed to make this easy. So we wish for something to make such code more concise. `pcase' does indeed make such code more concise, but it takes that conciseness to an extreme by defining its own cryptic little language, That is going too far. Using `pcase' in your own private code concerns you alone. Using it in released packages that others use but others rarely change or study is not a big deal for the community. However, putting `pcase' into many packages imposes this cryptic little language on all of us. There are other little languages in Emacs, but most of them are limited to special high-level purposes -- which means that hardly any of us need even be aware of them. For instance, there is a little language called "quail" which is used for concisely defining input methods. Its specific purpose is a high-level purpose. If you don't work on input methods you never need to learn quail. It's just the opposite for `pcase' -- its specific purpose is a low-level purpose, so it could appear in any part of the code of Emacs, The burden of its complexity can fall on any or all of us. Those of you who are fans of `pcase' may not recognize the cost it imposes on the Emacs Lisp language. You paid that cost already, perhaps a few years ago, and perhaps you enjoy each new language construct you learn. Perhaps, for you, the more complexity of features to be learned, the better. But don't argue that this cost does not exist, simply because it doesn't feel like a burden to you. So... I'm looking at adapting some of the features of `pcase' into other constructs, so as to make type-discrimination code more concise than in old-fashioned Lisp, but _not_ so concise as to be cryptic and burdensome. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)