This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
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