[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [External] : Re: cond*
From: |
Richard Stallman |
Subject: |
Re: [External] : Re: cond* |
Date: |
Sun, 07 Jan 2024 22:45:50 -0500 |
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Perhaps off-topic, but I think the difficulty
> of human-parsing pcase sexps can be reduced
> considerably if each variable bound by the
> sexp is clearly shown to be just that.
After reading the example, I see the point you're making.
I suppose the same issue could apply to cond*.
Do you think it applies equally to both?
The only pertinent difference is that cond*
would use match* or bind* around constructs that can make bindings.
> Even just following a trivial convention,
> such as prefixing each variable name with,
> `?', would help.
Supposing that cond* could benefit from this idea, how can we make
this idea fit the framework of Emacs Lisp? `?' has a different
meaning. Of course, it does not _have_ to take the form of `?', but
what could it be?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
- Re: cond*, Ihor Radchenko, 2024/01/01
- Re: cond*, Richard Stallman, 2024/01/02
- Re: cond*, Ihor Radchenko, 2024/01/03
- Re: cond*, Richard Stallman, 2024/01/04
- Re: cond*, Ihor Radchenko, 2024/01/06
- RE: [External] : Re: cond*, Drew Adams, 2024/01/06
- Re: [External] : Re: cond*,
Richard Stallman <=
- RE: [External] : Re: cond*, Drew Adams, 2024/01/08
- map seq and radix-tree-leaf, in pcase, Richard Stallman, 2024/01/08
- Re: cond*, Richard Stallman, 2024/01/07
- Re: cond*, Ihor Radchenko, 2024/01/10
- Re: cond*, Richard Stallman, 2024/01/12
- Re: cond*, Adam Porter, 2024/01/13
- Re: cond*, Richard Stallman, 2024/01/15
- Re: cond*, Ihor Radchenko, 2024/01/13
- Re: cond*, Richard Stallman, 2024/01/14
- Re: cond*, Richard Stallman, 2024/01/07