mapException

[Simon Peyton-Jones]

There's no good reason that mapException isn't there.  Would someone
like to add it to Control.Exception, and document it? =20

Something like
	mapException f v =3D unsafePerformIO (catch (evaluate v) (\x ->
throwIO (f x)))
The unsafePerformIO is, of course, safe in this case.

Simon

| -----Original Message-----
| From: Lauri Alanko [mailto:la@iki.fi]
| Sent: 16 November 2002 09:18
| To: libraries@haskell.org
| Subject: mapException
|=20
| On Mon, Nov 04, 2002 at 01:00:39PM -0000, Simon Marlow wrote:
| > and the awkward squad paper will have to be updated to comply
(although
| > we just noticed it is already wrong about the behaviour of
| > Prelude.catch).
|=20
| This reminds me: in the paper "A semantics for imprecise exceptions" a
| primitive "mapException" is introduced:
|=20
| mapException :: (Exception -> Exception) -> a -> a
|=20
| However, I don't think GHC's exception library has ever had this. Is
| this just a lapse, or is there some fundamental problem with a non-IO
| mapException? The paper says that "its usefulness and desirability
might
| be debatable", but to me this seems very useful. Eg. in Java this is a
| common idiom:
|=20
| try {
| 	aux.library.Thing.doSomething();
| } catch (aux.library.ThingException e) {
| 	throw new MyException(e.getProblem());
| }
|=20
| That is, one module uses another module internally to do a task, but
of
| course wishes to hide any implementation details from the caller.
| Therefore we don't want to show the auxiliary library's exception
| interface to the caller, but convert exceptions to match the publicly
| defined exception interface.
|=20
| It'd be very inconvenient if doing this in Haskell would require
making
| a formerly pure function use the IO monad.
|=20
|=20
| Lauri Alanko
| la@iki.fi
|=20
| _______________________________________________
| Libraries mailing list
| Libraries@haskell.org
| http://www.haskell.org/mailman/listinfo/libraries