Fergus Henderson:
> >Infinities are probably best treated as a seperate issue.
> >That is, infinities should not correspond to exceptions.
> >If you have a type which supports infinities, then 1/0 should return
> >infinity, not raise an exception.
Hans Aberg responds:
> I think it is best to let 1/0 throw an exception "divide-by-zero" -- then
> this can be used to build types that support infinities (like projective
> spaces).
I am afraid that this discussion is becoming too distant from Haskell or
from functional programming in general. "Errors" and other "real programming"
topic have no universal solutions. From the perspective of a physicist who
constructs an enormous application which runs a Monte-Carlo process during
20 hours,:
a. The code should be as short as possible. Inserting specific code which
treats infinities in many places is not a good idea.
b. The infinities (and NaNs) *should* bomb, and never propagate.
So, I agree with Hans Aberg that in such a case an exception is an exception,
and not a value to be processed by the (standard) user code.
But when I teach programming, I demand from students that they protect their
applications from exceptions. They become "almost" normal values, or conti-
nuations. So, I believe that we are discussing ideology.
Jerzy Karczmarczuk
Caen, France.
