Alex Jacobson:
> In the backchannel, Alastair Reid and Adrian Hey, have convinced me
> that the return values of functions and cannot be represented using
> algebraic types.
I'm not clear what you mean by this.
> I am not sure of syntax, but I am describing something like:
> > fun:: a->b->c :: MYException a b c
> > fun x y = if x/= then numerator/denominator else throw SomeException x
> > where numerator = x
> > denominator = y
> > catch DivisionByZero=throw OtherException y
Trouble is, implicit propagation of thrown exceptions in this sort of
way ends up being non-referentially-transparent. So I don't think
you'll find the Haskell committee rushing to embrace this solution
(or if they do, they might have to poison the current Chairman, amongst
others).
I think you can adequately simulate exception handling of this sort in
Standard Haskell, by using say the Either type (as Ralf Hinze suggests),
which if you test for exceptions explicitly leads to something like:
> fun:: Either a MyException -> Either b MyException -> Either c MyException
> fun (Right numerator) (Right denominator)
> = if denominator /= 0
> then Right (numerator/denominator)
> else Left DivisionByZero
> fun (Left err1) y
> = Left err1
> fun x (Left err2)
> = Left err2
Using error-monad syntax might be a bit more palatable, but amounts to
essentially the same thing. Alternatively, you can define HOFs to
"lift" an n-ary function to an exception-propagating equivalent:
propagate2 :: a -> b -> c -> (Either a d -> Either b d -> Either c d)
Hope that helps...
Slainte,
Alex.
