[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
- To: jonl@LUCID.COM
- Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
- From: Kim A. Barrett <IIM@ECLA.USC.EDU>
- Date: Wed 7 Dec 88 13:41:44-PST
- Cc: IIM@ECLA.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: <8812070640.AA11552@bhopal>
> Date: Tue, 6 Dec 88 22:40:23 PST
> From: Jon L White <email@example.com>
Perhaps I'm misunderstanding where your objections are coming from. If they
are based on implementation issues, then I don't see the problem (see below).
If you don't want to allow the kind of extension that Symbolics and others
have made because of porting issues or some such thing, that's something else
entirely, and my comments below don't address your objections at all.
I really don't understand your opposition to the latest proposal (STATUS-QUO).
I don't see anything in it that would imply that all arrays must be adjustable
in all Common Lisp implementations. It has always been my understanding that
the :adjustable argument had the following meaning:
The implementation is required to return an array representation which it is
capable of adjusting, using adjust-array.
The implementation is given license to return an array representation which
is not adjustable, in the interest of efficiency. This is the default
because it is the most commonly used case, thus avoiding the requirement
that programmers explicitely supply it all over the place in order to get
a possibly efficiency improvement.
> Document clearly that omitting the :ADJUSTABLE option to MAKE-ARRAY
> or explicitly supplying :ADJUSTABLE NIL may not guarantee a non-adjustable
> array. ADJUSTABLE-ARRAY-P ... MIGHT be true of an array created with
> no :ADJUSTABLE option or with :ADJUSTABLE NIL.
The paragraph above, which you quoted from the proposal, seems to me to be 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. Symbolics makes all arrays
adjustable because they can do so for free, while stock hardware
implementations are free to use specialized non-adjustable representations
unless the programmer specifically requests otherwise.
Note that IIM Common Lisp implements ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR.
However, I am opposed to making this be the required behavior, in part because
of the significant incompatability with current practice and in part because
the Symbolics "extension" really doesn't seem all that unreasonable to me, so
I'm reluctant to say that it shouldn't be permitted. (I use quotes because,
strictly speaking, I don't consider it to be an extension. Rather, I think it
is a particular implementation which falls within the range of behavior
specified by CLtL).
I am strongly opposed to ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY, for
reasons that others have stated pretty well, so I won't repeat them here.
(See Fahlman's response, for example).