Kernel LISP - how low down can it go?

[Chris Bitmead uid]

>WAB> Mr Baker, I've read your papers and, as I said above, I'm bloody dense. I
>WAB> really don't understand what your immutable cons cells have as an advantage
>WAB> over, say, the spaghetti stack of way too long ago...
>
>The simplest way to look at it is that we can copy immutables indiscriminatly,
>we can also change their structure to a large degree.
>
>So if I have an immutable list (a b c d e f), then I can re-implement that
>in my garbage collector, or wherever into a vector. If they share type
>then we can even make this into a simple-vector, and save both space
>and improve speed.

Is this going to help very often? Your typical recursive lisp function
cdr's down a list, which would mean a copy of the vector every time in
order to strip off the first element.

Has anyone done any research to figure out if the savings are real or
imaginary?

BTW, we could do lots more optimisations by making lisp a fully typed
language, but of course we don't like that. Isn't this a bit of a dent
in the philosophy, of letting the user do what they like with minimal
specification, and letting the compiler just doing it's best to figure
it out the best optimisation?