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: Installing cond* in core Date: Sun, 28 Jan 2024 19:14:06 +0000 Message-ID: References: <868r4a6lbb.fsf@gnu.org> <3cf3ba2d-873f-44d8-81f4-420d8954fd8e@gutov.dev> <6415235c-b06c-41b2-9909-39ecc74a6873@gutov.dev> <0f7c3969-7b57-4ce4-87e7-5f86e712c2b5@gutov.dev> 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="13420"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , stefankangas@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 28 20:15:05 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 1rUAcT-0003Jh-2T for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 20:15:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUAbe-0007Oj-Im; Sun, 28 Jan 2024 14:14:14 -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 1rUAbc-0007Mm-72 for emacs-devel@gnu.org; Sun, 28 Jan 2024 14:14:12 -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 1rUAbZ-00079X-Tl for emacs-devel@gnu.org; Sun, 28 Jan 2024 14:14:11 -0500 Original-Received: (qmail 22270 invoked by uid 3782); 28 Jan 2024 20:14:06 +0100 Original-Received: from acm.muc.de (pd953ae19.dip0.t-ipconnect.de [217.83.174.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 28 Jan 2024 20:14:06 +0100 Original-Received: (qmail 12909 invoked by uid 1000); 28 Jan 2024 19:14:06 -0000 Content-Disposition: inline In-Reply-To: <0f7c3969-7b57-4ce4-87e7-5f86e712c2b5@gutov.dev> 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=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:315566 Archived-At: Hello, Dmitry. On Sun, Jan 28, 2024 at 18:54:18 +0200, Dmitry Gutov wrote: > Hi Alan, > On 28/01/2024 16:32, Alan Mackenzie wrote: [ .... ] > >> We're yet to see whether cond* is any better in those areas. > > This is true, but it's highly likely cond* will be better. It's > > being designed by an expert designer, and has been through a phase of > > open comment and revision. Also, it takes advantage of the > > experience of pcase. > A new macro that went through a few rounds of revision with no real > consumers yet vs a macro that's been in use for 14 years. Yes. The 14 year old macro has acknowledged faults, the new one doesn't as far as anybody yet knows (although it has an area of controversy). > Have you actually tried it yourself? E.g. to rewrite some code > conversion logic that you urge to replace? No. It is not yet working. > > [ .... ] > >>> That's not the way things happened. pcase was simply installed in > >>> Emacs, with all its faults, and then proliferated round Emacs. Where > >>> was the room for discussion? Discussion is difficult after something > >>> has already been done. > >> We're doing it all the time by commenting on commits in an email to > >> emacs-devel. > > To have been effective, such comment would have resulted in the removal > > or fundamental alteration of pcase long after it had been ground into the > > core of Emacs. That just wasn't going to happen. > > You weren't there at the time. I was. I was completely unaware of pcase > > happening, and it was a shock being confronted by it for the first time. > If you weren't aware, then you weren't working on that area of code, right? I was not. pcase was first committed on 2010-08-04 in commit d02c9bcd096c44b4e3d5e2834c75967b56cdecdd. There was no prior discussion about it on emacs-devel. > >>> If you're trying to say that pcase is better than nothing, so people use > >>> it, then I'd agree. But if you're trying to insist it's as good as it > >>> could be, > >> One does not need to insist on that to disagree with your original > >> statements. > > You cannot disagree with my original statement made last night. As I > > said, you weren't there at the time. > I don't have to insist it's as good as it could be to object to throwing > it out. Your wish has been fulfilled. Eli's and Stefan K's decision from last night is 100% in favour of those who want the use of pcase to carry on unchanged. cond* has been consigned to a few niche uses before it is even up and running. > >>> I'd ask you why Richard is spending a lot of time crafting a > >>> better replacement. > >> Rewriting other people's code that one doesn't understand has a long and > >> varied history in software development. We even have a term for it. > > You're suggesting in that paragraph that the fault lies in Richard's lack > > of ability. That's uncalled for. He has trouble reading and > > understanding code written with pcase, as do I, and as do others here. > > The fault is in pcase; it is flawed. At the same time, it is not doubted > > that there are people here fully conversant with pcase. Having such a > > split in the project is a bad thing. > Having trouble with doing something is the literal definition of lack of > ability. "Lack of ability" means a general inability to get things done, unless qualified somehow. (English is my first language.) The fault lies in pcase's unreadable syntax. It is not personal. > Not the lack of talent, mind you, or potential, but insufficient > understanding and skill with that tool (destructuring pattern > matching--which is not unique to Elisp and has carryover from a number > of other programming languages) is what motivated this whole argument. Unlike most of Emacs Lisp, pcase is peculiar in that only some hackers can get to grips with it. You seems to be one of them, I am certainly not, and neither is Richard. The decision recently taken will mean you need not trouble yourself with cond*, and people like me will continue to be hindered and slowed down by pcase code for the foreseeable future. > And I'm really skeptical that when cond* goes through all the additional > revisions and gets as powerful as pcase, that it won't raise all the > similar questions. Possibly, but not inevitably. Its syntax is kinder on the eye than pcase's. Maybe people would object to it because it requires the use of multicharacter keywords and is bulkier, and so on. I can't tell at this stage. > But I guess we shall see. I doubt we will. My proposal to test cond* by putting it into macroexp.el was vetoed by Eli. The decision taken was not to replace any pcase with cond*. Where does that leave cond*? -- Alan Mackenzie (Nuremberg, Germany).