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]