On Thu, 29 Jan 1998, Ralf Hinze wrote:
> Matthias Fischmann writes ...
>
> > I am now trying to learn Haskell for half a week and I like it a lot.
> > But I still did not find out too much about exception handling. Is it
> > possible that there is no ml-like mechanism with `raise' and `handle'
> > built in? Yes, I know about types like
> >
> > data Result t = ERROR | Yes t
> >
> > and I also read the chapter in the report about IO, monads, and
> > userError. But this seems all a little clumsy compared to the elegant
> > and simple exceptions in standard ml or even ugly languages like java.
> >
> > Did I miss the point? Are there exceptions libraries? Is there any
> > extension to Haskell in some existent implementation that handles my
> > needs? How do you handle exceptions in your Haskell programs?
>
> No, there are no extensions for handling exceptions. Some may think
> that this is a bug but I think it's a feature ;-). First of all it's
> against Haskell's spirit of being a pure functional language. Consider
>
> raise First + raise Second handle First => 1 | Second => 2,
>
> what is the value of this expression? It clearly depends on the order
> of evaluation. SML defines this rigorously (right?). However, Haskell
> is a lazy language, so even if the language designers would undergo
> the task of defining the evaluation order, this is nothing which is
> easy for the user to understand.
Don't even more extreme problems with exceptions arise because of lazy io?
E.g., if a function produces a list of integers but can produce an
exception after calculating some of the first elements of the list (say
divide by zero or something), then if this function is used by a lazy
output function (say putStr),
then by the time the exception gets thrown all the elements already
produced will already have been sent to the screen and this can't be
rescinded.
E.g., using the hugs interpreter,
Prelude> putStr(show [1/2,2/3,4/0])
[0.5, 0.666667,
Program error: {primDivDouble 4.0 0.0}
(Imagine that program error was actually an exception that would be caught
somewhere else.)
In ML the strictness of the language means that this won't happen, and
because it's a functional language there's a guarantee that there are no
`program variables' being corrupted. I'd presume imperative languages like
C++ and java require much more careful, generalised exception planning. (I
don't use C++ exceptions in my programming :-) )
cheers, dave
-------------------------------------------------------------------------
email reply: [EMAIL PROTECTED] "Life is good for only two things,
http://www.cs.bris.ac.uk/~tweed/ discovering mathematics and teaching
work tel: (0117) 9545104 mathematics" -- Simeon Poisson
