[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
All arrays can be adjustable?
From: barmar@Think.COM (Barry Margolin)
Date: 19 May 87 23:07:00 GMT
Date: Tue, 19 May 87 15:22:17 PDT
From: Richard Berman <email@example.com>
I hope there is a way to have guaranteed non-adjustable arrays!
Some systems (Maclisp, for example!) don't have non-adjustable arrays.
The way to think of these things is as hints or declarations. Telling
the system that you only plan on storing integers or that you don't plan
on adjusting the array allows it to choose an optimal array format. If
a particular implementation chooses not to perform a particular
optimization it doesn't affect the semantics.
It's definitely wrong for make-array to randomly return adjustable arrays
when the user doesn't specifically ask for them. From page 289: "If
make-array is called with the :adjustable, :fill-pointer, and :displaced-to
arguments all either unspecified or nil, then the resulting array is
guaranteed to be a simple array."
This actually sounds like a good problem for the cleanup committee to
address. As I see it, a correct implementation needs to do two things:
(1) Ensure that things like svref work correctly on things that
are supposed to be simple arrays:
(svref (make-array 3 :initial-element 'foo) 0)
(2) Ensure that user programs can distinguish arrays that are supposed to
be simple arrays from those that are not, regardless of whether or not
simple arrays use the same internal representation as non-simple arrays.
(simple-vector-p (make-array 3 :initial-element 'foo)) => true
(simple-vector-p (make-array 3 :adjustable t)) => false
I do agree that this problem is similar to whether or not the implementation
has specialized representations for arrays that can only contain a specified
element type. However, this issue has the same semantic problems as above.
Would you like to get a general vector back when you're expecting a simple
string? Especially if it doesn't even print like a string?