[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
- To: jonl@lucid.com, masinter.pa@Xerox.COM
- Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
- From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
- Date: Wed, 11 Jan 89 23:12 EST
- Cc: cl-cleanup@Sail.Stanford.Edu
- In-reply-to: <8901120148.AA07016@bhopal>
Date: Wed, 11 Jan 89 17:48:32 PST
From: Jon L White <jonl@lucid.com>
re: As I think about it, I'm not sure why we rule out the possibility that the
upgrading of arrays might happen differently for different arrays: for
example, I might have an algorithm that "upgraded" all simple
non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,
but be more strict about larger arrays.
Lucid would certainly oppose that change. Our compiler optimizations
work on simple-arrays of known element type; and good reasons exist
as to why the simple/non-simple distinction and the element-type
distinctions are important (other "stock hardware" implmentations
have similar open-coding techniques). I see no benefit to further
discrimination based on rank or array total size.
-- JonL --
Right. If you can't determine the upgraded type from a declaration, the
declaration is next to useless. (It just is not reasonable to have to,
for instance, know the size of an array in order to be able to determine
how to access it.)