>>46
JS + JIT is not going to be faster than SBCL + type hints. (I think JIT and type hints are equivalent "advantages" here) And the guys writing Lisp compilers have it figured out, thank you very much.
But to convince your C++ poisoned mind that it's not as simple as "LOL linked lists R stoopid freshman crap not actually useful" :
let's say you implement Lisp lists as backward vectors, where the
car is the last element, and the
cdr is an identical array with size set to - 1 of the parent size, and cons just pushes, occasionally growing the vector by reallocating the whole thing at a new memory position. (you make it backward because idiomatic Lisp builds lisps by pushing to the front, but vectors are better at pushing to the back)
There's already a nasty performance problem here: you have to reallocate the whole array every time you cons onto something that's already the cdr of something else. For instance:
(define ngland '(n g l a n d))
(define england (cons 'e ngland))
(define angland (cons 'a ngland)) ;have to reallocate ngland because it's already got an e at the end of the array.
This isn't just some dumb example: in functional code, you pretty constantly re-use parts of data structures to build new ones, and you need to know that it's not having side effects. So the vector solution doesn't really reduce allocations, because allocations are necessary for the style. Instead, it just delays them and makes them bigger (as well as less obvious.)
Another thing this approach ruins is pointer-equality of cells. Most lisps require that lists be comparable by pointer to see if they are identical lists. If they can get reallocated, this gets complicated.
And unless you implement your arrays as not really arrays at all, like Clojure does, they kind of fall on their face at functional-style code performance-wise (as I showed above.) You need to be able to recombinate (take apart and put back together in crazy ways) them while minimizing memory allocation. That's tough with arrays. Linked lists are built for it.
Another performance issue is that cells all being the same size (typically just two pointers) is a convenient invariant to optimize around. For example, it becomes easy to write a memory manager that doesn't deallocate and rather just pushes things on a "free list." Doing so with arrays is... clumsy.
In conclusion, you have stateful brain damage.
[code]