[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
- From: Jon L White <email@example.com>
- Date: Fri, 7 Oct 88 18:26:34 PDT
- Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-reply-to: David A. Moon's message of Fri, 7 Oct 88 16:02 EDT <19881007200231.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
re: [JonL] Here's the thing that keeps me from being as upset at this situation
as you are -- there are *several* places where "objects" can be stored
that one may desire specialization a la array-element-type. In particular
Lucid's customers keep asking for this sort of thing in defstructs and
flavor instances, and I notice with some chagrin the cleanup proposal
on type-specialized lists (e.g. list-of-unsigned-byte-8 or whatever).
Right now Common Lisp only uses "declaration versus discrimination" in
connection with ARRAY and COMPLEX.
Had we thought of it before, this issue should have been called
TYPE-SPECIFIER-SPECIALIZATION:UNIFY-DECLARATION. Your addition
of the COMPLEX stuff is ok by me, since it doesn't detract from the
fixup of arrays, nor from similar directions in the future.
But, in the future, we may have to worry about any lurking remnants of
the "schizophrenia"; I think it is more pervasive, in implicit ways,
than the explicit losage in the section 4.5.
re: I didn't see this message before sending my proposed revision
of ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, because the message
was not sent to the mailing list, only to individuals.
. . .
Date: Wed, 5 Oct 88 15:43:44 PDT
From: Jon L White <email@example.com>
. . .
I'd really prefer that to
[Moon] Either of these names would be okay with me. I would have
included the one you proposed in my revision of the proposal if I had
seen this message in time.
If you don't mind, then, I'll change it to IMPLEMENTED-ARRAY-ELEMENT-TYPE,
and analogously will change IMPLEMENTATION-COMPLEX-COMPONENT-TYPE to
IMPLEMENTED-COMPLEX-PART-TYPE [See CLtL, p220 and p47 where the "elements"
of a complex number are called "parts"]
-- JonL --