I'd appreciate an explanation of the internals of coercion between lists and
vectors.
Specifically, when coercing a list to a vector are the same memory
allocations holding the actual data used? Or is an entirely new structure
created from scratch necessitating a reallocation of memory and a copy
operation of the data?
How about the other way around going from a vector to a list?
Many thanks,
Carl Taylor
In article <······················@bgtnsc04-news.ops.worldnet.att.net>,
"Carl Taylor" <··········@att.net> wrote:
> I'd appreciate an explanation of the internals of coercion between lists and
> vectors.
>
> Specifically, when coercing a list to a vector are the same memory
> allocations holding the actual data used? Or is an entirely new structure
> created from scratch necessitating a reallocation of memory and a copy
> operation of the data?
It has to be a copy, because you can modify the original after you're
done and it should have no effect on the object that was returned by
COERCE. Also, except on hardware that supports CDR-coding, the internal
representation of lists and vectors are virtually always quite different.
The only time that the result of COERCE can share structure with the
input is when it was already of the requested type, in which case it's
simply returned as is.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <······················@bgtnsc04-news.ops.worldnet.att.net>,
> "Carl Taylor" <··········@att.net> wrote:
>
> > I'd appreciate an explanation of the internals of coercion between lists and
> > vectors.
> >
> > Specifically, when coercing a list to a vector are the same memory
> > allocations holding the actual data used? Or is an entirely new structure
> > created from scratch necessitating a reallocation of memory and a copy
> > operation of the data?
>
> It has to be a copy, because you can modify the original after you're
> done and it should have no effect on the object that was returned by
> COERCE. Also, except on hardware that supports CDR-coding, the internal
> representation of lists and vectors are virtually always quite different.
>
> The only time that the result of COERCE can share structure with the
> input is when it was already of the requested type, in which case it's
> simply returned as is.
Yes, but more precisely, what's coerced is the first level of the "structure".
(defparameter y (mapcar (function copy-seq) '("at""last""we""meet""again")))
(defparameter x (coerce y 'vector))
(loop for i from 0 below (length x) do (assert (eq (elt y i) (elt x i))))
(setf (first y) "At")
(assert (string= "at" (aref x 0)))
But:
(setf (aref (second y) 0) #\L)
(assert (string= "Last" (aref x 1)))
y --> ("At" "Last" "we" "meet" "again")
x --> #("at" "Last" "we" "meet" "again")
(assert (not (eq (elt y 0) (elt x 0))))
(loop for i from 1 below (length x) do (assert (eq (elt y i) (elt x i))))
So, the memory used by the elements of the list is still the same
memory, only of course, new memory is allocated to hold the array.
(lisp coece is not C type casting!)
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> (lisp coece is not C type casting!)
This is a very important point. I still keep thinking in C when I
read about these things. Rather, I keep casting Lisp speak into C
speak. Segfault.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1