an alternate BOGUS-FIXNUMS proposal

[sandra%cdr@cs.utah.edu (Sandra J Loosemore)]

Gail Zacharias has suggested an alternate proposal on this issue.  The
relevant parts are:

> Proposal:	BOGUS-FIXNUMS:SET-MINIMUM
> 
> (1) Require that (SIGNED-BYTE 15) must be a subtype of FIXNUM.
> 
> (2) Specify that MOST-POSITIVE-FIXNUM and/or MOST-NEGATIVE-FIXNUM may be
> NIL to indicate no limit aside from any placed on the size of integers.
> That is, the FIXNUM type is equivalent to
>    `(INTEGER ,(OR MOST-NEGATIVE-FIXNUM '*) ,(OR MOST-POSITIVE-FIXNUM '*))
>
> Implementations which do not have fixnums (or do not wish to advertise them
> as such) should make the FIXNUM type be the same as INTEGER and set the
> MOST-POSITIVE/NEGATIVE-FIXNUM constants to NIL.
> 
> Implementations which have fixnums of less than 15 bits would become
> implementations without fixnums.  They would have to make FIXNUM be the
> same as INTEGER and pick a different name for their small integers.
> The efficient integers of such implementations cannot be taken advantage of
> by portable programs by means of FIXNUM declarations.


I suppose a proposal along these lines would be a better than the
status quo.  However, I do see some problems:

- It does not address the issue of what happens to the BIGNUM type
  specifier.  If it remains in the language, are BIGNUM and FIXNUM still
  required to be disjoint?  If an implementation has only a single
  representation for integers and FIXNUM == INTEGER, would the set of
  BIGNUMs be empty?  Or would it be similar to how the different types
  of floats are handled if an implementation does not support all 4
  distinct representations?

- Programmers would still be able to put FIXNUM declarations in their
  code, but under this proposal FIXNUMs would not necessarily guarantee
  the most efficient representation (which appears to be the main reason
  why people are so anxious to preserve the FIXNUM type in the first
  place).

- Forcing users to DEFTYPE their own integer subrange types instead
  would encourage better use of data abstraction.  I've noticed that 
  Lisp programs are typically much sloppier about this than programs
  written in strongly typed languages such as C or Pascal. 

Also, note that if users specify a smaller subrange of integers than
the nominal FIXNUM size in their declarations, it may be possible to
get even more improvements in performance.  For example, a Lisp
implementation on a M68000 typically sizes fixnums to fit in a 32-bit
longword, but if enough type information is available to deduce that
the integers will fit in 16 bits (including perhaps 2 or 3 low tag
bits), it would be possible to use the significantly faster word-sized
arithmetic operations instead of longword operations.

-Sandra
-------