I've just run into a quandry with extending string support.
In this implementation (simple-array character (*)) and (array
character (*)) have distinct underlying representations.
It is a bit ambiguous in the CLHS as to how this should be.
"For all T1 and T2 other than *, (array T1) and (array T2) are two
different type specifiers that always refer to the same sets of things
if and only if they refer to arrays of exactly the same specialized
representation, i.e., if (upgraded-array-element-type 'T1) and
(upgraded-array-element-type 'T2) return two different type specifiers
that always refer to the same sets of objects. This is another way of
saying that `(array type-specifier) and `(array
,(upgraded-array-element-type 'type-specifier)) refer to the same set
of specialized array representations. For all T1 and T2 other than *,
the intersection of (array T1) and (array T2) is the empty set if and
only if they refer to arrays of different, distinct specialized
representations."
If specialized array representation refers to the underlying
implementation form, then (subtypep '(simple-array character (*))
'(array character (*))) should be false.
This is important since if they are subtypep, then the type-system
cannot distinguish something which is an (array character (*)) but not
a (simple-array character (*)), at least not in a natural way.
Hoping for clarification,
Regards,
Brian Spilsbury
·····@designix.com.au (Brian Spilsbury) wrote in message news:<····························@posting.google.com>...
> I've just run into a quandry with extending string support.
>
> In this implementation (simple-array character (*)) and (array
> character (*)) have distinct underlying representations.
Really I think you mean that (make-array 12 :fill-pointer 6 :element-type 'base-
char :initial-element #\Z) is an ARRAY but not a SIMPLE-ARRAY.
It is still the case that (make-string 12 :initial-element #\Z) is both an ARRAY
and a SIMPLE-ARRAY. So some members of (ARRAY CHARACTER (*)) have the same
"underlying representation" as the members of SIMPLE-STRING.
>
> It is a bit ambiguous in the CLHS as to how this should be.
>
> "For all T1 and T2 other than *, (array T1) and (array T2) are two
> different type specifiers that always refer to the same sets of things
> if and only if they refer to arrays of exactly the same specialized
> representation, i.e., if (upgraded-array-element-type 'T1) and
> (upgraded-array-element-type 'T2) return two different type specifiers
> that always refer to the same sets of objects. This is another way of
> saying that `(array type-specifier) and `(array
> ,(upgraded-array-element-type 'type-specifier)) refer to the same set
> of specialized array representations. For all T1 and T2 other than *,
> the intersection of (array T1) and (array T2) is the empty set if and
> only if they refer to arrays of different, distinct specialized
> representations."
This excerpt (I'm unsure of which section it comes from because you don't say)
doesn't say anything about the relationship between an ARRAY compound type and
the corresponding SIMPLE-ARRAY compound type. It only talks about the relation-
ship between types under ARRAY which have different actual-array-element-types.
(SIMPLE-ARRAY CHARACTER (*)) and (ARRAY CHARACTER (*)) have the same actual-
array-element-types.
>
> If specialized array representation refers to the underlying
> implementation form, then (subtypep '(simple-array character (*))
> '(array character (*))) should be false.
It "refers" (actually it appears to state very plainly, in the clause that fol-
lows the "i.e.,") to the actual-array-element-type an array contains after the
declared or explicit type has been upgraded. It's basically saying that when
deciding if two array types are the same or different, you should consider all
the element types that upgrade to the same type as the same. I think all the
remarks about UPGRADED-ARRAY-ELEMENT-TYPE clarify the context in which "special-
ized representation" is meant clearly enough. It means the array type specializ-
ed on the permitted element types it can hold.
There is a section in the HyperSpec which directs that the controlling verbiage
is that which most specifically speaks to an issue. (Sec 1.5.1.4.1)
Since the excerpt you quoted above doesn't say anything about simple arrays,
you might profit by finding some section that does.
Here is a quote from Section 15.2, SIMPLE-ARRAY:
"This compound type specifier is treated exactly as the corresponding compound
type specifier for type ARRAY would be treated, except that the set is further
constrained to include only simple arrays."
This is another way of expressing the nature of a subtype.
Section 2.3 of the Character Proposal is pretty specific about your question:
http://www.lisp.org/HyperSpec/Issues/iss026-writeup.html
"* SIMPLE-BASE-STRING is equivalent to (SIMPLE-ARRAY BASE-CHARACTER (*)).
SIMPLE-BASE-STRING is a subtype of BASE-STRING."
The issue of CHARACTER vs. BASE-CHARACTER would be relevant to your excerpt,
but is orthogonal to the issue of ARRAY vs. SIMPLE-ARRAY.
>
> This is important since if they are subtypep, then the type-system
> cannot distinguish something which is an (array character (*)) but not
> a (simple-array character (*)), at least not in a natural way.
I suppose the "natural" way would be for there to be an implementation-defined
subtype of ARRAY that is exclusive of SIMPLE-ARRAY. This type isn't part of CL
because it need not exist - an array with a fill-pointer, or displaced, or
explicitly adjustable MAY be of type SIMPLE-ARRAY, but need not be.
And don't forget ADJUSTABLE-ARRAY-P, ARRAY-HAS-FILL-POINTER-P, and
ARRAY-DISPLACEMENT, which reveal all the important information about members of
such a type.
> Hoping for clarification,
Hope this helps.
regards,
Nate Holloway