From: JD Smith <jdtsmith@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Code for cond*
Date: Tue, 23 Jan 2024 23:49:06 -0500 [thread overview]
Message-ID: <1AD5807F-91F7-4B92-BCB0-D0FEA904A75D@gmail.com> (raw)
In-Reply-To: <jwvv87kvtey.fsf-monnier+emacs@gnu.org>
In general I’ve always felt cond by itself was missing some functionality and could really use the ability to make bindings — a cond-let if you will. Even making and testing bindings local to each cond clause would be a real advance[1]. Pattern matching adds another level of complexity I hadn’t considered, but overall I'm supportive of efforts to improve cond.
I’ve used pcase lightly, but to be honest have always winced when I have encountered it in code I really need to understand. As others have already discussed, the similar looking but in fact semantically distinct domain language has always thrown me (unlike cl-loop, whose language is not easily mistaken for regular elisp syntax).
But oddly enough, this thread discussing its potential replacement has given me the key insight — “imagine running list interpolation backwards”. With that mental model, I find I can now read pcase forms much more easily and confidently. A short introductory paragraph in the elisp pcase documentation which explains this approach to its novel syntax would have gone a long way for me.
> On Jan 23, 2024, at 1:10 PM, Stefan Monnier via Emacs development discussions. <emacs-devel@gnu.org> wrote:
>
>> ((match* `(expt ,foo ,bar) x))
>> ;; Bindings continue in effect.
>
> Same comment as before: I like having both "bindings for the clause"
> and "bindings for the rest", but having the two be syntactically
> identical will lead to confusion.
This is a significant concern. If I’m understanding the design correctly:
(let ((var outer-value))
(cond*
((bind* (var (some-complicated-function-that-returns-nil))))
((bind* (other-var (some-other-function))))
<... lots of other clauses>
(t var)))
would return a different final fall-back value than the nearly identical form:
(let ((var outer-value))
(cond*
((bind* (var (some-complicated-function-that-returns-nil))) t) ; <-- hidden danger
((bind* (other-var (some-other-function))))
<... lots of other clauses>
(t var)))
with a single `t’ added, perhaps a page above, deep inside a sibling clause. That kind of “spooky action at a distance” would in my view lead to hard to track down errors and difficult to parse code.
Perhaps let* could be used for binding variables within clauses, and bind* for bindings which remain in effect for the rest of the construct, ignoring any final value given in the ((bind* )) clause. But even with that disambiguation, I’m so used to “looking upwards to a parent let-form for the active bindings” that establishing bindings in a sibling clause like this would take some getting used to.
[1] I regularly convince myself that it’s such low hanging fruit, there must in fact already BE a cond-let, and I go hunting for it. The obvious interface seems like such a straightforward extension of if/when-let, that there would be absolutely nothing new to learn:
(cond-let
(((var value)
(dvar (derived-from var))
((has-the-right-stuff-p dvar)))
(cons 'correct dvar))
(((foo value2)
(bar (1- foo))
((< bar 0)))
(cons 'incorrect bar))
(t nil))
next prev parent reply other threads:[~2024-01-24 4:49 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-18 3:37 Code for cond* Richard Stallman
2024-01-18 4:59 ` Emanuel Berg
2024-01-20 3:39 ` Richard Stallman
2024-01-24 12:37 ` Po Lu
2024-01-24 19:12 ` Alan Mackenzie
2024-01-27 3:35 ` Richard Stallman
2024-01-18 15:44 ` Andrea Corallo
2024-01-19 10:42 ` João Távora
2024-01-21 3:04 ` Richard Stallman
2024-01-21 20:05 ` Adam Porter
2024-01-22 5:32 ` tomas
2024-01-23 13:39 ` Richard Stallman
2024-01-24 6:02 ` Po Lu
2024-01-24 9:48 ` Stefan Kangas
2024-01-24 10:09 ` Emanuel Berg
2024-01-24 11:30 ` João Távora
2024-01-24 12:08 ` João Távora
2024-01-24 12:09 ` Po Lu
2024-01-24 12:22 ` Ihor Radchenko
2024-01-24 12:33 ` Po Lu
2024-01-24 13:34 ` Ihor Radchenko
2024-01-24 13:52 ` João Távora
2024-01-24 14:31 ` Po Lu
2024-01-27 3:35 ` Richard Stallman
2024-01-27 3:35 ` Richard Stallman
2024-01-24 14:07 ` Po Lu
2024-01-24 14:20 ` Ihor Radchenko
2024-01-24 14:34 ` Po Lu
2024-01-24 14:44 ` Ihor Radchenko
2024-01-24 14:47 ` João Távora
2024-01-24 15:28 ` Emanuel Berg
2024-01-24 16:30 ` Ihor Radchenko
2024-01-24 16:34 ` Emanuel Berg
2024-01-25 9:06 ` Po Lu
2024-01-25 9:55 ` Alfred M. Szmidt
2024-01-25 10:38 ` Eli Zaretskii
2024-01-25 11:29 ` Po Lu
2024-01-25 12:04 ` Emanuel Berg
2024-01-25 13:32 ` Po Lu
2024-01-25 14:08 ` Emanuel Berg
2024-01-25 13:19 ` Alfred M. Szmidt
2024-01-25 13:43 ` Emanuel Berg
2024-01-25 14:31 ` Eli Zaretskii
2024-01-25 15:02 ` Emanuel Berg
2024-01-25 15:29 ` Eli Zaretskii
2024-01-25 15:33 ` Alfred M. Szmidt
2024-01-25 15:50 ` Eli Zaretskii
2024-01-25 16:01 ` Alfred M. Szmidt
2024-01-25 16:13 ` Eli Zaretskii
2024-01-25 15:40 ` Emanuel Berg
2024-01-25 10:30 ` Eli Zaretskii
2024-01-25 11:27 ` Emanuel Berg
2024-01-24 12:15 ` Alan Mackenzie
2024-01-24 12:28 ` Emanuel Berg
2024-01-25 9:10 ` Po Lu
2024-01-25 11:56 ` Emanuel Berg
2024-01-25 13:21 ` Po Lu
2024-01-25 13:56 ` Emanuel Berg
2024-01-25 23:32 ` Stefan Kangas
2024-01-20 3:39 ` Richard Stallman
2024-01-23 18:10 ` Stefan Monnier via Emacs development discussions.
2024-01-24 4:49 ` JD Smith [this message]
2024-01-24 9:45 ` Stefan Kangas
2024-01-24 15:29 ` JD Smith
2024-01-24 15:55 ` Stefan Monnier
2024-01-24 16:02 ` Stefan Monnier
2024-01-24 16:20 ` JD Smith
2024-01-24 17:08 ` Stefan Monnier
2024-01-24 16:35 ` [External] : " Drew Adams
2024-01-24 16:30 ` Drew Adams
2024-02-01 8:56 ` Madhu
2024-02-01 22:46 ` Emanuel Berg
2024-01-25 3:16 ` Madhu
2024-01-25 13:57 ` Stefan Monnier
2024-01-25 15:17 ` JD Smith
2024-01-25 15:37 ` JD Smith
2024-01-25 15:44 ` Alfred M. Szmidt
2024-01-25 16:00 ` JD Smith
2024-01-25 16:05 ` Stefan Monnier
2024-01-25 16:12 ` Alfred M. Szmidt
2024-01-25 16:20 ` Stefan Monnier
2024-01-25 16:33 ` JD Smith
2024-01-29 3:19 ` Richard Stallman
2024-01-26 4:30 ` Richard Stallman
2024-01-28 3:06 ` Stefan Monnier via Emacs development discussions.
2024-01-30 3:59 ` Richard Stallman
2024-01-30 13:02 ` Stefan Monnier
2024-02-23 3:04 ` Richard Stallman
2024-01-26 4:30 ` Richard Stallman
2024-01-28 4:16 ` Stefan Monnier via Emacs development discussions.
2024-01-31 3:32 ` Richard Stallman
2024-01-31 13:20 ` Stefan Monnier
2024-02-03 3:32 ` Richard Stallman
2024-02-03 6:09 ` Stefan Monnier
2024-02-03 6:48 ` Emanuel Berg
2024-02-04 4:46 ` Richard Stallman
2024-02-04 14:04 ` Stefan Monnier
2024-02-04 4:46 ` Richard Stallman
2024-02-04 13:58 ` Stefan Monnier
2024-02-13 0:48 ` Stefan Monnier
2024-02-13 2:27 ` Stefan Monnier
2024-02-14 11:16 ` Richard Stallman
2024-02-14 12:45 ` Stefan Monnier
2024-02-22 3:05 ` Richard Stallman
2024-02-22 4:08 ` Stefan Monnier
2024-02-25 3:14 ` Richard Stallman
2024-02-25 15:03 ` Stefan Monnier
2024-02-29 3:50 ` Richard Stallman
2024-02-29 18:07 ` Stefan Monnier
2024-02-29 3:50 ` Richard Stallman
2024-02-13 0:41 ` Stefan Monnier
2024-02-23 3:04 ` Richard Stallman
2024-02-23 13:39 ` Stefan Monnier
2024-02-25 3:16 ` Richard Stallman
2024-02-25 14:57 ` Alfred M. Szmidt
2024-02-25 15:38 ` Stefan Monnier
2024-02-25 16:42 ` Alfred M. Szmidt
2024-02-25 17:13 ` Stefan Monnier
2024-02-25 17:22 ` Alan Mackenzie
2024-02-25 17:46 ` Alfred M. Szmidt
2024-02-25 18:13 ` Stefan Monnier
2024-02-25 17:10 ` Stefan Monnier
2024-02-27 3:11 ` Richard Stallman
2024-01-24 12:39 ` Alan Mackenzie
2024-01-24 14:43 ` Emanuel Berg
2024-01-24 16:25 ` Manuel Giraud via Emacs development discussions.
2024-01-25 14:01 ` Code for cond* - cond*-match, cond*-subpat and backtrack-aliases Alan Mackenzie
2024-01-29 3:19 ` Richard Stallman
2024-01-29 12:16 ` JD Smith
2024-02-01 3:51 ` Richard Stallman
2024-02-01 14:54 ` JD Smith
2024-02-04 4:42 ` Richard Stallman
2024-01-29 3:19 ` Richard Stallman
2024-01-29 8:54 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1AD5807F-91F7-4B92-BCB0-D0FEA904A75D@gmail.com \
--to=jdtsmith@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.