[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 
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 <jonl@lucid.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 --