[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: Ram@C.CS.CMU.EDU
- Date: Sat, 27 Feb 1988 21:17 EST
- Cc: cl-cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA, vanroggen%aitg.decnet@HUDSON.DEC.COM
- In-reply-to: Msg of 25 Feb 1988 12:19-EST from Jon L White <edsel!jonl at labrea.Stanford.EDU>
- Sender: RAM@λλ
Well, I don't agree with VanRoggen's stand on the &rest type issue,
but I think he is pretty close to the mark about array types. This
isn't inconsistent, since the desirability or feasilibility of a typed
list specifier is pretty unrelated to the &rest issue.
Date: Thursday, 25 February 1988 12:19-EST
From: Jon L White <edsel!jonl at labrea.Stanford.EDU>
To: vanroggen%aitg.decnet at hudson.dec.com
Setting an element of A to be something that's not of type FOO is
an error. The representation might allow it, because the new value
might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it
correct. It's just a matter of whether the array happened to
remember the precise type it was created with.
Perhaps the clearest indicator that CLtL really isn't saying this is
found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how
this section really is "clear" that an array made by
(make-array 5 :element-type '(mod 5))
may legitimately have an element stored into it that is of type (mod 8)
but not necessarily of type (mod 5).
No, this example doesn't make it clear. If you make an array
:element-type (mod 5), then it is an error to ever store anything in
that array that isn't (mod 5). What the example make clear is that
implementation has discretion to upgrade the element type. A
corollary is that it has discretion to not upgrade the element type.
Since a Common Lisp implementation is free to implement whatever
specialized array types it pleases, Common Lisp programs must assume
that every type potentially has an exact specialization.
The only rationale under which one could store something not (mod 5)
into that array would be that they could make the array, then call
ARRAY-ELEMENT-TYPE to find out that element types it can actually
hold, and then store randomness into it. I don't believe that this is
a reasonable thing to do.
This basically amounts to bogotifying the language in order to make
ARRAY-ELEMENT-TYPE work. This is a bad idea, since I think that the
semantics of ARRAY-ELEMENT-TYPE are just as seriously flawed as the
semantics of TYPE-OF. (which is another flame)
It is much easier to give types a clean semantics in Common Lisp if
ARRAY-ELEMENT-TYPE and TYPE-OF are ignored. For example, without
these functions, there would be no way for users to even know that
"array element type upgrading" exists. (Assuming the array TYPEP
"feature" mentioned in the manual is fixed.)