[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
an alternate BOGUS-FIXNUMS proposal
- To: email@example.com, firstname.lastname@example.org (Gail Zacharias)
- Subject: an alternate BOGUS-FIXNUMS proposal
- From: email@example.com (Sandra J Loosemore)
- Date: Wed, 13 Jul 88 09:52:31 MDT
- In-reply-to: firstname.lastname@example.org (Gail Zacharias), 12 Jul 88 18:30:10 EDT (Tue)
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
- 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
- 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.