Per Bothner <xxxxxx@bothner.com> 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
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/