On Sun, Mar 3, 2013 at 6:07 PM, Ertugrul Söylemez wrote:

Arie Peterson wrote:

...

Would anyone have a problem with a deprecation of MonadCatchIO-transformers, and a failure to update it to work with a base without 'block' and 'unblock'?

Yes. This is a simplified variant of a monad I use:

newtype Continue f m a = Continue (m (Maybe a, f (Continue f a)))

It's related to Cofree and has a valid and very straightforward MonadCatchIO instance. However, it's probably impossible to write a valid MonadTransControl/MonadBaseControl instance for it.

Perhaps there's a good reason why it's impossible to make such an instance. Are you sure that your MonadCatchIO instance is well founded? What happens if you use finally? Are you guaranteed that your cleanup function is called once, and precisely once? These are the problems I ran into with MonadCatchIO three years ago, almost precisely. The main monad for Yesod was built around ContT, and I ended up with double-free bugs. It's true that I had to move away from ContT in order to get the desired semantics, but that has nothing to do with MonadCatchIO vs monad-control. The former just made it seem like I had working code when in fact I had a lurking bug.

So I kindly ask you not to deprecate MonadCatchIO. The reason I'm hesitant about moving to monad-control is that it's hard to understand and also very difficult to define for CPS monads. It is commonly believed to be impossible.

Also I've seen at least one article about the incorrectness of monad-control. That's one further reason I like to avoid it.

I've seen the criticisms of monad-control (or at least I believe I have). What I've seen has been dubious at best. I'll fully agree that the implementation is hard to follow, but it's designed for efficiency. The underlying concept is simple: capture the current state and pipe it through the underlying monad. If you needed to lift a control operation for the ReaderT or StateT monads, you would likely end up with an almost exact replica of what monad-control does for you. Michael

On Mon, Mar 4, 2013 at 12:07 AM, Ertugrul Söylemez wrote:

Arie Peterson wrote:

...

Would anyone have a problem with a deprecation of MonadCatchIO-transformers, and a failure to update it to work with a base without 'block' and 'unblock'?

Yes. This is a simplified variant of a monad I use:

newtype Continue f m a = Continue (m (Maybe a, f (Continue f a)))

It's related to Cofree and has a valid and very straightforward MonadCatchIO instance. However, it's probably impossible to write a valid MonadTransControl/MonadBaseControl instance for it.

So I kindly ask you not to deprecate MonadCatchIO. The reason I'm hesitant about moving to monad-control is that it's hard to understand and also very difficult to define for CPS monads. It is commonly believed to be impossible.

You can always cast the continuation to a dynamic type and cast it back later. Doing so would typically require additional constraints, however if you're trying to make an instance for MonadTransControl that's unfortunately not possible (you'd need a Typeable constraint on the monad parameter, but it's not in scope). Lacking an appropriate MonadTransControlWithTypeable class, it's certainly possible to fall back to various low-level, highly-dubious constructs. Which I of course implemented without hesitation :grin

Also I've seen at least one article about the incorrectness of monad-control. That's one further reason I like to avoid it.

I'd appreciate a link if anyone could manage to find it. I haven't seen any criticisms of monad-control. John L.