On Thu, 6 Oct 2005, Per Bothner wrote:

>As I wrote: I'm *assuming* that + when operating on fixnums
>will return a fixnum even if it "overflows".
>
>I.e. that arithmetic on fixnums are defined "modularly" and
>fixnums are *not* just a subset of the integers.
>
>This implies that (fixnum? 0) is not true, though of course 0
>can be trivially *converted* to a fixnum: (fixnum? (as <fixnum> 0))
>is true.
>
>I can see that this might be a bit too radical.

Um, I would have said "dead wrong" rather than "too radical."

Addition should add.  It should give the correct answer, or
possibly signal an error.  Answers which are not correct
answers to addition are *NOT* answers that can or should be
returned from addition. And some kind of type polymorphism
with a distinct number type should not cause addition to
behave differently in the sense of giving answers with
different numeric values.

If you're talking about some kind of operation that acts
like addition over a limited range but is restricted to
that range and has well-defined modular-math semantics
that happen to be very easy to implement on twos-complement
machines with 32-bit words, that's valid too, and useful
in some binary stuff like cryptography, but it is *NOT*
addition and should not be confused with addition. It is
its own separate function with different semantics and
deserves a different function name.

			Bear