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: combining cond and let, to replace pcase. Date: Sun, 26 Nov 2023 22:11:47 -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="37729"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 27 04:12:20 2023 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 1r7S2l-0009bY-E8 for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 04:12:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7S2G-0004a2-RQ; Sun, 26 Nov 2023 22:11:48 -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 1r7S2G-0004Zb-7P for emacs-devel@gnu.org; Sun, 26 Nov 2023 22:11:48 -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 1r7S2F-0002ki-VD; Sun, 26 Nov 2023 22:11:47 -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=RCx96Zj97/tnI2wUvmuQ1LPSX3vwQOVROJNFBKUNH7E=; b=FEYgZOwsHHC4 kM1O4g7m4lNDKdFDdcoHzU1gqOulIVyXsT3kzVaKFcbet+DoBSqe6Gmkjobv+3baPFknyklHwpppW 5+dcl4BGeG30lSyrbdyvSkI1W80msZ3UY5xszhXXYzef6ENH4jBT973Gfy69If4bWDvKv0oXx9iVN 5vIARbjIv52ydtRCL1mqrCtF/+ceJiQZIAdrEGdADPD8P3l8N8cYjCRRNYg7/LNTPA5c2uTpuXyBg 4OpLRktdhLAojGI5ZE6rrHtGDZomonBcqLzRLmAmBsnYyyRDI2v3yJnRGKriaLRxjnsSlkmothGKp B5Xy0e2uHdk7ZTsheLa18w==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1r7S2F-0004Tk-NE; Sun, 26 Nov 2023 22:11:47 -0500 In-Reply-To: (emacs-devel@gnu.org) 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:313256 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. ]]] > (defalias 'match-set #'pcase-setq) I'm not defining these constructs based on pcase. I'm defining them to be useful together with cond*. If one of them resembles a part of pcase, that is a coincidence even if not entirely surprising. Maybe we can copy parts of that pcase code with changes, smaller or larger. However, the definitions of these constructs will not depend on pcase. > There's a tradeoff here, indeed: sometimes I find the added ((...)) > of `pcase-let` rather annoying, but other times the fact that it's > a superset of `let` means I get to mix it with normal bindings without > increasing the nesting depth, What does that mean, concretely? I am not sure. I have (not coincidentally) little experience with reading code that uses pcase. -- 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)