Re: small integers

[Simon Spero <ses@SunSite.unc.edu>]

   Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU writes:

>I don't think this will work.  The fact that a function will return only a
>fixnum, if it returns anything at all, must be known at compile time if you
>are to generate optimal code.  Handlers are established dynamically, not
>lexically, so the compiler could not be sure what policy would be in effect
>when a function is called.

What I was thinking off was trying static analysis to determine which handler
would be in force for a given function; if it can be shown that for all 
invocations the error re-raising version is in force, then one can deduce 
that the only valid return type is fixnum; if this cannot be shown, then 
we're back where we started. This analysis could be simplified by using  some
macro (with-small-integers &rest body),sorry, #rest; force of habitr, which
would set the hander appropriately. The same goes for the bignum version.

The  idea is that the compiler would treat these handlers as special cases
and generate the same code as before when the chosen policy is known at 
compile time.

The advantage of this method is that it doesn't introduce any strange new 
semantics; bignums are generated by overflows triggering an exception/retry 
like mechanism in nearly all implementations now (did it overflow? jump to
bignum code). It's more flexible that the either/or solutions, and is 
conceptually pretty simple.

The big disadvantages are that if the analysis fails, then the result type
is no longer known exactly, and overflowing bignums may cost an extra  
function call. Another hassle is that this introduces yet another potential
place to split. There's probably a show-stopper in there, but I can't quite
see it.
>
>I don't understand your other suggestion.

Well, I was trying to be obfuscuated, but I guess I over did it; what I was 
really doing (I think - it's getting early this side of the pond) was suggesting
a name for the previously proposed machine-length 'integer'; by calling it
'long', programmers who are used to 'C' will automatically intuit its 
non-numeric properties. The usual problems of boxing and unboxing still apply,
but static analysis can get rid of most redundant box/unbox pairs. 

'long' would not be a replacement for the existing integer types; it would 
be an additional integer like type for use by the mathematically impure.

Simon