Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)

[Jon L White <jonl@lucid.com>]

re: I think that the only issue we really have the charter to attack is to
    "fix" what we think was a mistake in the wording of the amendment that
    was accepted at the last meeting. 

There were two sorts of "bugs" in the proposal as brought to, and
voted upon in, Hawai:
  (1) a number of little unclarities about the precise relationship
      between ADJUSTABLE-ARRAY-P and error signalling in ADJUST-ARRAY
  (2) Confusion as to whether or not the type SIMPLE-ARRAY was to
      changed from the simple defintion on CLtL p28.

Presumably (1) has been the subject of the volumes of "private" mail,
and much related public mail.  However, I still don't see any clear 
statement in the latest proposal regarding point (2) -- namely that it 
is not trying to change the type SIMPLE-ARRAY.  There is in fact a
very confusing statement in the rationale section of the most recent
version:
  "Specifying the points left unspecified (requiring all simple arrays to be
   non-adjustable and all adjustable arrays to be non-simple) would require
   large changes to some implementations and would be of little benefit to
   ..."
Virtually everyone who reads the last paragraph of CLtL p.28 believes it 
to be a _definition_ of SIMPLE-ARRAY (except some folks at Symbolics) -- 
and that clearly says non-adjustable.  In previous mail, I alluded to 
reasons why the _utility_ of the type SIMPLE-ARRAY requires it to mean 
non-adjustable; that was the clear consensus of all the "stock-hardware" 
compiler implementors who where at Hawaii (and at least one other
implementor too).  There is simply no point at all in having SIMPLE-ARRAY
in the language if it isn't of critical use to these implementations.

As someone mentioned, there is language in CLtL about how simple-arrays
might be implemented "differently" from implementation to implementation
(i.e., "be more efficient on some implementations", or whatever).  Could
that statement be the source that has misled so many people to believe 
that the permission to implement the  internal structure differently gives 
a permission to implement the type differently?  Considering the tremendous 
amount of time wasted arguing this non point, it would be a great help if 
the final version of the issue contained the simple statement:

 "This proposal does not alter the definition of SIMPLE-ARRAY in any way."


Here's a synopsis of the damage that can occur unless some such
clarification is made.  Consider the following function:

     (defun fast-aref (x i)
       (declare (optimize (safety 0) (speed 3)))
       (check-type x (simple-array t 1))
       (setf (aref (the (simple-array t 1) x) i)	;open-compiled
             :encountered)
       t)

     (defparameter foo (make-array 5 :adjustable t))

What happens when FOO is passed to FAST-AREF?  If SIMPLE-ARRAY can't be 
assured to mean non-adjustable, then either the aforementioned compiler-
writers must give up their long-held technology that allows Lisp to 
compete with C; or perhaps they would ignore this issue entirely, and
the portability of Common Lisp would be officially compromised.  That is,
if the language permits SIMPLE-ARRAY to mean one thing in one implementation,
and another thing in another implementation (under a false sense of 
permitting optional efficiency), then this little example will "break" in 
one implementation but will "work" in the other -- in short, the type 
SIMPLE-ARRAY will not be portable.  

I seriously doubt that the "stock hardware" types will give up their 
optimizations.  Hence we must ask ourselves whether we would view 
non-portability of SIMPLE-ARRAY as a simply a fact that one (or two?) 
implementations never did (and never will?) fulfill the definition on 
p28; or whether we view it is a **good thing** to be non-portable (as 
in the remaining cases of the FIXNUM type).  If it comes to the latter, 
then I think we will have to admit that the standardization process will 
have failed.



-- JonL --