On 12-Jun-1998, Jerzy Karczmarczuk <[EMAIL PROTECTED]> wrote:
> 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.
Well, to extend my idea a bit further: for floating point, you could
easily have two different floating point types, one for ordinary
numbers, and one which can hold either ordinary numbers or infinities.
For the former, operations whose result would be infinite raise
exceptions, but for the latter, they don't. In fact, you could have
three different types, the third being one that allows all the IEEE
values, including NaNs. Then the programmer can choose which type is
appropriate to use for his or her application. The Haskell type class
mechanism and "default" declarations should make this quite convenient,
I think.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
