[m-rev.] Added int:'/'/2 and builtin false/0

[Michael Day]

> The point is that "truncating integer division" is not a mathematical
> division operation.  It has significantly different semantics to floating
> point division.  It makes sense to use a different symbol for different
> operations.

Thus you would only want to use the same symbol if integer division threw
an exception when it encountered a non-zero remainder, bringing its
semantics in line with those of floating point division?

eg. 16 / 2 = 8 is fine, 15 / 2 is undefined.

Seems like your dividing line is whether it would be possible, at least in
theory, to make operators mathematical by aborting on undefined cases.  
This is feasible for overflow or division by zero, but not feasible for
integer division, as it would make it practically useless. So your
argument goes that integer division is not mathematical division but a
completely different operation, as true integer division would be
something like int / int = rational.

The opposition to this is the "generally accepted practice" of allowing
operations like division and even square root to act on integers and round
or truncate as a matter of course, without denoting in any special way
that these operations are different (except in assembly language, which
uses different opcodes, hmm). Also the generally accepted practice of
pseudo-mathematical operations returning the same type as their arguments;  
I personally haven't seen an int->rational division example in the wild.

In between the "mathematical purity" stance and the "generally accepted
practice" stance is the awkward fact that ints will never be natural
numbers as they are cyclic rather than infinite and floats are not
rationals and certainly not reals and that you can sometimes add 1 to a
number and get back the same number. The most mathematical type in Mercury
is probably list, and the cleanest way to get natural numbers would be to
use a zero/succ type. int and float are merely foreign types that map to
underlying circuitry in a way that is conveniently close to numbers such
that mathematical abstractions can be used to model their usage, if you
don't look too hard at the corner cases.

And finally there is the endless debate of what does Joe Programmer
*really mean* by writing X / Y, and what will Jane Programmer assume when
reading X / Y? Probably that division is taking place, but not that 
multiplying by Y will bring back X, as that's something that rarely 
happens anywhere.

Michael

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------