[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 6 Oct 88 03:44 EDT
- In-reply-to: <881005-005724-4531@Xerox>
Ok, so I finally got caught up in my reading on this. This is starting
to look pretty good, but I've bot a bunch of picky little comments about
how this should be projected ...
Date: 5 Oct 88 00:57 PDT
in most implementations of CL, an array X created with and element-type
"an element-type" ?
This proposal suggests elimination of this distinction for the array types
ARRAY, SIMPLE-ARRAY, and VECTOR and their subtypes, by guaranteeing that
arrays constructed with a specific element-type satisfy the typep predicate
with the derived array type-specifier, and by guaranteeing that subtypep
reflect the type equivalences defined by the behavior of make-array.
This paragraph doesn't belong in the problem description!
-- Introduce a function, UPGRADE-ARRAY-ELEMENT-TYPE of one argument, which
reveals how the given implementation treats a particular :element-type
argument to make-array. Given a type-specifier <type1> as argument, it
returns a maximal type-specifier <type2> such that <type2> is the
actual specialized array element type used whenever <type1> is given as
an :element-type argument to MAKE-ARRAY. Note that
(upgrade-array-element-type '<type>) =
(array-element-type (make-array 0 :element-type '<type>))
for all type specifiers <type>.
I haven't decided how I feel about this part. You could do the same by
just saying ``Introduce the concept of an `upgraded' array-element-type...''
without actually providing the function that does the upgrading. But I guess
I think providing the function is harmless. Presumably it will be there anyway.
Thus, in each case, it should be true that:
I'd say "will happen to be true that", and emphasize that it's important
to know that this might happen -- but it's not something that should be
particularly depended upon since obviously it will vary across implementations.
That implies that the following set of tests should also be true:
(subtypep '(array <aet-x>) '(array <aet-y>))
This is a feature and should be encouraged.
(subtypep '(array <aet-y>) '(array <aet-x>))
This happens by accident and might not always happen. Again, document it, but
make sure it's clear that this is only something to `guard against' and not
something to generally depend upon.
Additionally, to show that un-equivalent type-specifiers that are upgraded
the same "element type" should be equivalent as element-type specifiers,
following type tests should be true:
(typep (make-array 0 :element-type '<aet-y>)
(typep (make-array 0 :element-type '<aet-x>)