[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Instead of pcase
From: |
Richard Stallman |
Subject: |
Re: Instead of pcase |
Date: |
Tue, 02 Jan 2024 23:13:56 -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. ]]]
> Let me try to illustrate the problem with another example:
> ;; ALIST-VAL = '((:key1 . 1) (:key4 . 2))
> ;; Match alist key where the key is one of a know set of keys.
> (match* (memq (alist-get key alist-val) '(:key1 :key2 :key3)) :key1)
> >From the description of "constrained variable" construct, the above will
> (1) test if ALIST-VAL contains a record with KEY=:key1 key; (2) test if
> KEY=:key1 is one of :key1 :key2 :key3.
What a strange example. This is connterintuitive and I could not see
at first what it would mean. But I worked it out by following the
rules.
(match* PATTERN :key1) matches PATTERN against the data object :key1.
(memq (alist-get key alist-val) '(:key1 :key2 :key3))
as a pattern means to match (alist-get key alist-val) aainst it,
and if that matches, then call memq to determine whether this matches,
It would be matched against :key1.
Matching (alist-get key alist-val) against :key1 would succeed,
so `key' would be bound to `key1'.
So the memq call would return t. And the pattern would match,
binding `key' to :key1.
It isn't "wrong", but I can't see the point using that strange
pattern. What purpose did you have in mind in writing it?
Is there a simpler way to do that?
--
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: Instead of pcase, Ihor Radchenko, 2024/01/01
- Re: Instead of pcase, Richard Stallman, 2024/01/02
- Re: Instead of pcase,
Richard Stallman <=
- Re: Instead of pcase, Ihor Radchenko, 2024/01/03
- Re: Instead of pcase, Richard Stallman, 2024/01/04
- Re: Instead of pcase, Ihor Radchenko, 2024/01/06
- Re: Instead of pcase, Richard Stallman, 2024/01/07
- Re: Instead of pcase, Ihor Radchenko, 2024/01/08
- Re: Instead of pcase, Richard Stallman, 2024/01/26