[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
- To: IIM@ECLA.USC.EDU
- Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
- From: Jon L White <jonl@lucid.com>
- Date: Fri, 9 Dec 88 23:37:12 PST
- Cc: cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: Kim A. Barrett's message of Wed 7 Dec 88 13:41:44-PST <12452601261.24.IIM@ECLA.USC.EDU>
re: [an] attempt to make it clear that specifying :adjustable NIL only permits
a non-adjustable representation be returned, but does not guarantee that
the object returned will be non-adjustable. This sounds like a pretty
good characterization of current practice to me.
I thought I made my opposition clear enough -- that the Symbolics "status
quo" is not the status quo for the community at large; their "extension"
is not one that is fully compatible with (the obvious reading of) CLtL.
In particular, the part that of the proposal that suggests that
(make-arry n :adjustable nil)
can legitimately return an adjustable array flies in the face of the
very reason reason why the type SIMPLE-ARRAY was introduced into Common
Lisp in the first place! Listen very carefully to those implementing
Lisp on stock hardware -- ask if they think it is perfectly fine to
**** have no way whatsoever *** to guarantee getting a non-adjustable array.
The history you might be missing is that, from the very beginning, some
folks from the "special purpose Lisp machine" companies opposed the
compromise to admit SIMPLE-ARRAYs. It makes one factor of "stock hardware"
efficiency visible in the language itself. I called their re-reading of
CLtL on this point disingenuous, because there is no precedent whatsoever
for the alleged loophole whereby the English phrases:
"... [an array that] is not to have its size adjusted dynamically
after creation is called a simple array." [p.28]
"If make-array is called with the :adjustable [option] ... not supplied
or NIL, then the resulting array is guaranteed to be a simple array."
[p.289]
"It is not permitted to call ADJUST-ARRAY on an array that was
not created with the :ADJUSTABLE option" [p.297]
can mean just the opposite of what the are evidently saying. In contrast,
-- p.28 evidently says that a simple array *must not* be adjustable.
-- p.289 evidently says that "not supplying" the adjustable option is a
required part of *** the only way specified *** for makeing a simple
array [supplying NIL is the same as "not supplying"].
-- p.297 evidently implies the converse, that a non-NIL value must be
supplied to MAKE-ARRAY, as the :ADJUSTABLE option, in order to be able
to dynamically adjust the result.
I think this language of CLtL, p.28, p.289, and p.297 is adequately clear.
One might ask for additional clarifying statements, but it should be obvious
to just about anyone that if the :ADJUSTABLE argument/option could be
legitimately ignored, then *** an explicit statement to the effect ***
would have been put somewhere in the text.
I can even hazard a guess as to why p.297 says "created with the
:ADJUSTABLE option", rather than saying "created by supplying a non-NIL
value for the :ADJUSTABLE argument". Many Lisp Machine functions and
macros would permit the user to specify some alternative simply by including
a certain keyword in a list of options; DEFSTRUCT still has this style of
syntax (see CLtL p.311). At one point in time, someone working on the
text that became CLtL considered adjustability an "option" for arrays,
which could simply be specified by supplying the :ADJUSTABLE argument;
only later did we notice that &keyword arguments are not by themselves
"options", but rather "named arguments". Clearly,
(make-array n :adjustable t)
supplies the :adjustable option, whereas
(make-array n :adjustable nil)
does not supply it.
-- JonL ---