I mention it because pg makes a fairly good point about using alists.
"There is a tradition in Lisp going back to McCarthy's 1960 paper [2]
of using lists to represent key/value pairs:
arc> (= codes '(("Boston" bos) ("Paris" cdg) ("San Francisco" sfo)))
(("Boston" bos) ("Paris" cdg) ("San Francisco" sfo))
This is called an association list, or alist for short. I once
thought alists were just a hack, but there are many things you can
do with them that you can't do with hash tables, including sort
them, build them up incrementally in recursive functions, have
several that share the same tail, and preserve old values"
Of course none of this negates anything in akkartik's response. I just think there are some helpful tips in the tutorial.
Lists are easy to split and merge, insert and delete nodes from, but searching them is slow. Tables are fast for searching and insertion and deletion, but they don't naturally encode ordering relationships.
Check out this chapter: http://www.gigamonkeys.com/book/they-called-it-lisp-for-a-re... Tables are often great for things Lisp historically used lists for. But the one thing they can't do is represent code and trees in general. That's where cons cells come in.
>But the one thing they can't do is represent code and trees in general. That's where cons cells come in.
They can if you can nest them, or include references to other keys (like foreign keys in SQL or something) It's inefficient but it's possible. You can even represent trees in a flat array if you work hard enough.
Although maybe I should be pedantic and clarify that you can represent trees with tables but not in tables natively, of course.