I'm running into the issue described in the examples for the function
typep in section 4.4 of the CLHS related to array element types:
Let Ax and Ay be two type specifiers that denote different types, but
for which
(upgraded-array-element-type 'Ax)
and
(upgraded-array-element-type 'Ay)
denote the same type. Notice that
(typep (make-array 0 :element-type 'Ax) '(array Ax)) => true
(typep (make-array 0 :element-type 'Ay) '(array Ay)) => true
(typep (make-array 0 :element-type 'Ax) '(array Ay)) => true
(typep (make-array 0 :element-type 'Ay) '(array Ax)) => true
End of example from CLHS
So, this is what confuses me. Why do I have to get to specific float
types before typep returns nil? Or for that matter, to fixnum? Notice
that the problem is not just for characters, but also for symbols.It
appears to be a distinction between system classes and types. But I
don't appreciate the distinction.
CL-USER> (typep #(#\a #\b #\c #\d) '(vector number))
T
CL-USER> (typep #(#\a #\b #\c #\d) '(vector real ))
T
CL-USER> (typep #(#\a #\b #\c #\d) '(vector rational))
T
CL-USER> (typep #(#\a #\b #\c #\d) '(vector integer ))
T
CL-USER> (typep #(#\a #\b #\c #\d) '(vector fixnum))
NIL
CL-USER> (typep #(#\a #\b #\c #\d) '(vector float ))
T
CL-USER> (typep #(#\a #\b #\c #\d) '(vector single-float))
NIL
CL-USER> (typep #('a 'b 'c 'd) '(vector number))
T
CL-USER> (typep #('a 'b 'c 'd) '(vector real))
T
CL-USER> (typep #('a 'b 'c 'd) '(vector float))
T
CL-USER> (typep #('a 'b 'c 'd) '(vector single-float))
NIL
Thanks,
Tom
On Mar 23, 2:05 am, "Thomas M. Hermann" <········@centurytel.net>
wrote:
> I'm running into the issue described in the examples for the function
> typep in section 4.4 of the CLHS related to array element types:
>
> Let Ax and Ay be two type specifiers that denote different types, but
> for which
>
> (upgraded-array-element-type 'Ax)
>
> and
>
> (upgraded-array-element-type 'Ay)
>
> denote the same type. Notice that
>
[...]
>
> So, this is what confuses me. Why do I have to get to specific float
> types before typep returns nil? Or for that matter, to fixnum? Notice
> that the problem is not just for characters, but also for symbols.It
> appears to be a distinction between system classes and types. But I
> don't appreciate the distinction.
>
> CL-USER> (typep #(#\a #\b #\c #\d) '(vector number))
VECTOR and Sharpsign Left-Parenthesis return simple-vectors, that is
(simple-array t 1). Moreover if the implementation does not have
specialised vectors types for number, rational, float, etc., a (vector
number), (vector rational) etc. is just a (vector t). As usual in CL,
type declarations aren't about safety as much as speed. There is
little point is having vector types specialised for arbitrary pointers
(which must be used for arbitrary numbers, including bignums). It
could make sense for float, but the rest of the code would be bogged
down in type dispatch anyway. As to what specialised vector types are
available, that is completely implementation dependent, and probably
described in your favourite implementation's manual.
Paul Khuong
Paul Khuong wrote:
> On Mar 23, 2:05 am, "Thomas M. Hermann" <········@centurytel.net>
> wrote:
>> I'm running into the issue described in the examples for the function
>> typep in section 4.4 of the CLHS related to array element types:
>>
>> Let Ax and Ay be two type specifiers that denote different types, but
>> for which
>>
>> (upgraded-array-element-type 'Ax)
>>
>> and
>>
>> (upgraded-array-element-type 'Ay)
>>
>> denote the same type. Notice that
>>
> [...]
>> So, this is what confuses me. Why do I have to get to specific float
>> types before typep returns nil? Or for that matter, to fixnum? Notice
>> that the problem is not just for characters, but also for symbols.It
>> appears to be a distinction between system classes and types. But I
>> don't appreciate the distinction.
>>
>> CL-USER> (typep #(#\a #\b #\c #\d) '(vector number))
>
> VECTOR and Sharpsign Left-Parenthesis return simple-vectors, that is
> (simple-array t 1). Moreover if the implementation does not have
> specialised vectors types for number, rational, float, etc., a (vector
> number), (vector rational) etc. is just a (vector t). As usual in CL,
> type declarations aren't about safety as much as speed. There is
> little point is having vector types specialised for arbitrary pointers
> (which must be used for arbitrary numbers, including bignums). It
> could make sense for float, but the rest of the code would be bogged
> down in type dispatch anyway. As to what specialised vector types are
> available, that is completely implementation dependent, and probably
> described in your favourite implementation's manual.
>
> Paul Khuong
That's what I suspected. I'm running into this problem with the
check-type macro, but need to understand it for declarations as well.
Mainly, I'm interested in notifying the personal calling my function
that they've provided a vector with a incompatible type, only numbers
are compatible. I want the backtrace to list my function at the top to
hopefully reduce confusion. Currently, the incompatible type of the
vector generates an error in my function when it is used in some number
operation, listing my function second or higher in the backtrace. This
is probably sufficient.
Thanks for the response.
Tom
In article <································@centurytel.net>,
"Thomas M. Hermann" <········@centurytel.net> wrote:
> That's what I suspected. I'm running into this problem with the
> check-type macro, but need to understand it for declarations as well.
> Mainly, I'm interested in notifying the personal calling my function
> that they've provided a vector with a incompatible type, only numbers
> are compatible. I want the backtrace to list my function at the top to
> hopefully reduce confusion. Currently, the incompatible type of the
> vector generates an error in my function when it is used in some number
> operation, listing my function second or higher in the backtrace. This
> is probably sufficient.
It will have to do. Array element types are about the implementation of
the array -- whether it is implemented using an optimized format that
can only hold certain types of data. There's no way to discover the
requested type of the array, only the actual format that was chosen to
implement the requested type. This is what "upgrading" is about: we
don't expect there to be specialized formats for every possible type, so
more general formats are often used. And in most cases, it will be the
most general format, which allows any type of data.
What you might want to do is provide your own functions for creating and
filling in the arrays that are used with your application, perhaps
hiding it all in CLOS objects. Your function could check that only
numbers are stored into the arrays.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***