On 30/01/06, Daniel McAllansmith
On Tuesday 31 January 2006 16:32, Andrew Pimlott wrote:
On Tue, Jan 31, 2006 at 03:00:41PM +1300, Daniel wrote:
I've got some functions in MonadError with different Error types. I would like to map errors of one Error type onto the other Error type.
It seems that the only facility for doing this is mapErrorT, but that seems to force me to work in ErrorT rather than any old instance of MonadError.
What type would your mapError have? The first idea that comes to mind is
mapError :: (MonadError e1 m1, MonadError e2 m2) => (e1 -> e2) -> m1 a -> m2 a
The problem here is that m1 and m2 have no relation--m1 could be IO and m2 (Either e2)! Not surprisingly, we can't implement that.
Yeah, I expected that would be difficult. Is it actually impossible or does it just result in an explosion of code in the implementation, needing a clause to map each instance of MonadError to each other instance on MonadError? Not that I'm suggesting that solution, it's just that I'm new to this stuff and don't immediately see why it's impossible (as opposed to impractical).
Well, it that case mentioned, it would actually be impossible. If we have a function of type: (IOError -> IOError) -> IO a -> Either IOError a there will be a large problem with referential transparency. Barring unsafe hacks in the runtime system, you can't have such a thing.
So what relation do you want between m1 and m2? The only one I can think of is that m1 and m2 are ErrorT transforms of the same inner monad.
Yep. That's what I was thinking of.
In this case mapErrorT fits the bill, though it would probably be more convenient to define your own version that maps only the error:
mapErrorTE :: (e1 -> e2) -> ErrorT e1 m a -> ErrorT e2 m a
Ok, so mapErrorT, or a convenient wrapper, is the right tool for this situation?
If so, doesn't using mapErrorT bind the general MonadError class to the specific ErrorT instance? So, g :: (MonadError String m, MonadIO m) => Int -> m String would have to become g :: (MonadIO m) => Int -> ErrorT String (m String) and that change will propagate out through any function which calls g.
It feels bad to me to lose that generality. Is that just a hangover from other/weaker languages? Is it good advice for a new haskeller to stick to ErrorT in functions with errors?
Well, it may be possible to rig up something more general, but it's not quite so simple. Moving from IO to much of anything else will be tough. You can map between errors of the same type with mapError :: (MonadError e m) => (e -> e) -> (m a -> m a) mapError f x = catchError x (\e -> throwError (f e)) Having no additional information about the structure of m, it's impossible to map between errors of different types. If we had an extractError :: (MonadError e m) => m a -> Either e a, we could do the general mapError simply by extracting the error and rethrowing it in the other monad, (optionally performing some other computation if there's no error) but this function isn't generally implementable. It implies that there's some way to run the monadic computation and get a value. Then again, if you really wanted one, you could create a new typeclass for exactly that situation. - Cale