[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Moon@stony-brook.scrc.symbolics.com
- Subject: function-type-rest-list-element
- From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
- Date: Mon, 29 Feb 88 19:54:18 PST
- Cc: email@example.com, firstname.lastname@example.org, Ram@c.cs.cmu.edu
- In-reply-to: David A. Moon's message of Mon, 29 Feb 88 16:53 EST <19880229215350.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
re: . . . CLtL isn't sure whether its data types are portable, fairly
abstract types or are ways to find out about implementation details.
Good point. In that series of messages a couple of months ago (?) on this
issue, there were basically two camps of opinions:
(1) array types should be completely portable -- hence the exact
equivalence class of the :element-type specifier must be "remembered"
(2) "Upgrading" is reasonable, albeit a source of non-portability akin to
the fixnum/bignum split; to do otherwise isn't worth it.
Both Rob and Walter are espousing position (1), and may not have fully
noticed that it isn't mandated by CLtL. I myself forget the horrible
intricacies of array types from time to time. Worse yet, I waffle between
preferring (1) and (2) depending on the latest "arguments" for one or
the other. To me, this indicates that an easy solution isn't at hand.
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.
-- JonL --