Re: small integers

[moon (David A. Moon)]

> Date: Wed, 07 Oct 92 17:57:37 -0400
> From: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
> 
> It isn't really clear from the book, but the Dylan <integer> class
> evidently supports extended-precision arithmetic.  Since small integers are
> ubiquitous, good small-integer preformance is crucial for all manner of
> applications.  There must be some way of informing the compiler that
> arimthmetic operands are small integers and that the result will be a small
> integer.

Agreed.

Actually our implementations already have a class named <small-integer> which 
behaves the same as Common Lisp fixnum.  I guess you would say that when we 
argued about whether this class ought to be included in the book, the wrong 
faction won, because writing portable efficient code requires mentioning the 
class <small-integer> from time to time.

> ....
> Small/extended integer proposal:
> 
> There shall be two disjoint subclasses of <integer>:
>     <small-integer>
>     <extended-integer>
> ....
> Note that a <small-integer> and an <extended-integer> may have the same
> numeric value (such as 5).  In such a case, the class distinction serves to
> control the over/underflow behavior.  AS may be used to convert between
> integer classes:
>     (as <small-integer> some-integer) 
>     (as <extended-integer> some-integer) 

This is only my initial reaction, but this strikes me as a really bad idea, 
because it violates the principle that correct programs should be easy to 
write and the burden of micro-optimization should be on programmers who need 
to do micro-optimization, not on all programmers.  It seems to me that you're 
making the language significantly more complicated and hard to understand, 
just to make compiler optimization a little easier.  The specific aspect I 
object to is having two non-id?, non-operationally-equivalent integers with 
the same mathematical value.

Can't we find a less semantically violent way to enable the desired compiler 
optimization?  Correct me if I'm wrong, you've thought a lot more about this 
kind of compiler optimization than I have, but it seems to me that what you 
are really aiming for is a way for the compiler to infer that the results of 
certain operations will lie within the <small-integer> subrange of <integer>, 
given information about the integer subrange of the arguments, supplied either 
by programmer annotation or by type inference.  Is it really necessary to give 
up any hope of being able to do such inference within the existing semantics 
of Dylan (possibly with addition of finer-grained type specifiers for integer 
subranges)?  If so, what is the evidence?