From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Code for cond* Date: Wed, 24 Jan 2024 12:15:20 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5201"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, joaotavora@gmail.com, acorallo@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 24 13:16:07 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 1rScAp-000169-N6 for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Jan 2024 13:16:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rScAN-0006DE-3b; Wed, 24 Jan 2024 07:15:39 -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 1rScAK-00066n-S9 for emacs-devel@gnu.org; Wed, 24 Jan 2024 07:15:36 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rScAH-0001a5-C6 for emacs-devel@gnu.org; Wed, 24 Jan 2024 07:15:36 -0500 Original-Received: (qmail 4375 invoked by uid 3782); 24 Jan 2024 13:15:21 +0100 Original-Received: from acm.muc.de (p4fe15939.dip0.t-ipconnect.de [79.225.89.57]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 24 Jan 2024 13:15:21 +0100 Original-Received: (qmail 6688 invoked by uid 1000); 24 Jan 2024 12:15:20 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:315295 Archived-At: Hello, Stefan. On Wed, Jan 24, 2024 at 01:48:53 -0800, Stefan Kangas wrote: > 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. Richard's point, and I agree with it, is that pcase is so far from perfect that it needs replacing. > 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'. It is not a version of pcase. It is more like what pcase should have been in the first place. > 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. What is its "success"? It is a failure, being accepted only by some Emacs hackers. It is difficult to learn, it may be easy to write, but is difficult to read, and difficult indeed to debug. > 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. I think this is the plan, yes. We can replace uses of pcase with equivalent cond* uses, thus improving the readability and maintainability of our code at a stroke. > If it does _not_ come with such a plan, it's slightly better. But then > that begs the question: why add it? To solve the problems that pcase has. > 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. When pcase was introduced, it was quickly and systematically forced into (?)every bit of code it would conceivably fit into. Something similar could be done for cond*. > 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. cond* was designed with the benefit of experience gained from pcase, and also after extensive open discussion. pcase had neither of these. It is highly likely that cond* will be considerably better than pcase. It is a bit like programming languages. The Lisp we use in Emacs now is quite a bit different from the original Lisp of 1957. I'm sure we all agree this is a good thing. > 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. That's just a way of ensuring it never comes to anything and just gets forgotten about. If that is done, it will be impossible to replace any of the pcase uses in Emacs with cond*. A better way of doing this would be to create a feature branch, which can later be merged into master once its advantages become clear. -- Alan Mackenzie (Nuremberg, Germany).