[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Code for cond*
|
From: |
Alfred M. Szmidt |
|
Subject: |
Re: Code for cond* |
|
Date: |
Thu, 25 Jan 2024 11:12:52 -0500 |
> (cond-let
> (:let var-for-rest value)
>
> Is there a reason why using a keyword here?
It was to "ensure" compatibility with existing `cond` code.
I really hope we are not going to modify cond -- which has been
literally the same since it created many decades ago. It would be
confusing to all Lisp programmers, even if it was backward compatible.
Also it was based on the premise that most `cond`s would *not* use it
since such code is mostly needed to replace things like:
(let (val)
(cond
[...]
((foo (setq var (bar)))
[...])
[...]))
And while such code does occur, it occurs only in a minority of `cond`
uses, so I thought it would be worthwhile for it to "stand out" so as
not to catch the reader by surprise.
Are such cases really worth solving by extending cond, and not better
addressed in a different macro (cond*, pcase, ...) -- or even just
sticking to the status quo?
The above "idiom" is much easier to understand since it just uses well
known Lisp behaviour than modifying cond even if it is really ugly
... the feature is a nice addition, but is it worth it?
- Re: Code for cond*, (continued)
- Re: Code for cond*, Stefan Monnier, 2024/01/24
- RE: [External] : Re: Code for cond*, Drew Adams, 2024/01/24
- RE: [External] : Re: Code for cond*, Drew Adams, 2024/01/24
- Re: Code for cond*, Madhu, 2024/01/25
- Re: Code for cond*, Stefan Monnier, 2024/01/25
- Re: Code for cond*, JD Smith, 2024/01/25
- Re: Code for cond*, JD Smith, 2024/01/25
- Re: Code for cond*, Alfred M. Szmidt, 2024/01/25
- Re: Code for cond*, JD Smith, 2024/01/25
- Re: Code for cond*, Stefan Monnier, 2024/01/25
- Re: Code for cond*,
Alfred M. Szmidt <=
- Re: Code for cond*, Stefan Monnier, 2024/01/25
- Re: Code for cond*, JD Smith, 2024/01/25
- Re: Code for cond*, Richard Stallman, 2024/01/28
Re: Code for cond*, Richard Stallman, 2024/01/25
Re: Code for cond*, Richard Stallman, 2024/01/25