I see in the CLHS that :element-type actually enforces
(upgraded-array-element-type type). In CLISP,
(upgraded-array-element-type x) => T for all X that I can come up with.
Is this a shortcoming of CLOS and/or arrays in CLISP?
In article <······················@fed1read03>,
Ari Johnson <·····@hotmail.com> wrote:
> I see in the CLHS that :element-type actually enforces
> (upgraded-array-element-type type). In CLISP,
This is a tautology, since UPGRADED-ARRAY-ELEMENT-TYPE is defined in
terms of what MAKE-ARRAY does (or vice versa).
> (upgraded-array-element-type x) => T for all X that I can come up with.
> Is this a shortcoming of CLOS and/or arrays in CLISP?
CL requires that there be specialized array types for strings and bit
strings, but everything else can be a general array.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> In article <······················@fed1read03>,
> Ari Johnson <·····@hotmail.com> wrote:
>
>
>>I see in the CLHS that :element-type actually enforces
>>(upgraded-array-element-type type). In CLISP,
>
>
> This is a tautology, since UPGRADED-ARRAY-ELEMENT-TYPE is defined in
> terms of what MAKE-ARRAY does (or vice versa).
>
>
>>(upgraded-array-element-type x) => T for all X that I can come up with.
>> Is this a shortcoming of CLOS and/or arrays in CLISP?
>
>
> CL requires that there be specialized array types for strings and bit
> strings, but everything else can be a general array.
Thanks - I was reading more into it than is there.
Barry Margolin wrote:
> CL requires that there be specialized array types for strings and bit
> strings, but everything else can be a general array.
More precisely, it requires that u-a-e-t of BIT or CHARACTER be type
equivalent to those types (no requirement that the element type be
of a one dimensional array). It also requires that any subtype
of BIT or CHARACTER have u-a-e-t of BIT or CHARACTER (respectively).
Paul