Arc Forumnew | comments | leaders | submitlogin
4 points by akkartik 1976 days ago | link | parent

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.



3 points by krapp 1976 days ago | link

>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.

-----

2 points by akkartik 1975 days ago | link

You got me, I was careful to use the word 'natural' in the first paragraph but I forgot to do so in the second ^_^

-----

2 points by kinnard 1919 days ago | link

I realized belatedly that ordering matters for my application. . .

Even looked at Assocative Containers[1] before I thought, "alist!"

[1] https://en.wikipedia.org/wiki/Associative_containers

-----