issue BOGUS-FIXNUMS (initial draft)

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

This proposal might go over better if we replaced the feature with
another, more portable, feature addressing a similar need. eg,

 FIXNUM could be left undefined as proposed, and then implementations
 could support it as a non-portable extension

but also

 SMALL-INTEGER could be defined as some range of integers which we
 think most implementations can support efficiently (but with the
 understanding that the important thing is to support it correctly
 rather than efficiently). For example, maybe SMALL-INTEGER could
 be defined as (INTEGER -2â??30 (2â??30)). [The specific bounds is open
 to discussion, of course, I'm just proposing ``something like this''.]

 As a corollary, MOST-POSITIVE-EFFICIENTLY-REPRESENTABLE-INTEGER, etc
 might hold an integer (or NIL, if the concept made no sense for some
 reason in a particular implementation -- eg, all numbers were bignums)
 with no necessary relation to the type SMALL-INTEGER. Maybe it could
 just be MOST-POSITIVE-EFFICIENT-INTEGER.

That way, people could declare known-to-be-small integers without
being concerned that some pathological implementation would screw them
by having an ultra-tiny range.

Note also that there'd be a slight two's-complement bias there, but the
alternative seems to be to offer nothing, and I'm not sure that that's
better.

Does anyone think this is worth trying to incorporate with this proposal
to make it more palatable to those who are worried that striking FIXNUM
will lose them functionality. (I don't dispute Sandra's claim that almost
no one knows how to use FIXNUM portably. There are a few, but only very
few, portable uses, and I think not enough to worry about. I'm just
concerned that people use FIXNUM because it's all we offer and that 
perhaps what that really means is not that we should give up on the
feature, but rather that there's such severe need for it that we should
come up with something better.)