From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Psionic K Newsgroups: gmane.emacs.devel Subject: cond* Examples Date: Mon, 6 Jan 2025 23:55:09 +0900 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39430"; mail-complaints-to="usenet@ciao.gmane.io" To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 06 15:56:12 2025 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 1tUoWZ-000A6x-Tw for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jan 2025 15:56:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUoVp-0006No-RR; Mon, 06 Jan 2025 09:55: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 1tUoVo-0006NW-0i for emacs-devel@gnu.org; Mon, 06 Jan 2025 09:55:24 -0500 Original-Received: from mail-yb1-xb33.google.com ([2607:f8b0:4864:20::b33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tUoVm-00006c-8T for emacs-devel@gnu.org; Mon, 06 Jan 2025 09:55:23 -0500 Original-Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-e3c9ec344efso17228639276.2 for ; Mon, 06 Jan 2025 06:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1736175320; x=1736780120; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ctHzlibxTNNc5pCtAF1LhF7EMjkAhibD4t5Bmyx4soo=; b=JkW4+R/SdxsCUUgrRrYxzBKcbUMncpSbeVkTGYXObL+jKrLMq3lr1Y0vWLjMQ14475 SMDdzmxXkAKz7VeW5e5iaGOnZ9g1aBQVdPxqbo07jKHc52Q1XGJMGshhHKipQvk3FMy5 kx2jdMKt5KjX11mw7KN/e5l4zzRmWP4Xzvqsbm3MhOSfwJxguG8xdtFYokaafkl21UMZ vhbR0Lh6FEyAaB9rVR8gheRwdWhF53xP9wn+KJZpqPuRWC6P8JgljhIps+h9u8s5nbLy XLTCynH8XXJWqto/nckv0rDEL0CDjWpFG9UYQkQoQVZCcbXyOiCYr2G5ilN1BsEufioI eeNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736175320; x=1736780120; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ctHzlibxTNNc5pCtAF1LhF7EMjkAhibD4t5Bmyx4soo=; b=XARGRb3LcBQea8WRI8S+RqnAvhSL4/6lnbhbpIc7WO/7sz4hdF9l0O14hp0mI3BHQh HptfappT4Kh3ovvOhHO+biQsI9KFH+NJkm5nHp9iUASeBoUVQHqWfLLJiTXccD6X6J74 nYc6mwmNTsH3DjLqef0ONWCZ7kTG496JwKC6LmNYWFP8r1Q40vssC3BCQjKJ3vnq7bK5 Z3fqOImftdRVBqCZ7CXF2mP25hpQUiFC7H8Bz9Qt4RpPZMFDDOzneKZlRvXcFEHMbZPn kZVIXqpR0Sm++zsapADT8s65CFjmD9JI0RtzTu80lXojUyP7a6xIMeF1/58hjGNgTp+y MqEw== X-Gm-Message-State: AOJu0YyHpNEuZpQv14fcZ7llHEDDqSV/sHUI4d+Cebo6nljYDKEuJF3A WF0YbqdckzOramoMUKUxZZCmnDXOzgfd2uj3YfswwGayr6QOoJzb4z51SZeKqLKc7qL2BIrkbOx n65rvuDZmGFJkbmUpBL+Br07zRWjh4L6USOo31G4wlXsprOCRgpGBdw== X-Gm-Gg: ASbGnct7Dkn+5bcr4VvsRhO7X4fGlSwzQHvKbwiem27pOpZPEVDm6JxqOcKNZpSBzzp KDJr1p6jrb+gRHdVdoz1EErYj93urm5Kb+8UQNhhB X-Google-Smtp-Source: AGHT+IHBOqMyzvKKVPX88V10Liq+ub50DdToaOg7a2KRunRexJOvViyCRzknxEQjVIhJ59+NM/IxrwX8WZWy9T3mVCk= X-Received: by 2002:a05:690c:3612:b0:6ef:366e:a6a3 with SMTP id 00721157ae682-6f3f80d63f3mr437658217b3.9.1736175319895; Mon, 06 Jan 2025 06:55:19 -0800 (PST) Received-SPF: pass client-ip=2607:f8b0:4864:20::b33; envelope-from=exec@positron.solutions; helo=mail-yb1-xb33.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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:327738 Archived-At: I'm putting together some examples on Elisp forms and wanted to get ahead regarding use cases where cond* is more ergonomic. The closest example I can relate from other languages is a Rust match statement, which both destructures and binds before taking one matching arm. Since cond-star's package docs say it's a replacement for `pcase', that explanation is consistent at a surface level. Regarding `bind*': > it counts as true if the first binding's value is non-nil. This feels inconsistent with `when-let*' and `if-let*' behavior, where there's an intuitive reason that every bind must succeed for the first or all body forms to evaluate. Is this a first-pass tradeoff? Regarding exit clauses > and it exits the `cond*' >From this, I expected the next part: > If a clause has only one element, or if its first element is > t, or if it ends with the keyword :non-exit, then > this clause never exits the `cond*' construct. Instead, > control falls through to the next clause (if any). > The bindings made in CONDITION for the BODY of the non-exit clause > re passed along to the rest of the clauses in this `cond*' construct. Yeah, okay, so we're definitely evaluating multiple BODYs in some cases. I read the tests, new manual section, and news. I couldn't find the mailing list entries since I didn't subscribe and while I'm positive I've seen many cond* threads, no query that I provided Namazu was effective. In any case, the goal is to identify 1) the point where cond* becomes necessary. For example, in the case of let*, I can say that whenever bindings become dependent, it is necessary to use let*. 2) where cond* becomes advantageous. For example, when using let* over its equivalent sequentially nested let form, the advantage is readily evident in the reduction of form repetition. It's natural that necessity and advantage tend to go together here. >From what I can gather and deduce, cond* is a variation of a cond where I want to compose several destructurings into the same scope, conditionally, so the equivalent in Elisp today will compose several logic and pcase expressions, and this may lead to some repetitive binding until the natural flow of the logic is discovered. While cond* seems capable of short-circuiting this repetition by propagating binds, I am less clear on natural cases where I want to bind from an inner rather than outer form. Compared to let*, the existence of many inner macro calls makes me wonder what I am compressing out. Why not a sequential match* for such a composition of dependent destructuring binds and then no repetition of match* in the inner forms? In fact, I fear the use of cond* for its expression of both logic and destructuring within one macro will obfuscate the purpose of why it was employed. It does almost everything. As for what is not included, it can't be used for looping except as an inner form. How intensely jealous I am of Clojure, Rust, and Python, where destructuring is quite natural in the other elementary forms, including iteration, logic, and binding. I do sense some idea trying to get out. If the destructuring form is not understood by let, let*, if-let* etc, then we are forced to choose between destructuring and logic. Other languages are blessed with both and profit greatly from it. Cond does seem to be reaching towards such a composition. One idea I like from cond* (at least described in the documentation that I was unable to find in the implementation of) is this notion that the form is limited to comprehending other symbols bearing the "cond-star property" as clauses. It all makes me intensely jealous of languages for which every conditional binding or iterative binding form can also destructure. What a magical world if let, while-let, and if-let could destructure and if let itself could be composed with a conditional expression without a distinct macro such as the one named if-let. If only there was a tool to dispense with redundant parentheses around inner calls to further macros.