CLHS: Issue ARRAY-DIMENSION-LIMIT-IMPLICATIONS Writeup

#

## 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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.