Fixing MonadCatchIO
6 views
Skip to first unread message
Leon Smith
Feb 8, 2012, 1:12:17 AM2/8/12
to snap
Ok, I'm updating my snap app to 0.7, and I noticed that the Handler monad has the same issues with MonadCatchIO bracket and finishWith as the Snap monad, which isn't that surprising to me.
Clearly, the problem is that bracket *should* be a typeclass method, and not forcing everybody to use the same definition based on catch. Although I really do think that everything should be a method, with the current definitions as the defaults. This should prevent any similar such complications.
As for instances, I would suggest using the current MonadControlIO-transformer instances minus the ErrorT and ContT instances.
However, one problem with adding more methods to a typeclass is that this can constrain implementations. So, for example, "local" should not be part of the MonadReader class, "fail" should not be part of the Monad class, etc. I would have no objection to "local" if it were in a separate typeclass.
So the question is, how many typeclasses should the control operators provided by MonadCatchIO-transformers be spread across? One? Two? More? How should they be partitioned?
On this count, I'm unsure. Carl Howell's has conjectured that the LogicT IO monad supports bracket but does not support catch. I haven't thought about that conjecture too deeply yet, though.
And, I'd like to take this kind of approach to MonadCatchIO and generalize postgresql-simple to arbitrary MonadIO/MonadCatchIO monads using it. And try to convince Michael Snoyman to provide Yesod instances (in terms of monad-control and lifted-base) for the classes.
Best,
Leon
Clearly, the problem is that bracket *should* be a typeclass method, and not forcing everybody to use the same definition based on catch. Although I really do think that everything should be a method, with the current definitions as the defaults. This should prevent any similar such complications.
As for instances, I would suggest using the current MonadControlIO-transformer instances minus the ErrorT and ContT instances.
However, one problem with adding more methods to a typeclass is that this can constrain implementations. So, for example, "local" should not be part of the MonadReader class, "fail" should not be part of the Monad class, etc. I would have no objection to "local" if it were in a separate typeclass.
So the question is, how many typeclasses should the control operators provided by MonadCatchIO-transformers be spread across? One? Two? More? How should they be partitioned?
On this count, I'm unsure. Carl Howell's has conjectured that the LogicT IO monad supports bracket but does not support catch. I haven't thought about that conjecture too deeply yet, though.
And, I'd like to take this kind of approach to MonadCatchIO and generalize postgresql-simple to arbitrary MonadIO/MonadCatchIO monads using it. And try to convince Michael Snoyman to provide Yesod instances (in terms of monad-control and lifted-base) for the classes.
Best,
Leon
Reply all
Reply to author
Forward
0 new messages