On 28-Sep-1999, George Russell <[EMAIL PROTECTED]> wrote:
> I must be missing something. Isn't it blindlingly obvious that
> here SML's exception mechanism is streets ahead of Haskell's? Please,
> what am I missing? Is there some lurking type-unsafeness?
SML's exception mechanism essentially forces sequential execution,
and (I think) causes problems for equational reasoning.
Haskell's exception mechanism preserves referential transparency
and gives the compiler more freedom to reorder and/or parallelize code.
> [snip]
> > (a) allow throwing exceptions from arbitrary code, not just from within
> > the IO monad
>
> Aaarrgh no. If you're going to do unsafe operations then be honest about it
> and use IOExts.unsafePerformIO.
Throwing an exception from arbitrary code is no less safe than calling `error'
or executing a case for which no pattern matches.
Allowing exceptions to be thrown from arbitrary code does not violate
referential transparency. See the paper that Alastair Reid cited.
> Actually I don't often feel the need to do
> this (I don't think there's any example in UniForM). Exceptions tend to be
> either because of something IOish (file not found), in which case you are already
> doing state, or else because of a bug in the program, in which case "error"
> is probably appropriate.
There are many common examples where exceptions arise for reasons other
than I/O, for example integer overflow, division by zero, taking the
square root of a negative number, head of an empty list, and so forth.
If we want to be able to write robust programs, then we need to be able
to recover from such errors. Likewise, if we want to be able to write
efficient programs, then we need to be able to recover from such
errors, because often it is more efficient and/or easier to make the
common case fast and to deal with the rare cases via an exception
handler than to write code which avoids such raising such
errors/exceptions in the first place.
> I suppose the main problem with "error" is that theoretically
> you have to crash out of all enclosing Haskell code. I don't understand
> enough about the semantics of haskell to know the answer to this question,
> but could you provide a way of wrapping up a value
> a -> Maybe a
> so that if somewhere during the evaluation of the a, there is an attempt to
> evaluate "error", the result is Nothing (and perhaps an error
> message printed on the screen), otherwise Just (something).
> Would this break the semantics?
Unfortunately yes. The possibility of infinite loops causes trouble here.
For the details, which are rather subtle, see the paper.
But a function of type `a -> IO (Maybe a)' need not suffer from the
same problem. You can safely throw exceptions from anywhere, so long
as you only catch them from code in the IO Monad.
--
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.
