From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Code for cond* Date: Fri, 19 Jan 2024 22:39:38 -0500 Message-ID: References: Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6054"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 20 04:40:35 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 1rR2Dj-0001I8-0A for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jan 2024 04:40:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rR2Cr-0002SP-4d; Fri, 19 Jan 2024 22:39:41 -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 1rR2Cp-0002S5-3F for emacs-devel@gnu.org; Fri, 19 Jan 2024 22:39:39 -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 1rR2Co-0007wc-S7 for emacs-devel@gnu.org; Fri, 19 Jan 2024 22:39:38 -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=emvfn4L1d2GyGmK+AmybQSPYDhsZdWx5LNFRfnZWXsw=; b=q585ZAmOyeST T29MWkZJqozzd+ws5/1u82EafkuX5P4+O+IYBtsb5IYnkFDFlPdk4PD/jC/7FVt+bzgVdKa0fsIZZ VpuV+joJru34C4ip+JB8f9nniO6jtjg6DmxlFQG7ftalIOSgpKbXMG2R0Mq6f8ShZPUkeZ+XDgQS9 0ZPczmr9XqiWOITmsK8V4uL+MUltu2vAuJVy751owADL+7KPU9MEbiMMjIlHII4dy0pZQo00klHqy oCIqsoGVN0pJs4Zs+46GSODWevx4CuPSd7olu4ZZECILHjw6PetmC2UHAa2V2AlpH3rogBZFHtoMy H2wsTB3+j7iUASLdsf5SrQ==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rR2Co-0003Oc-JC; Fri, 19 Jan 2024 22:39:38 -0500 In-Reply-To: (message from Andrea Corallo on Thu, 18 Jan 2024 10:44:00 -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:315129 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > apologies if it was discussed already, wanted to ask: what is the reason > for some of these cond* clauses to keep the binding in effect outside > the clause itself and for the whole cond* construct? One of the long-bemoaned inconveniences of cond is that often in mid-cond one wants to bind some variables and then proceed with more cond clauses. Lisp programmers have complained about this for decades. Sure, you can do (t (let ((temp (cadr whatsis))) (cond ((eq temp 'foo)) ... but this increases the indentation by 11 columns. bind* gives the same effect without deeper nesting. Consider the definition of cond*-subpat. If I rewrite that using cond*, I would bind a variable to (car subaat) after the clauses that deal with atomic subpatterns. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)