[Haskell-cafe] Re: Exception handling in numeric computations
xj2106 at columbia.edu
Tue Mar 24 18:56:32 EDT 2009
Jake McArthur <jake at pikewerks.com> writes:
> Xiao-Yong Jin wrote:
> | Then, why is 'div' not of type 'a -> a -> ArithExceptionMonad a' ?
> | Why does it throws this /ugly/ /error/ when it is applied to
> | 0? Why is it not using some beautiful
> | 'ArithExceptinoMonad'? Is 'Control.Exception' just pure
> | /ugly/ and doesn't make any sense?
> 'div' throws an error because dividing by zero is *programmer error*.
> *You* are supposed to make sure that you aren't dividing by zero.
> I differ from this decision in your case because, as you said, it is
> easier to check for the error condition in the function itself than to
> check it externally. This is fine, but because it's so hard to check
> externally, you have to tell the outside world whether there was an
> error or not. A functor/applicative/monad is the pure way to do this. An
> error is not.
> | Of course, 'scalarMult' is invulnerable and free of monad.
> | But take a look at the following functions,
> |> f1 = scalarMult 2 . invMat
> |> f2 l r = l `multMat` invMat r
> |> ff :: Matrix -> Matrix -> YetAnotherBiggerMonad Matrix
> |> ff x y = do let ff' = f1 x + f2 y
> |> put . (addMat ff') . f1 << get
> |> tell $ f2 ff'
> |> when (matrixWeDontLike (f1 ff') $
> |> throwError MatrixWeDontLike
> |> return $ scalarMult (1/2) ff'
> | Yes, I know, it's not really complicate to rewrite the above
> | code. But, what do I really gain from this rewrite?
> Code that is fully documented by its type, no harder to compose, more
> pure, and does what the programmer expects it to do.
Thanks for all the replies. Now I understand more about
Exceptions and Errors. I guess all I need is to compose a
larger monad, after all. I need to learn how to make
two different stacks of monad transformers cooperate
<\ * (__
More information about the Haskell-Cafe