Issue ARRAY-DIMENSION-LIMIT-IMPLICATIONS Writeup

Issue:        ARRAY-DIMENSION-LIMIT-IMPLICATIONS

Forum:	      Editorial

References:   FIXNUM-NON-PORTABLE

Category:     CHANGE

Edit history: 01-Mar-91, Version 1 by Pitman

	      13-Mar-91, Version 2 by Pitman

		(comments by Moon, Barrett, and JonL)

Status:	      For X3J13 consideration


Problem Description:


  Issue FIXNUM-NON-PORTABLE constrains ARRAY-DIMENSION-LIMIT to be 

  a fixnum, but this means that

     (MAKE-ARRAY (LIST (1- MOST-POSITIVE-FIXNUM) 2))

  is a valid program.  This in turn implies that:

     (ROW-MAJOR-AREF (MAKE-ARRAY (LIST (1- MOST-POSITIVE-FIXNUM) 2)) n)

  might need bignum values of N to access all elements of the array.


Proposal (ARRAY-DIMENSION-LIMIT-IMPLICATIONS:ALL-FIXNUM):


  Constrain the upper bound on ARRAY-TOTAL-SIZE-LIMIT

  (and ARRAY-RANK-LIMIT, by implication) in the same ways as

  ARRAY-DIMENSION-LIMIT is constrained.

 

  Clarify that the subscript arguments to AREF and to ROW-MAJOR-AREF

  must be fixnums.


Example:


  (MAKE-ARRAY (LIST MOST-POSITIVE-FIXNUM 2)) would be an error.


Rationale:


  This makes it safe for users to declare subscripts for ROW-MAJOR-AREF to

  be fixnums without knowing the nature of the array internals.  Without 

  this, in principle, an implementation could support bignum arithmetic

  internally for multi-dimensional arrays, and some situations involving

  ROW-MAJOR-AREF would have to presume that bignum arithmetic was needed

  in order to `keep up'.


Current Practice:


  Symbolics Genera makes the array dimension limit smaller than the

  most positive fixnum, so is not affected.


Cost to Implementors:


  None.


Cost to Users:


  None.


Cost of Non-Adoption:


  Some situations would be left fuzzy, and might keep users from making 

  certain fixnum declarations where desirable.


Benefits:


  See above. 


Aesthetics:


  Slight improvement--language is more consistent.


Discussion:


  Pitman thinks he supports this.


  Version 1 of this proposal had two parts:

    1. to allow ARRAY-DIMENSION-LIMIT to be a bignum (the smallest bignum)

       in implementations which wanted to permit the full fixnum range 

       for array size.

    2. the text of the proposal as it now stands.

  Part 1 was removed as controversial in v2 based on conversation which 

  followed, which is summarized here.

 

  Barrett said of version 1:

    ``I think the second item of the proposal is ok.

      I think the first item is unnecessary.''

 

  Moon says of version 1:

    ``... I do agree that ARRAY-TOTAL-SIZE-LIMIT should have

      been required to be a fixnum. Maybe ROW-MAJOR-AREF didn't exist

      when FIXNUM-NON-PORTABLE was written?''

 

  JonL says (in reply to Moon):

 

     ``Nope -- the relevant dates were March 1988 and January 1989.  

       In fact, ROW-MAJOR-AREF was suggested (I think) by GLS's 

       suggestions list from 6-Dec-85.  We probably just overlooked 

       ARRAY-TOTAL-SIZE-LIMIT in January 1989 [but as I recall, that

       issue accepted then had been argued about for two years or

       more; so the original presentation of FIXNUM-NON-PORTABLE may

       have occurred before ROW-MAJOR-AREF's.]

       History aside, I too agree that ARRAY-TOTAL-SIZE-LIMIT should 

       have been required to be a fixnum.''

 

  Note that the effect of removing part 1 of the v1 proposal is that

  the status quo is retained for the case that

     (MAKE-ARRAY MOST-POSITIVE-FIXNUM)

  is never a valid program in any implementation because of the

  constraints that currently exist on ARRAY-DIMENSION-LIMIT.