Issue: ARRAY-DIMENSION-LIMIT-IMPLICATIONSForum: 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.