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.
Per Bothner <per@xxxxxxxxxxx> writes: > Your argument hinges on the term "addition", which you don't define, > so it's meaningless. A good approximation is + as defined by R5RS. > Do you consider "complex number addition" to be "addition"? Definitely. > Do you consider "matrix addition" to be "addition"? If Scheme supported generic functions and made + extensible, then it would make sense to let a library providing matrices specialize + on matrices to mean matrix 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. There is a very good reason: addition of integers is already defined to mean something else. A necessary condition for adding any overload is that it doesn't conflict with existing overloads. If Scheme used generic functions, you could add a separate 32-bit unsigned integer type, for which + means modulo. Note that with typical implementations they would be less efficient than fixnums and would require heap allocation for all numbers, so it would make little sense to use them just for efficiency. I'm not convinced that this type is useful often enough to provide it by standard Scheme. > In fact most programming languages do consider the latter to > be "addition". I disagree with "most": Lisp, R5RS, Dylan, Smalltalk, Python, Ruby, Perl, SML don't make modular arithmetic the default, Haskell provides two equally well supported integer types - one correct and one with wraparound, and even C# can be told to throw exceptions in case of overflow. I disagree with making this compromise between efficiency and correctness the default for Scheme. SRFI-77 provides a way to use the fast but incorrect addition in cases the programmer has manually proven they are correct. It could be done in some different way, perhaps even by some declarations scoped over regular arithmetic operators, but it should not break existing addition. Note that in almost all Scheme implementations fixnums are not exactly 32 bits but slightly smaller (or slightly smaller than 64 bits) and signed. There is an extremely slim chance that one would need the semantics of wraparound over an unspecified number of bits of a signed type, except when he just wants to detect fixnum overflow and redo the computation differently in this case (or let the program fail). It's not a variant addition that anybody really wants, but just something that happens to be implementable on current hardware faster than any other approximation of 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? Yes. Although the amount of doing that is a matter of taste, and it could be abused. > * 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? Yes, as long as they don't conflict with more correct interpretations of these operations for the same arguments. -- __("< Marcin Kowalczyk \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/