Consider this simple example:
(deftype image nil '(simple-array single-float (100)))
Here we are defining a shorthand for a type that is an array that is holding single floats. Let us try creating one like that:
(defparameter tmp
(make-array 100
:element-type 'single-float
:initial-element 0.0))
Let's check the type just in case:
CL-USER> (type-of tmp)
(SIMPLE-ARRAY SINGLE-FLOAT (100))
All good. Let us see if we could have those little arrays in another array, to make the retrieval easier, instead of putting everything into a single dimensional array and ending up having a headache calculating the access indexes.
(defparameter image-array
(make-array 10
:element-type 'image
:initial-element tmp))
There is no way it is going to fail but checking just in case:
CL-USER> (type-of image-array)
(SIMPLE-VECTOR 10)
Oops, that is not what we want at all. Seems like this new array defaulted to the default element type:
CL-USER> (array-element-type image-array)
T
That likely means that the application will now have to type check not just the container array elements, but also the elements of child arrays with all the consequences for the performance. The questions that arises is this:
Is storing typed arrays as array elements in another array possible in SBCL?
EDIT: That might be a bit too early to panic though as this returns the right type:
CL-USER> (type-of (aref image-array 0))
(SIMPLE-ARRAY SINGLE-FLOAT (100))
In that case, why do we get T as the element type from (array-element-type image-array)?