Assigning key/value pair in disembodied property list

Switched to makeTable and that works!

Generally speaking DPLs are not so good for dynamic data, but even then it's not hard. You can't use the arrow syntax because it will assume that the property is called the literal symbol name on the right hand side of the arrow - it can't be a variable.

Rather than using pList->"str"=nth(0 List2) you can use putprop(pList car(List2) str)

Or you could use a table like you suggested.

Regards,

Andrew.

The funny thing is the quote itself surrounding key name will be stripped off with no matter putprop or ->. So in the following corner case, how can we retrieve the value from the only pair?

> dpl1 = '("a" "b" "c")

  ("a" "b" "c")

> dpl1->?

("b")

How can we get the value of key "b"?

Thanks

Fred

I don't mean the way -- cdr(dpl1->??). Because it only works in one pair. If there are many pairs like dpl1 = '("a" "b" "c" "d" "e" "f"), how can we do?

Hi Nora,

That list '("a" "b" "c") is not really a disembodied property list. A disembodied property list is a plain SKILL list with the first element potentially being anything (often nil) followed by alternating key/value pairs. And the keys (or slots or whatever you wanna call them...) need to be symbols which is not the case in your example. The underlying function of the arrow operator (->) is getq(..), so dpl->name is under the hood just
(getq dpl name)
However as I said that requires the keys to be symbols! Or is there any good reason why you would want the slot names to be strings?

Max

The tricky thing here is there is no fixed constructor for dpl. That means we can flexibly compose dpl. If dpl1=‘(“a” “b” “c”) is not an eligible dpl, then there should be warning in output of dpl1->?. I know ‘(a b c) should be ok to use all the indirect access methods for genuine dpl....

It would be prohibitively expensive to continuously check the list that it consists of symbol-value pairs only. Also, because a DPL is just a list that is interpreted specially, there's nothing to stop you hiding other information in the list which will be ignored by the DPL operator ->, so producing a warning would break existing code. Since using dpl1->key returns nil if key doesn't exist, that's the case here and so everything is as expected...

Regards,

Andrew.

Then from this perspective, it is understandable and applicable. Be little bit pedantic and off-topic, SKILL language itself always give me prosmiscuous feeling. I just guess, maybe it firstly originated from LISP and late absorbed some traits from other languages. In fact key-value pair is a strong binding in data structure. But in DPL, this binding is easily be challenged by normal list element operation like nth etc. That makes makeTable more appealing. Except DPL, a symbol also has property list which can be accessed by dot(.) operator but it seems this data structure is not heavily used in the practice.

Thanks.

Fred

Disembodied property lists are a long-standing simple way of representing structured data in lists, one of the primitive datatypes in SKILL. They are not intended for general purpose key-value pairs - the only keys that are supported are symbols. If you need a data structure that can handle other object types as keys, then you can use hash tables (which have been in SKILL for over 25 years, so are not exactly new). DPLs are not really so good for arbitrary keys - they're mostly for objects with a small number of keys.

Property lists on symbols are used for some operations, but because they are tied to the symbol containing them, they are mostly used for settings where you don't have a variable number of objects. I use them from time to time to represent persistent state (although a better way is to use SKILL++ lexical scoping and the closures that offers).

Note you can also use the -> operator with symbols and hash tables. So doing:

data=makeTable('data nil)
data->value=10
data->suit="clubs"
data->??

Or:

data2='mySymbol
data2->value=10
data2->suit="hearts"
data2->??
mySymbol.suit
mySymbol.??

Regards,

Andrew.

Andrew,

Now I totally get you. Each type of data structure has its own nuance.

Be more off-topic, differentiated with hash table, what is the best scenario for defstruct?

Thank you so much!

Fred