Re: small integers

[Robert A. Cassels <cassels@cambridge.apple.com>]

>whether the compiler is smart enough to figure this out as well.  In
>practice, people just say "fixnum" and then complain about how slow
>arithmetic is in Lisp.  It's infinitely easier just to say, one way or
>another, that you don't believe overflows will occur in a certain part of
>the program, and that you want to get an error signal if you're wrong.

This part succinctly captures the dilemma as I see it.  We all agree that
we want fast, efficient, robust code.  And we want it to be easy for the
programmer to write such code.  Ideally we'd like the compiler and runtime
to be simple and easy to implement.  A machine that implements integer
arithmetic "in the instruction set" (c.f. Lisp machines) satisfies the
constraints nicely.  For most special-purpose C/Fortran machines, the set
of constraints can't be satisfied, and something has to give.

[BTW, Scott is correct that the issues for integers and floating-point are
completely different.  In this message I'll keep the focus on integers.]

I believe in clever compilers and I make a living building language
implementations, so I'm perfectly happy writing off the ease of
implementation constraint.

For me, the most important concern is robustness from the *user's* point of
view.  [See below for the user/devloper distinction.]

So can we make it easy to write extremely efficient, robust code on C
machines?  I don't know how to do it.  Your approach (signal overflow)
allows reasonably efficient code for most machines, though on most the
overflow test requires at least one extra instruction per operation.  What
that approach loses is a certain amount of robustness -- what does a user
of an application do when she gets that "error signal"?  That's the moral
equivalent of "out of memory" on a machine where you can't get any more for
some reason.  I would rather not give up that level of robustness, since we
have ways to address it.  [It's fine for a developer to get such error
signals during development, 'cause then she can do something about it.  A
user is SOL.  Of course it is completely wrong to silently truncate the
answer.]

So I personally would prefer a system where the default was to do
arithmetic as mathematically as possible, because that's the way I'd like
to think about the problem.  [If I wanted everything mod 32, I'd say that.]
 Then the question is how to make it as easy as possible for me to write
code that the compiler can turn into efficient machine instructions.  I
would like the compiler to figure out as much as it can about integer
ranges.  In cases where I know something about the range, I should have
easy, natural ways to give the compiler that information.  If I'm willing
to claim without any proof that the integer won't overflow, I should have a
way to say that.  But that last claim shouldn't be so easy or natural to
make, since if I'm wrong the user will suffer.