From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Code for cond* Date: Wed, 24 Jan 2024 01:48:53 -0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1718"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acorallo@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org To: rms@gnu.org, joaotavora@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 24 10:49:31 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 1rSZsx-0000CH-QY for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Jan 2024 10:49:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSZsS-0005El-IA; Wed, 24 Jan 2024 04:49:00 -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 1rSZsQ-0005EX-Cs for emacs-devel@gnu.org; Wed, 24 Jan 2024 04:48:58 -0500 Original-Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rSZsO-0007Ad-OA; Wed, 24 Jan 2024 04:48:58 -0500 Original-Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-55a50649ff6so5811097a12.3; Wed, 24 Jan 2024 01:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706089734; x=1706694534; darn=gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=YlT63HDb5xIlYFzx8RUS/rsLKGg0nJRp6uoFZGF0pWo=; b=YfGyhfF3tVP7fp//U+8nU66ysVV4j6zn0SRNMu5lhTvJ6mNbMHwHdEy4Srx6z8bF4p 9C/p0a6QbnMFJROJjRdpuSONd/al44HTPDl3c658LBdwJ1sIUmoHJVKTa8oiQdrOLYMY Eu4ow5YPaYp+5/uWxRuo9VqQDaFLmopjyuBlwfwoD1/jlkJulSs6fbRqX7fzUMmqKgnf SJbODHZaJ+ebVpFTX+laH/WJ4WuTZZwKKLm60OEDE2K1BbJQVJfUcgHfQNyRjAg9+gxw r1deXR9ptb/RIXLxss5cNPMC2zaq5n/NhxiMTlYF6YTMtLxjGW4CQFn5A4abWAmPMto4 XB+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706089734; x=1706694534; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YlT63HDb5xIlYFzx8RUS/rsLKGg0nJRp6uoFZGF0pWo=; b=GiDOjxihMQ9bfWDnJYecyzQc6WLIn11W28xg4Fl+DSJvczk7Gofs6do9GGI3RxYm2X T38KTKJUG+S7qGWvuN/WFIEEN3MloGAPtYbP8bo/pC3BJXTSEQCxQKVQVFTzCyLVexxC 7cxxq0Hd4JeVC5rEkEV/q5OJs9eG6gLYTLFOPsV7ciiiEB3eE4aXnZcqpQIJs5LMG9jU 5ZKjWFULu6NR34DiqRMGv/fMXVWtLvvWdq2ycAyriW92MsH7CGq77WHzjAwmfgLh9Fh3 5XMhxhpGjChyIKLAypytF8Z52TD6MAENvBLvFgpwmyacn9evA8xeU48qL/LuUUFbtyw+ LXTg== X-Gm-Message-State: AOJu0Yyk9gpPLqt+Llozxdzy3BgjUi/0ksagJAT+hloWLWjrH2BggILu hhcsO3v+LzLs7LkDqbW/R6MlvVMHFyyDZmRfcEhybf8lGGNEvxMJwu9tArBJI30ifzKjiOD3g7o jfJGIY0FW55R+Xc2Ve7mq2Zh0Qim1XEDwWqA= X-Google-Smtp-Source: AGHT+IHpZppGKAzD1Yu8AFY2AXP8wB0zAifLprSwUcUt2jcGT4Tb4BoSyEWx6D/RGSfu6uBS56PdYY5v4AKUmrzje5Q= X-Received: by 2002:a05:6402:5244:b0:55c:a7c6:e617 with SMTP id t4-20020a056402524400b0055ca7c6e617mr625041edd.47.1706089734178; Wed, 24 Jan 2024 01:48:54 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Jan 2024 01:48:53 -0800 In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::536; envelope-from=stefankangas@gmail.com; helo=mail-ed1-x536.google.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:315287 Archived-At: Richard Stallman writes: > I'm going to do some more testing and then install cond*. I'm sorry for paying so little attention to this. I was not aware that there was a plan to install `cond*', or I would have spoken up sooner. While I don't want to claim that `pcase' is perfect and impossible to improve upon, I don't find `cond*' convincing. Whatever else is true, a new macro will increase the complexity of ELisp and make the task of maintaining Emacs harder. If the downsides to having two ways of doing the same thing are to be worth it, it needs to be demonstrated that the new one offers substantial improvements. Here, it is not clear that `cond*' offers much in the way of either simplifications, or powerful new ways to express ideas and solve problems. What I see instead is a mere _version_ of `pcase'. Now, the `pcase' macro has been with us for 14 years already, and we have had plenty of time to learn its ins and outs. It's heavily used in many parts of Emacs, and many of us rely on it as a matter of routine. Its success is not surprising, given that this style of pattern matching is increasingly common in other programming languages. Does the "install `cond*'" proposal come with a plan to replace `pcase' everywhere? That sounds like a bad idea: it would lead to code churn, unhappy maintainers of subsystems that use `pcase', and, of course, bugs in both the code being changed and in `cond*' itself. If it does _not_ come with such a plan, it's slightly better. But then that begs the question: why add it? To avoid having to bikeshed about whether or not to use `pcase' or `cond*' every single time, I think we will have to capitulate the argument, as we sometimes do, and say that the choice is a matter of personal style. Which, if we are being really honest, it really is. We will end up with `pcase' for those that happen to prefer that, and `cond*' for those that happen to prefer that. For me, as a maintainer, I now have to know not one, but two relatively complex macros. While I realize that ELisp has been largely designed in an ad-hoc way, consciously introducing such needless proliferation does not strike me as a particularly good way to design a programming system. In summary, I recommend installing `cond*' as a new package on GNU ELPA. This is a good way of exploring an alternative version of an existing macro.