[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cl-loop and plists vs alists
From: |
Philip Kaludercic |
Subject: |
cl-loop and plists vs alists |
Date: |
Mon, 26 Dec 2022 00:11:53 +0000 |
(I have removed the remaining CC's because this has nothing to do with
the previous discussion, but I'd like to hear if anyone knows more on
the topic.)
João Távora <joaotavora@gmail.com> writes:
> On Sat, Dec 24, 2022, 10:33 Philip Kaludercic <philipk@posteo.net> wrote:
>
>> .
>>
>> I would guess a custom function, say `plist-map' along the lines of
>> `maphash'. I am kind of surprised to see that this doesn't exist, but
>> according to my intuition of property lists, they are not meant to be
>> iterated.
>>
>
> Until you step into the real world and you have to.
Can you elaborate this point? Is this by intrinsic necessity or due to
the "mistakes" of others. Plists are "harder" to iterate, because your
steps are cddrs which is an unusual way to run over a data structure.
Same applies to adding and removing associations from a plist. The
advantage is that they are easier to write.
Maybe somebody knows the history here, why and where which of the two
were used. Again, my hunch is that going by the respective strengths
and weaknesses of the two (in relation to the conventional tools), we
can give some heuristic of when it is /better/ to use which of the two.
>> While writing this, I also just realise this exists in the "map"
>> package.
>>
>> (map-do (lambda (key val)
>> (message "Key %s, Value %s" key val))
>> '(:one 1 :two 2 :three 3))
>>
>
> Right, a custom function, a loser in versatility (even if this one is
> polymorphic, that strength is wasted here) Take your example: print only
> three pairs max and a "and more" if there are more than there.
I get your point, but this example is geared towards cl-loop. It is
powerful as long as you are doing the "right" things. But when you
decide to change the problem and say "print only the three pairs with
maximal values and a "and more" if there are more than there." then I
believe that the language that cl-loop provides isn't elegant anymore.
- Re: cl-lib warnings, (continued)
- Re: cl-lib warnings, Stefan Monnier, 2022/12/22
- Re: cl-lib warnings, Eli Zaretskii, 2022/12/23
- Re: cl-lib warnings, Yuan Fu, 2022/12/23
- Re: cl-lib warnings, Juanma Barranquero, 2022/12/23
- Re: cl-lib warnings, Stefan Monnier, 2022/12/24
- Re: cl-lib warnings, Juanma Barranquero, 2022/12/24
- Re: cl-lib warnings, Tomas Hlavaty, 2022/12/24
- Re: cl-lib warnings, João Távora, 2022/12/23
- Re: cl-lib warnings, Philip Kaludercic, 2022/12/24
- Re: cl-lib warnings, João Távora, 2022/12/24
- cl-loop and plists vs alists,
Philip Kaludercic <=
- Re: cl-loop and plists vs alists, João Távora, 2022/12/25
- Re: cl-loop and plists vs alists, Bob Rogers, 2022/12/26
- Re: cl-lib warnings, Sean Whitton, 2022/12/24
- Re: cl-lib warnings, Stefan Monnier, 2022/12/24
- package-initialize was Re: cl-lib warnings, T.V Raman, 2022/12/24
- Re: package-initialize was Re: cl-lib warnings, T.V Raman, 2022/12/24
- Re: package-initialize was Re: cl-lib warnings, Stefan Monnier, 2022/12/25
- Re: package-initialize was Re: cl-lib warnings, T.V Raman, 2022/12/25
- Re: cl-lib warnings, tomas, 2022/12/25
- Re: cl-lib warnings, João Távora, 2022/12/25