Hi Alex,
Having list cells behave like variables (by referring to their CAR
parts) is a very useful feature. Not only for properties, but also
for other list structures.
: (setq L (1 2 3 4 5 6 7 8 9))
- (1 2 3 4 5 6 7 8 9)
: (nth L 6)
- (6 7 8 9)
:
Hi Tomas,
Alex, why does getl return a list of (property-value . property-name)
and not a list of (property-name . property-value)?
There are some practical reasons for representing the elements of
property lists in such a way.
Most of all, a cell can be passed to functions that expect a
Hi Tomas,
Isn't it just because it was implemented this way? I mean these
functions could be implemented to behave the same way even if getl
returned a list of (property-name . property-value) which in this case
Ah, there is a misunderstanding. I was not talking especially about
'getl', but
Hi Henrik,
The main problem is that I need to be able to handle an arbitrary object and
convert all Ts to true, and NILs to false in the JSON string.
With the NILs we run into a problem, because a property value of NIL
means that this property does not exist. So it can never be extracted
from
Maybe this is a non-issue when I think about it. I can think of two
possibilities:
1) For some reason an +Entity object needs to be converted to JSON.
2) A key = value structure needs to be sent, in such a case a paired list
would do the trick, ie: ((k1 . v1) (k2 v2)) = {k1: v1, k2: v2}.
This is
Hi Henrik,
convert all Ts to true, and NILs to false in the JSON string.
With the NILs we run into a problem, because a property value of NIL
means that this property does not exist. So it can never be
extracted from the object itself.
maybe the js - picolisp mapping false - NIL is not the
Thanks for the input Thomas but I think I will just go with paired lists
instead, they are easier to manipulate with various list functions and
should therefore be preferable to basic objects anyway. +Entity objects are
on the list though.
This is oversimplified version as there are lots of
