[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: meta-comment on typing

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.


	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/