help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to get plist properties list?


From: Stefan Monnier
Subject: Re: How to get plist properties list?
Date: Fri, 08 Jan 2021 01:50:26 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> I would like to understand what is the problem. I don't. You tell me
> that `elt' is problem, that is how I understand it.
>
> Could I maybe rather use `nth' to replace `elt'?

No, same problem.
Think of it this way: consider your list of N elements as a road that's
N kilometers long.  `elt` and `nth` are operations which involve walking
from the beginning of the road to the Nth kilometer.  So to collect all
the keys found at kilometers 0, 2, 4, ... your loop does:
- walk 0 kilometers and collect the key (then come back).
- walk 2 kilometers from the start and collect the key (then come back).
- walk 4 kilometers from the start and collect the key (then come back).
- walk 6 kilometers from the start and collect the key (then come back).
...
[ the "come back" happens to be feasible as a kind of teleportation:
  obviously my analogy breaks down there.  ]
So to collect all the keys on a road of 100km you'll end up walking
a total of about ... 5000km.  I hope you can see that it's far from
being the most efficient use of your feet.

>> > But maybe there is some more simpler way to get plist properties list?
>> 
>> Probably not the simplest but this should work:
>> 
>>     (defun plist-keys (plist)
>>       (let (keys iskey)
>>         (dolist (x plist)
>>           (if (setq iskey (not iskey)) (push x keys)))
>>         (nreverse keys)))
>
> As we already discussed it, `dolist' is not perfect, it would give
> warnings, not logical at all.

There's no warning for this code, AFAIK, no.

> In the above example `x' would not give warning, but if there would be
> return value then `x'  would be part of warning, while return variable
> would not be. That is not logical to me, so I consider `dolist' not
> well handled by compiler and is better for me not to use it.

Just never use that 3rd argument and you'll never get that warning.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]