Re: small integers

[Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU]

I generally like Rob Maclachlan's proposal for small and extended integer
types.  (Not surprising, perhaps, since Rob and I have discussed these
issues before.)

The Common Lisp decision to create a single integer type, with automatic
rollover into bignums as needed, is conceptually very elegant, but I've
gradually, relucantly, come around to the conclusion that it was a mistake
for real programming on real machines.  Assuming that the short-integers
(or fixnums, in CL parlance) are of reasonable size -- 28 bits or more is
typical -- bignums are rarely used, but having them available at all times
is expensive.  The bignum code significantly increases the size of the
runtime system, and if you want fixnum arithmetic to compile efficiently
inline you have to put "fixnum" type-declarations *everywhere*.  I wish I
had a dollar for every (the fixnum ...) form I've written (or that a macro
has written for me) in the past five years.

Under Rob's proposal, small-integer arithmetic would once again be easy and
efficient, and the extended-integer stuff could be an optional facility.
Some very small implementations of Dylan could decline to support extended
numbers at all, and others could load the extended arithmetic code only
when it is used.  Ratios (which often cross over into bignums) could be
supported as yet another optional facility.

I have two quibbles with Rob's proposal:

    Numeric operations on non-integers with integer results
    (truncate,floor,ceiling,round,/-variants,numerator,denominator, probably
    real-part, imag-part) always return <extended-integer>s.

This seems like the wrong default to me if we don't want extended-integers
to be sneaking in the back door all the time.

Second, I think users may find it very confusing to have an
extended-integer 5 and a short-integer 5 that print the same, and it is
awkward not to be able to type in the extended integers.  I think that the
extended integers need to be decorated in some way so that they are
visually different from short integers.  One possibility would be to use a
training decimal point to indicate an extended integer: 5. would be
extended, while 5 is a short-integer.  Alternatively, some # code might be
used.  I'm not sure if any existing language makes this same distinction
and has come up with a better convention.

-- Scott
===========================================================================
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu