From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Code for cond* Date: Sat, 27 Jan 2024 22:06:09 -0500 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1792"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:xxBBcNtQ8MJYKUJAY59U3yqWXQ0= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 28 04:06: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 1rTvVJ-0000MG-Rv for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 04:06:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTvV0-0001lC-3P; Sat, 27 Jan 2024 22:06:22 -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 1rTvUy-0001l4-I8 for emacs-devel@gnu.org; Sat, 27 Jan 2024 22:06:20 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTvUw-0004vJ-Sz for emacs-devel@gnu.org; Sat, 27 Jan 2024 22:06:20 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rTvUt-000AUF-W1 for emacs-devel@gnu.org; Sun, 28 Jan 2024 04:06:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:315517 Archived-At: > > > ;; Execute FORM, and ignore its value > > > ;; (except if this is the last clause). > > > (FORM) > > YAGNI. > > If this were a special feature, it might not be worth having. > > But it is not a special feature. It is a special case of the general > rule that a clause with one element is a non-exit clause. > > I think it will sometimes be useful to execute something unconditionally > in the middle of a cond*. I like the feature (especially since it's how we introduce bindings that scope over the rest of the branches), but I find the syntax too inconspicuous. I'd rather either have some "magic keyword" indicate "this is not a branch", or maybe use [...] instead of (...)? > > > ;; Variables to bind, as in let*, around the rest > > > ;; of the cond*. > > > ((bind* (x foobar) y z (foo 5) a)) > > > ;; Bindings continue in effect for the whole cond* construct. > > > This is one of the functionality missing from `cond`, so I'm rather > > favorable, but: > > - why `bind*` when the rest of ELisp uses `let*` in the names of all > > related constructs? > > `let*' is a Lisp function, and that is reflected in the syntax for using it. > Calling this `let*' would be misleading, I didn't suggest to call it `let*`. `pcase-let` is not called `let` and neither is `cl-macrolet` :-) Having `let` in the name would make a lot more sense. Also, if (FORM) means "Execute FORM, and ignore its value", then the above ((bind* (x foobar) y z (foo 5) a)) would collide with an actual `bind*` function or macro. That's also part of the reason why I considered using (:let ...) when I considered adding bindings to `cond`. > > - Why `*`? > I put * at the end of the names `bind*' and `match*' to go with > `cond*' and thus make it easier to recall how they go together. Also > to make it clear that they are special syntax, not Lisp functions, so > their uses can't be understood like function calls. But there are macros and functions with `*` at the end of their names, so it doesn't make it clear to me at all. In my view of the Lisp world, when you talk about symbols that represent special syntax that are only given a meaning by where they're used, I think of keywords instead (hence my use of `:let`), which cannot be used as variables and by convention are never used as functions either. > > - I'm not happy about using the same construct for "bindings > > for this clause" and "bindings for subsequent clauses". > The alternative to having a uniform rule to distinguish a non-exit I do like such a uniform rule. I just think it needs to be more visible than just the absence of something before the next close paren. Stefan