From: Stefan Monnier via "Emacs development discussions." <emacs-devel@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: Code for cond*
Date: Tue, 23 Jan 2024 13:10:01 -0500 [thread overview]
Message-ID: <jwvv87kvtey.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: E1rQJDv-0001UG-2E@fencepost.gnu.org
> Here is the first draft of cond*. I have tested some cases
> but I ask others to help in testing it more thoroughly.
AFAICT the main reason to oppose the use of `pcase` is that it increases
the size of the language, making it harder for non-experts to
read/understand/modify ELisp code.
`cond*` suffers from the same criticism. And having both even more so
(and whether you like it or not, `pcase` is probably not going to
disappear any time soon, among other things because it offers a style
familiar from other languages and that style is gaining popularity).
So, I'm not super enthusiastic about adding such a new form, but being
responsible for the introduction of several such new constructs in ELisp
over the years, I do feel a bit like the pot calling the kettle black.
So, rather than oppose it, I'll just point out some things which I think
could be improved (or which offend my taste, as the case may be).
> (cond*
> ;; Same as a clause in `cond',
> (CONDITION
> DO-THIS-IF-TRUE-THEN-EXIT...)
So far so good.
> ;; Execute FORM, and ignore its value
> ;; (except if this is the last clause).
> (FORM)
YAGNI.
> ;; 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?
- Why the double parens?
- Why `*`? If you need such sequential bindings, you can get it with
(cond
[...]
((bind* (x E1)))
((bind* (y (foo x))))
So here a plain old "parallel let" would be more useful (or restrict
that binding to a single var, so the question doesn't even pop up).
> ;; Bind variables for the clause, as in let*.
> ((bind* (foo 5) (condition (hack-it foo)))
> ;; condition is that the last variable bound be non-nil.
> BODY...)
This is the other 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?
- I'm not happy about using the same construct for "bindings
for this clause" and "bindings for subsequent clauses".
Maybe it should be inspired by `when-let*`?
> ;; Extracts substructure and binds variables for the clause.
> ((match* `(expt ,foo ,bar) x)
> DO-THIS-IF-IT-MATCHED-THEN-EXIT...)
> ;; Bindings no longer in effect.
This `(expt ,foo ,bar) is a valid Pcase pattern, so it would be odd if
other Pcase patterns can't be used here.
For that same reason, it's odd for its name not to include "pcase".
> ((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.
Finally, I see a fairly extensive but hardcoded pattern language, which
seems like a regression compared to Pcase where the pattern language is
built from a few primitives only (with the rest defined on top via
`pcase-defmacro`). The worst part, tho, is that the two pattern
languages are very similar, and I can't see any good reason for
the differences. It feels like an NIH reaction.
Stefan
next prev parent reply other threads:[~2024-01-23 18:10 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. [this message]
2024-01-24 4:49 ` JD Smith
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvv87kvtey.fsf-monnier+emacs@gnu.org \
--to=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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).