Property lists in newlisp?

[g1i1ch]

I remmember that in common Lisp I could do something like this:

(list :a 1 :b 2 :c 3)



Is there any way to make this kind of list in newlisp. I saw hashes but I'd like to make something like this within another list and it seems hashes need their own namespace.

[cormullion]

Hi there. If I remember correctly, Common Lisp has both p-lists and a-lists, where p-lists alternate keys and values, whereas a-lists group keys and values in sublists. newLISP supports a-lists but not p-lists. Since there are built-in functions for working with a-lists, these are probably the way to go. You could write something to mimic p-lists, but it would have to be worth doing for speed or memory use, I expect.



There's an introduction to association lists at http://en.wikibooks.org/wiki/Introduction_to_newLISP/Lists#Association_lists">//http://en.wikibooks.org/wiki/Introduction_to_newLISP/Lists#Association_lists.

[newdep]

What do i catch here a wikibooks entry on newlisp? Never seen thatone befor? Thanks for the highlight ;-)

[g1i1ch]

Yeah I saw that, I like to use symbols as my keys and doing that with the association lists plus contexts causes weird behaviors. Say if I have a global database associative list and want to access it within (context thing) all my symbols are automatically changed. When I do (lookup 'stuff MAIN:db) 'stuff is changed to thing:stuff and of course the db is a MAIN context variable so thing:stuff returns nothing.



Kinda annoying when I want to access the database from multiple contexts and have to manually change every lookup to have MAIN: at the front. We should change lookup and assoc to append the symbols with the context of the list it's looking up, not the current context because then it's just extremely painful to use between contexts.



[edit] wrong word

[cormullion]

I've encountered similar problems - sometimes I used to switch to using string keys that dont need qualifying. I think I've asked questions about this issue on the forum too. I was never sure if it wasnt my coding style that was the real problem... :)

[Lutz]

The home context of symbols is not changed during runtime. The context of a variable gets set during program loading for example in the following piece of code:

Code Select Expand


(set (global 'alist) '((a 1) (b 2) (c 3)))

(context 'Foo)

(set 'blist '((a 1) (b 2) (c 3)))

(define (report)
    (println (assoc 'a blist))
    (println (assoc 'a alist)) ; alist is global, does not need MAIN prefix
    (println (assoc 'MAIN:a alist))
)

(context MAIN)

(println)
(Foo:report)
(println (assoc 'a alist))
(println (assoc 'a Foo:blist))
(println (assoc 'Foo:a Foo:blist))

(exit)



produces correctly:

Code Select Expand


(a 1)
nil
(MAIN:a 1)

(a 1)
nil
(Foo:a 1)


The 'a always refers to the context it was found in when loading/translating the code and will never change afterwards.



But I agree, that in many cases it is easier to use strings in association lists. Or use hashes:

Code Select Expand


(define ahash:ahash) ; create default functor containing nil

(ahash "a" 1)
(ahash "b" 2)
(ahash "c" 3)

(context 'Foo)

(define (report)
    (println (ahash "a"))
    (println (ahash "b"))
    (println (ahash "c"))
)

(context MAIN)

(Foo:report)
(println (ahash))

; add from association list
(ahash '(("x" 10) ("y" 20) ("z" 30)))
(println (ahash))

(exit)


which produces:

Code Select Expand


1
2
3
(("a" 1) ("b" 2) ("c" 3))
(("a" 1) ("b" 2) ("c" 3) ("x" 10) ("y" 20) ("z" 30))


and you can easily go back and forth between association lists and hashes as shown in the last two statements.