[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Moon@stony-brook.scrc.symbolics.com
- Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
- From: Jon L White <firstname.lastname@example.org>
- Date: Sat, 21 May 88 06:05:42 PDT
- Cc: email@example.com
- In-reply-to: David A. Moon's message of Fri, 20 May 88 23:59 EDT <19880521035951.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
You raise a number of good points here. I'm going to reply to several
of them out-of-order, to do the "easier" ones first.
re: In the discussion section, "In short, no one would not want to
gain portability at the expense of limiting the language . . .
Take out a "not."
Yes, several persons here at Lucid noted the typo too. Take out a "not".
re: I don't understand the justification for introducing the function
UPGRADE-ARRAY-ELEMENT-TYPE. There are plenty of other type operators
missing from Common Lisp, why put in just this one?
Because of the prevalence of user confusion about "upgrading" in arrays;
this gives him a reasonable query mechanism for a very common problem. It
also, quite likely, reflects a functionality that each implementation will
have to provide for itself anyway.
re: You don't list what type specifiers it applies to. I assume you mean
to include SIMPLE-ARRAY and VECTOR in addition to ARRAY. What about
I didn't think that explicit mention of SIMPLE-ARRAY and VECTOR was
necessary, as they are subtypes of ARRAY. However, it can't hurt to
put in the one sentence clarification. I did not mean COMPLEX; I only
meant to cover arrays. Perhaps COMPLEX could be "swept under the same
rug"; do you think it is a good idea to do so?
re: Your proposal assumes without stating it explicitly that
(array-element-type (make-array dimensions :element-type element-type
is independent of the values of dimensions and options. I believe this
to be true of most implementations, but see nothing in CLtL that requires
it. . . . This could seriously impact the adoption cost. I think I
have mentioned this before; do I have to drag out all the other comments
I made last time this issue came up?
Yes, I think this assumption about independence is right. I don't remember
your bringing out any such discussion on cl-cleanup before; the only note
I can find is just a statement of this same assumption sent out to the
common-lisp mailing list:
Date: Fri, 11 Mar 88 16:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: the array type mess....
Cc: Jon L White <edsel!jonl@LABREA.STANFORD.EDU>,
. . .
An interesting comment on all this is that we are implicitly assuming
that an implementation's spectrum of specialized array types is independent
of the size, number of dimensions, indirectness, or adjustability of the
array. This seems unlikely to be true of all implementations. I don't
know how to fix this deficiency.
Someone should write this up in Cleanup form and thus give us all
a chance to think about it more deeply.
But the grim file reaper seems to have put on temporarily inaccessible
back-up tape my cl-cleanp archives prior to Mar 4, 1988. So I may have
just missed all the commentary about it before.
On the other hand, if this assumption is violated, the I'd be curious
to know how an implementation can do, say, displacement of a vector to
a multi-dimensional array with conformal element type, and vice-versa.
I've heard that Symbolics users frequently do this in order to run
sequence-like functions over 2-dimensional arrays.
re: The proposal is much too long and contains too many digressions.
There are two proposals here, you know; the verbal discussion in Palo Alto
on March 13 suggested we would need two (and maybe this was a first?). I
have had commentary on it from folks at Lucid, but I note that CL-CLEANUP
has been effectively moribund for the six weeks prior to the submission of
this proposal. So I don't think the lack of other public replies means it
is any more difficult to comprehend than the other long proposals (such as,
On the other hand, I agree that is is unfortunately long; I don't easily see
what can be deleted without opening up loopholes for someone to argue against.
Do you have some specific suggestions as to what could be elided without
inviting more criticism?
-- JonL --