[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Code for cond*
From: |
Richard Stallman |
Subject: |
Re: Code for cond* |
Date: |
Fri, 26 Jan 2024 22:35:55 -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. ]]]
> that the new cond* fall-through bindings don't lexically wrap
> their users.
I understand cond* in a different way which leads to the opposte conclusion.
match* is not a separate construct in its own right. It is part of
the syntax of using cond*, and it can only be used there.
These bindings belong to cond*. Their scope is a part of the cond*
expression, which does wrap their uses.
Would this be clearer if we replace `match*' with `:match'? I
wouldn't mind minor changes like that. I'm concerned about its
powerful features and its simplicity.
Another possible syntax change: non-exit clauses could also be mored
to top level, as in the first two lines in this example.
(cond* :match (PATTERN DATUM)
:bind (BINDINGS...)
;; The rest are exiting clauses.
(:match (PATTERN DATUM) CLAUSE-BODY...)
(COND-EXP CLAUSE-BODY...)
(:bind (BINDINGS...) COND-EXP CLAUSE-BODY...))
I prefer the syntax I've already proposed, because it expresses
syntactix relationships using parens. But I'll agree to changes like
these if others have a clear preference for them.
--
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: Code for cond*, (continued)
- Re: Code for cond*, Po Lu, 2024/01/24
- Re: Code for cond*, Ihor Radchenko, 2024/01/24
- Re: Code for cond*, Po Lu, 2024/01/24
- Re: Code for cond*, Ihor Radchenko, 2024/01/24
- Re: Code for cond*, João Távora, 2024/01/24
- Re: Code for cond*, Po Lu, 2024/01/24
- Re: Code for cond*,
Richard Stallman <=
- Re: Code for cond*, Richard Stallman, 2024/01/26
- Re: Code for cond*, Po Lu, 2024/01/24
- Re: Code for cond*, Ihor Radchenko, 2024/01/24
- Re: Code for cond*, Po Lu, 2024/01/24
- Re: Code for cond*, Ihor Radchenko, 2024/01/24
- Re: Code for cond*, João Távora, 2024/01/24
- Re: Code for cond*, Emanuel Berg, 2024/01/24
- Re: Code for cond*, Ihor Radchenko, 2024/01/24
- Re: Code for cond*, Emanuel Berg, 2024/01/24
- Re: Code for cond*, Po Lu, 2024/01/25