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 about how properties are implemented in general. It is
important, IMHO, that they are of the form (value . key) internally.
'getl' simply returns the property list as it is.
Surely it would have been possible to have 'getl' return a list of (key
. value) pairs, but this would have involved an additional level of
'cons'ing, creating unnecessary garbage.
> :(put 'A 'counter 0)
> -> 0
> : (put 'A 'list (1 2 3 4))
> -> (1 2 3 4)
> : (getl 'A)
> -> (((1 2 3 4) . list) (0 . counter)) # currently
> -> ((list . (1 2 3 4)) (counter . 0)) # I would expect this?
>
> Or, how is the order inside pairs for getl/putl important to these
> functions?
If you use those functions directly on the result of 'getl', yes. But
this was not the intention, and I think I never did it.
The interesting point is to apply these functions directly to the cells
of a property list as returned by 'prop' or '::', as described
previously as (inc (:: counter)) or (pop (:: list)).
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)
: (inc (nth L 6) 100)
-> 106
: (set (nth L 9) 777)
-> 777
: L
-> (1 2 3 4 5 106 7 8 777)
> I see, you think it is more useful to search for a given value and I
> thought it was more useful to search for a given property (even though
This is available anyway, with 'get', ':' etc.
> How and what for would you use assoc in your example?
In fact, I never needed that ;-)
But for the matter of an example:
: (mapc '((Key Val) (put 'A Key Val)) '(a b c d e f g) (1 2 3 4 5 6 7))
-> 7
: (show 'A)
A NIL
g 7
f 6
e 5
d 4
c 3
b 2
a 1
-> A
: (get 'A 'd)
-> 4
: (assoc 4 (getl 'A))
-> (4 . d)
> Sometimes a list of (key . value) is needed (e.g. a list of attributes
> for xml function) and in those cases, if I use getl in my code, I need
> to "swap" car and cdr values which is rather inconvenient.
I think 'getl' is not as important or useful as you seem to assume. It
always returns the _whole_ property list, and this may contain other
irrelevant data (as, for example, also Pilog stores rules in symbol
properties, and the debug environment file names and line numbers).
'getl' was primarily intended as the counterpart to 'putl', allowing a
fast cloning of symbols, or aid in debugging.
For application-relevant data it is much more common to use explicit
association lists. Assoc-lists were also the motivation to use the above
structure for xml attributes. They are more flexible than property
lists, because you can control aspects like the order of their elements,
or how you search them (with 'assoc', 'asoq', 'find' etc). Property
lists change their order on a last-recently used schema.
> I was thinking about XML data binding, representing XML using symbols
> instead of lists and that was where getl surprized me. It is not an
> issue though, just unexpected surprice;-)
I would say it is best to use symbols when you have well defined,
independent properties, and association lists when you need a whole list
for a given operation.
> # convert xml "list" (as returned by xml function) to xml "symbol"
> ...
> # convert xml "symbol" to xml "list" (as consumed by xml function)
> ...
As I said, this might give surprising results if you by chance encounter
symbols used somewhere else in the system. Try (getl 'select)!
> The advantage of this approach is that I can use all those property
> access functions instead of searching for elements & attributes in a
Searching with 'assoc' or 'asoq' is about as convenient as using 'put'
and 'get'. In addition, you can use the full set of list manipulation
functions on association lists, while with property lists you are
limited to the 'get' and 'put' function family, or need the overhead of
'getl' and 'putl'. This overhead is relatively large, as the whole
property list needs to be copied.
> list. Also, other useful stuff could be added to a symbol
> representing an XML element, e.g. indices for accessing items of a
> list hold by a property in a specific order.
Here, too, I believe that (nested) lists structures are more powerful.
But it all depends, of course. It is always worth experimenting around a
little.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
