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.
Your argument hinges on the term "addition", which you don't define, so it's meaningless. Do you consider "complex number addition" to be "addition"? Do you consider "matrix addition" to be "addition"? If you allow either of the former to be 'addition" then there is no a priori reason to reject "32-bit unsigned modulo addition with wrap-around" to be addition as well. In fact most programming languages do consider the latter to be "addition". What it really boils down to: * Is it wise/useful/desirable to overload operations so that different (but in-some-way-related) operations are named by the same operation name? * Is it wise/useful/desirable overload the operation names for standard arithmetic to objects that don't obey all the rules of complex number arithmetic? * A slightly different question: what is a number? Is a quantity with a dimension a number? Is a 32-bit unsigned machine integer a number? Is a complex a number? I have no problem with you saying that you don't think my idea is a good idea. (I'm not sure it is myself - probably not for R6RS.) But I don't think you have basis for calling t "dead wrong". bear wrote:
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
-- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/