Issue: BOGUS-FIXNUMS

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Perhaps the real cause of trouble here is that we have only one type, FIXNUM,
for two purposes -- (a) `machine precision' of either non-portable or 
hyper-optimized programs like Macsyma (b) `small integers' desiring 
efficiency.

The reason I suggested SMALL-INTEGER is that I think that's what some people
really want to say. I'm much less strong on elminating FIXNUM than I am on
providing a useful alternative. As it is now, if you want efficient code but
also want it to be portable, you have nothing to say beyond a cumbersome
signed-byte or bounded integer range. Just as we provide the `common' 
sequence operations because it saves everyone from writing them over and
over, so too we should provide the common declarations to save everyone from
writing them.

I think what Sandra is saying is not argued. FIXNUM declarations are very
seldom portable. Even in Macsyma, the alternate fixnum declared code might
sometimes be gone into on the basis of inputs being fixnums, sometimes not
worrying as carefully as it might about whether intermediate values or
outputs will all be fixnums. And every now and then you might lose unless
you've done some careful checking. GZ, JDalton, etc. are saying they're
willing to do such checking sometimes.

The problem is that naive users will see FIXNUM and mentally relate it to
small integers when it's really quite different. Surely, I can imagine such
a user saying, there is at least the concept of a small integer. Since 
there's only one type even remotely like that, it must be it. In fact, that
would be a wrong assumption. My reading of CLtL says the fixnum subrange
need not even include zero. It might be (INTEGER 5 25), for example. There
might, therefore, be integers smaller than FIXNUMs. We might want to just
plain fix that. It might also include no numbers (though that leaves an
implementation in a quandry about what to put in MOST-POSITIVE-FIXNUM, etc.)
I think some CDC CL had this problem. As best I remember from a manual I saw
a couple years ago, they had set the MOST-xxx vars to NIL because they had
the same representation for all numbers and had chosen them to either all
be fixnums or all be bignums, I don't recall. All of this is bound to confuse
a novice who may just be seeking a simple, efficient type declaration.

My revised view is that we leave FIXNUM and its associated vars be, and
add SMALL-INTEGER. We should choose the range of SMALL-INTEGER such that,
then clearly document that, SMALL-INTEGER is a portable concept which
might lead to inefficiency in an occasional implementation, but in most
implementations it will be suitably fast. We should document that FIXNUM
is intended to denote an implementation-specific type which is not
portable, but which is useful in certain applications, like Macsyma, which
have need to take the fullest advantage of whatever machine they're on, even
at the price of dealing more carefully with portability issues.
I think the availability of a pre-defined and usefully sized type such as
SMALL-INTEGER will make this explanation of FIXNUM much more palatable.

I would remove the type BIGNUM. I think everyone expects it to mean
(AND INTEGER (NOT FIXNUM)) anyway. I bet any implementation where it doesn't
mean this violates user expectations. Given that, one could just DEFTYPE
it for compatibility if it was really used heavily in some particular case.