views:

282

answers:

2

Can anybody explain why exceptions may be thrown outside the IO monad, but may only be caught inside it?

+8  A: 

Because exceptions can break referential transparency.

You're probably talking about exceptions that are actually direct results of the input. For example:

head [] = error "oh no!" -- this type of exception
head (x:xs) = x

If you are lamenting not being able to catch errors like this then I assert to you that the functions shouldn't be relying on error or any other exceptions but should instead use a proper return type (Maybe, Either, or perhaps MonadError). This forces you to deal with the exceptional condition in a more explicit manner.

Unlike the above (and what causes the issue behind your question), exceptions can be from signals such as out of memory conditions that are completely independent of the value being computed. This is clearly not a pure concept and must live in IO.

TomMD
Can you give an example of breaking referential transparency in this way?
Roman Cheplyaka
So you want to tell me, that excpetions are not the way to think functionally, so I should generally try to avoid them? Great!
FUZxxl
Roman: What I ment was that if you could catch exceptions in pure code and base your result on those exceptions, such an action would break referential transparency.
TomMD
Ah I see. It's maybe also a problem, that your code can just escape from the founction where it's defined, which may also break referential transparency.
FUZxxl
TomMD: I see perfectly what you meant, I just wanted to see a concrete example of breaking RT. Anyway, I came up with my own and expanded my answer...
Roman Cheplyaka
+11  A: 

One of the reasons is the denotational semantics of Haskell.

One of the neat properties of (pure) Haskell functions is their monotonicity -- more defined argument yields more defined value. This property is very important e.g. to reason about recursive functions (read the article to understand why).

Denotation of exception by definition is the bottom, _|_, the least element in poset corresponding to the given type. Thus, to satisfy monotonicity requirement, the following inequality needs to hold for any denotation f of Haskell function:

f(_|_) <= f(X)

Now, if we could catch exceptions, we could break this inequality by "recognizing" the bottom (catching the exception) and returning more defined value:

f x = case catch (seq x True) (\exception -> False) of
        True -> -- there was no exception
            undefined
        False -> -- there was an exception, return defined value
            42

Here's complete working demonstration (requires base-4 Control.Exception):

import Prelude hiding (catch)
import System.IO.Unsafe (unsafePerformIO)
import qualified Control.Exception as E

catch :: a -> (E.SomeException -> a) -> a
catch x h = unsafePerformIO $ E.catch (return $! x) (return . h)

f x = case catch (seq x True) (\exception -> False) of
        True -> -- there was no exception
            undefined
        False -> -- there was an exception, return defined value
            42

Another reason, as TomMD noted, is breaking referential transparency. You could replace equal things with equal and get another answer. (Equal in denotational sense, i.e. they denote the same value, not in == sense.)

How would we do this? Consider the following expression:

let x = x in x

This is a non-terminating recursion, so it never returns us any information and thus is denoted also by _|_. If we were able to catch exceptions, we could write function f such as

f undefined = 0
f (let x = x in x) = _|_

(The latter is always true for strict functions, because Haskell provides no means to detect non-terminating computation -- and cannot in principle, because of the Halting problem.)

Roman Cheplyaka
Okay. This seems to be one of the difficult mathematical backrounds behind haskell. Thank you for your brief description.
FUZxxl