From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Installing cond* in core Date: Sun, 28 Jan 2024 22:43:13 +0200 Message-ID: <712b4942-ff82-4510-ba38-1398b4b90663@gutov.dev> 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=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4555"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , stefankangas@gmail.com, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 28 21:44:20 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 1rUC0o-0000z1-4I for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 21:44:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUBzx-0000S8-I9; Sun, 28 Jan 2024 15:43:25 -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 1rUBzv-0000RI-TM for emacs-devel@gnu.org; Sun, 28 Jan 2024 15:43:24 -0500 Original-Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rUBzt-00061W-5H; Sun, 28 Jan 2024 15:43:23 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 7D6AA320099B; Sun, 28 Jan 2024 15:43:18 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 28 Jan 2024 15:43:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1706474598; x=1706560998; bh=q41dAkF+3N77SExQXVxVo1yBGL+WriJqxXWUbsB2TnE=; b= bQBBeclEZ6Z5CmLIxNekfeiLTOUhf+pABt0Qq0qGl61KOuWXaqhS/4XGKPKjfp/c AK7keCMxXkGRvUy3qWnq/1XX21FrL8goFYS6S14T7Wa6gTwcitjxTRiAojqZYuK5 O2AVWCaJ4dHv9FacanZq7uWxuJpFQ8Y7GIALihubyRBOexwetJhyWz9upvwqgf6E h1lMLMCCAyQWIpwPdzUWMvPo+gJzktxGsCPFeSv+NkJGXMStFgj2G1YsuWeb5auL YO2/ip3J3B69HvbYkoeIkAcEYMm/60koS9S26faidNcJwyEzue5/oCUV2Ud8Gyeu D1VymMKjdNcSQSf9cXw+Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1706474598; x= 1706560998; bh=q41dAkF+3N77SExQXVxVo1yBGL+WriJqxXWUbsB2TnE=; b=A c9MMJUML3D9ezqThNavcygT1NxjlY1jJ2WdOElqrpWXhnn13fOU7BgW/2ZAJ22WI SM7wMfzRzufE79HTv6JRHVnRJkt5V893EXhlPnXO2qCIe3KWPHfnITNo2ZjivNA0 1bCMxBS833caG58VMOJx+krbF9L3mT+5UHhWjK4Izekx+we2R9Tyy+8OjLqGSc6r zi4sO0aGVeG/627FyTKOFXXKA0uXR2hSGT6sb0G7Grmrnb78uae5cA8GdgOzozZD eJqv44sTO5SaSdSU69KbWOgUux4Aj9YH+uZq/TUxPJTOJyZJ18K8P7b74u7gK+Y1 DkVi0etfrfTBAso7g62QA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedtvddgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeegvdegieeuhfetieeufeevffelvdffffeugeffgfejfedtudehgffhtdet feejgfenucffohhmrghinheprggtmhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 28 Jan 2024 15:43:15 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=64.147.123.19; envelope-from=dmitry@gutov.dev; helo=wout3-smtp.messagingengine.com X-Spam_score_int: -36 X-Spam_score: -3.7 X-Spam_bar: --- X-Spam_report: (-3.7 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_SBL_A=0.1 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:315570 Archived-At: Hi Alan, On 28/01/2024 21:14, 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). A bunch have already been mentioned. Including (but not limited to) the gratuitous incompatibility in syntax where it doesn't have to be different when Stefan mentioned lately. >>> 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. So, you wanted it to have been discussed with... simply someone? I'm guessing it must have been, in public or in private. And if you were looking for the reasoning behind it, there are a few paragraphs about it in Stefan's paper: https://dl.acm.org/doi/pdf/10.1145/3386324 (Section 8.3, page 37). >>>>> 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. The proof is in the pudding. Personally, I *would* have put it in ELPA after some sufficiently broad announcement that there is this new powerful syntax endorsed by the maintainers of Emacs (or some of them), that the package authors could use. And see how well that turns out. The alternative-syntaxes packages (like f/s/dash) have been fairly popular among the package author community. But for some reason people who don't like pcase here, don't seem to like ELPA either. For my part, I'm concerned that cond* turns out to be a weaker, arbitrarily incompatible version of pcase, and only practice can prove otherwise. Committing to changing a whole swaths of code to it risks fixing in stone any current deficiencies. Not to mention that taking over the code that Stefan still maintains to an extent would not be very friendly. >> 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. Just to be clear, I like pcase not because I am particularly clever, but because my brain can only fit a limited number of things at a time (ideas, processes, or words on the screen), and a succinct syntax that uses principles I can recognize allows me to understand such programs quicker, cutting out the boilerplate. >> 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. If being slightly more verbose is going to be its only problem, I'd say we're in a good place.