[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Jon L White <edsel!jonl@labrea.Stanford.EDU>
- Subject: function-type-rest-list-element
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 1 Mar 88 13:07 EST
- Cc: cl-cleanup@SAIL.STANFORD.EDU, email@example.com, Ram@c.cs.cmu.edu
- In-reply-to: <8803010354.AA04652@bhopal.lucid.com>
Date: Mon, 29 Feb 88 19:54:18 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
While there seemed to be no clear consensus on saying that types "must be"
portable, almost everyone agreed that the schizophrenia induced by CLtL p45
is a bad idea, and could easily be dropped. This is the part that says
"Types can therefore be used for two different purposes: declaration and
discrimination. ...", and implies as a consquence that the result of:
(make-array <n> :element-type '<type-spec>)
will probably not be of typep (array <type-spec>).
Not only is this very counterintuitive, but it really doesn't satisfy
any need that I'm aware of. At first blush, it might seem to be a
corollary of "upgrading"; but it isn't at all.
I don't know why the declaration vs discrimination thing was done. The
only thing I can guess at is that the idea was that if (typep a '(array
foo)), then it's -guaranteed- that (typep (aref a n) 'foo) is true,
because a is implemented with a representation that only holds objects
of type foo. Before speculating further I should of course leaf through
CLtL to see if it already contains somewhere an explanation of why the
declaration vs discrimination distinction was drawn.
Offhand getting rid of this distinction into two kinds of types seems
like a good idea. However, I'm a bit leery of changing things in the
language when I don't understand why they are there. At first thought,
removing the distinction seems like an upward-compatible change in the
sense that all it does is make some types that currently have no
members, in a particular implementation, have some members. However
there might be subtle incompatibilities with existing programs, since
the subtype rules would be changed, and in a way that depends on what
array representations a particular implementation has. I don't claim to
understand the implications right now.