[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haskell
Subject:    Re: Exceptions, next round...
From:       Fergus Henderson <fjh () cs ! mu ! OZ ! AU>
Date:       1998-06-15 8:36:27
Message-ID: 19980615122813.32419 () mundook ! cs ! mu ! OZ ! AU
[Download RAW message or body]

On 12-Jun-1998, Hans Aberg <haberg@matematik.su.se> wrote:
> At 02:47 +1000 98/06/13, Fergus Henderson wrote:
> >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.
> 
>   So Fergus is right, these should be different types, but I figure it will
> be too difficult for a PL to classify all uses of say a "divide-by-zero"
> into legal types: For example, the use of 1/0 in a higher dimensional
> projective type is rather different from the one Fergus suggests in
> dimension 1; so one could probably not use that type for describing higher
> dimensional projective types.
> 
>   So it seems difficult to foresee what interpretation different types of
> exceptions might have when constructing new types: It is better attempting
> to classify these exceptions so that users can build the new types they
> need, rather than trying to build off-the-rack one-size-fits-all types.

I agree that in the general case, users may want to build their own types to
model their own needs.  However, I think it makes sense for the language
or standard library to provide types that meet the most common needs.
Types such as `Float', `Float_or_Inf', and `Float_or_Inf_or_NaN' meet
needs that are common enough that I think they warrant inclusion in the
standard library.

Also, I think it is important for provide types that match the basic
capabilities of real machines, at least in cases where is unlikely that
the implementation will be able to optimize a user-provided
implementation to be as efficient as one provided directly by the
implementation could be.  Since machines have hardware support for
types like `Float_or_Inf_or_NaN', I think it makes sense to include
them.  Implementing `Float_or_Inf_or_NaN' in terms of `Float' by
catching exceptions would most likely be very inefficient.
On the other hand, the default float type should probably support only
finite floats, not infinities or NaNs, so it would not be enough
to provide just `Float_or_Inf_or_NaN'.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.



[prev in list] [next in list] [prev in thread] [next in thread]