[Haskell-cafe] Re: Why purely in haskell?

[Ben Franksen]

jerzy.karczmarczuk at info.unicaen.fr wrote:
> Ben Franksen writes:
>> jerzy.karczmarczuk at info.unicaen.fr wrote:
> ...
>>> Does *MATH* answer the question what is: (0/0)==(0/0) ? Nope!
>> 
>> Exactly. So why try to give an answer in Haskell? MATH says: the
>> expression 0/0 is undefined, thus comparing (0/0)==(0/0) is undefined,
>> too. I would expect Haskell to say the same.
> 
> I don't know whether you are serious, or you are pulling my leg...
> Let's suppose that it is serious.
> 
> When math says that something is undefined, in my little brain I
> understand that there is no answer.
> NO answer.

Oh, come on. You know very well what I am talking about. Defined or
undefined is always relative to a set of axioms/laws that we usually take
for granted.

Division by zero is left undefined (in the sense of 'not defined') for a
reason: there is no way to define it without breaking some laws. E.g. A
one-point compactification of the real line is a nice thing but it breaks
total (global) ordering (and certain algebraic laws, IIRC). I knwo of no
mathematical theory that includes a NaN.

> Is this the "undefined" you want to have? The bottom non-termination?

In practice, it will be an exception.

> Now,
> this is obviously the *worst* possible reaction of the system, the IEEE
> indefinite is much better, at least you know what had happened.

It depends. An unsigned Infinity is ok if you are willing to concede that
odering is local only and not total. I.e. to every number there is an open
interval enclosing it on which the order is total, but it is not
(necessarily) total globally. Two (signed) infinities are ok if you are
willing to give up more laws.

> Would you propose the non-termination as the issue of all "errors", such
> as negative argument to the real sqrt, etc?

What do you suppose is the answer to

  head []

? What makes you think this is a less defined value, compared to, say, 0/0?

> Well, as you wish... But don't write medical software, please...

For medical software, somewhere at the end of the calculation there will be
some effect to the outside world, if only to display the calculated value.
Every pure calculation will eventually be called from the IO monad, where
we can catch the exception. What is the advantage of letting the pure
calculation continue while it is almost sure that the result will be Nan
(=Not a Nan ;) anyway?

In the end it won't make a big difference whether the 'undefined' result is
due to a (cought) exception or due to a Nan result. I think the exception
is cleaner, though.

Cheers
Ben