[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue FIXNUM-NONPORTABLE (Version 1)
- To: email@example.com
- Subject: Re: Issue FIXNUM-NONPORTABLE (Version 1)
- From: masinter.pa@Xerox.COM
- Date: 15 Sep 88 01:15 PDT
- Cc: Masinter.pa@Xerox.COM
I separated this issue from BOGUS-FIXNUM. Why don't we get this one out of the
way and then see what we have left?
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 15-Sep-88, Masinter
based on BOGUS-FIXNUM by Sandra Loosemore
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) remove the type BIGNUM from the language.
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable, and allows programmers to use the
FIXNUM type specifier in a way similar to how the "int" type is used
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
Cost to implementors:
Slight. All implementations I know of already define FIXNUMs to be at
least 16 bits and would only have to remove the BIGNUM type specifier
to be in compliance with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Earlier versions of this proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
might need to set MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM
to arbitrary values, consistent with the requirement that (SIGNED-BYTE 16) is a
Other alternatives considered (and not necessarly mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely
leave the range of FIXNUMs unconstrained and a SMALL-INTEGER type
with a fixed range (but no promises about efficiency) introduced.
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing)