[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
function-type-rest-list-element (really array types)
- To: Jon L White <edsel!jonl@LABREA.STANFORD.EDU>
- Subject: function-type-rest-list-element (really array types)
- From: Ram@C.CS.CMU.EDU
- Date: Tue, 1 Mar 1988 16:08 EST
- Cc: cl-cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA, vanroggen%aitg.decnet@HUDSON.DEC.COM
- In-reply-to: Msg of 29 Feb 1988 22:54-EST from Jon L White <edsel!jonl at labrea.Stanford.EDU>
- Sender: RAM@λλ
Date: Monday, 29 February 1988 22:54-EST
From: Jon L White <edsel!jonl at labrea.Stanford.EDU>
To: Moon at stony-brook.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.
Actually I'm not proposing 1, at least as I understand what you are
saying. My idea is that TYPEP automatically "upgrade" its type
argument to the corresponding "implementation type", i.e. a type
actually supported by the implementation. This basically amounts to
requiring the programmer (as opposed to the array) the remember the
array element type, but in the absence of a hard semantics for
ARRAY-ELEMENT-TYPE/TYPE-OF, this is the same as requiring that arrays
"remember their element-type".
I think that analogies with the FIXNUM/INTEGER are flawed: FIXNUM has
is a precisely defined concept within the language:
`(integer ,most-negative-fixnum ,most-positive-fixnum)
Given this definition, a Common Lisp program can have a portable
understanding of what it means to be a FIXNUM. For example, it is
(typep most-negative-fixnum 'fixnum)
is true in any Common Lisp implementation.
With arrays, TYPEP is simply broken. Unless you use one of the
special element types, BIT, STRING-CHAR or T, TYPEP doesn't mean
anything on arrays.
It seems to me that the FIXNUM issue is kind of like a resource
"This program will only run when a fixnum is at least 16 bits."
is similar to
"This program will only run when you can have 1e6 element bit-vectors."
In constrast, there is no way to characterize the set of
implementations in which TYPEP will work on arrays. In fact, there
probably are no such implementations.
[...] 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.
Yes, I agree with this.