From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Alfred M. Szmidt" Newsgroups: gmane.emacs.devel Subject: Re: Code for cond* Date: Thu, 25 Jan 2024 11:12:52 -0500 Message-ID: References: <1AD5807F-91F7-4B92-BCB0-D0FEA904A75D@gmail.com> <67B51664-352E-4EB1-AE17-6D571999FDDE@gmail.com> <4B3E3A7E-677C-43A2-92B3-562E99A8B897@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37555"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jdtsmith@gmail.com, enometh@meer.net, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 25 17:13:42 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 1rT2MI-0009b3-EP for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Jan 2024 17:13:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rT2LX-0003KV-KW; Thu, 25 Jan 2024 11:12:55 -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 1rT2LW-0003KN-M2 for emacs-devel@gnu.org; Thu, 25 Jan 2024 11:12:54 -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 1rT2LV-0001kQ-7n; Thu, 25 Jan 2024 11:12:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=/HoB5H82YS+AIYPkDIgjW/Dc3CYlY3uaQQHwGidAN2Y=; b=issv26fSrm6L TnVx8MI+OSZctRyS00hrQpewCbGqk1OUNhHNDXGXzpmSvcu0Q31ZDPIICS1CXS/T37OINGHUBR/tx F1wmYwT7kMou5vPD2U3VvCmj3k8j7CQ3xk/2RcfpYleoGzBAlOxWa9D/1uS2y3PKaFoVdyuDLMrkQ cIyHOOCAKckzc8lwI67oVXppm6uhnmT8OD/o2ZaUnhhUzZG2vCz7NucFUdEL61GUkJKEXEwPlI250 u+lYnEfNeROzGzKTm4KGU4e8I+60jGH0bgrURH2JlVacablkGAhB0FB5heSTkoK8CstyPIJkQ5YY1 PZGiqPRryr9v3TZ2D9F2dw==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rT2LU-0005nz-EK; Thu, 25 Jan 2024 11:12:52 -0500 In-Reply-To: (message from Stefan Monnier on Thu, 25 Jan 2024 11:05:16 -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:315376 Archived-At: > (cond-let > (:let var-for-rest value) > > Is there a reason why using a keyword here? It was to "ensure" compatibility with existing `cond` code. I really hope we are not going to modify cond -- which has been literally the same since it created many decades ago. It would be confusing to all Lisp programmers, even if it was backward compatible. Also it was based on the premise that most `cond`s would *not* use it since such code is mostly needed to replace things like: (let (val) (cond [...] ((foo (setq var (bar))) [...]) [...])) And while such code does occur, it occurs only in a minority of `cond` uses, so I thought it would be worthwhile for it to "stand out" so as not to catch the reader by surprise. Are such cases really worth solving by extending cond, and not better addressed in a different macro (cond*, pcase, ...) -- or even just sticking to the status quo? The above "idiom" is much easier to understand since it just uses well known Lisp behaviour than modifying cond even if it is really ugly ... the feature is a nice addition, but is it worth it?