On Thu, Aug 25, 2011 at 3:46 AM, John Lato wrote:

...

Message: 17 Date: Wed, 24 Aug 2011 17:02:49 +0300 From: Michael Snoyman Subject: [Haskell-cafe] Lifting an enumerator To: Haskell Cafe Cc: John Millikin Message-ID:         Content-Type: text/plain; charset=ISO-8859-1

Hi all,

Max asked earlier[1] how to create a new instance of a class in Persistent using a monad transformer. Without getting into the specific details of persistent, I wanted to pose a question based on a much more general question: how can we lift the inner monad of an enumerator? We can easily do so for an Iteratee[2], but there is nothing to allow it for an Enumerator.

At first glance, this problem looks very similar to the shortcomings of MonadIO when dealing with callbacks. In that case, you cannot use liftIO on a function that takes an `IO a` as a parameter. A solution to this issue is monad-control[3], which can be used to allow exception catching, memory allocation, etc.

So I'm wondering: can we come up with a similar solution to this issue with enumerators? I have a working solution for the specific case of the ErrorT monad[4], but it would be great to be able to generalize it. Bonus points if we could express this in terms of the typeclasses already provided by monad-control.

Based upon a similar problem I worked on in the past, I suspect this isn't possible in the general case, at least not safely.  That is, any implementation (presuming it's possible at all) would violate the resource guarantees enumerators typically provide (an inner MonadCont is able to do this).

Unfortunately I don't have a proof, so I'm open to counter-examples ;-)

John L.

I'm not going for a general case, in the sense of every monad transformer. I think this is the same concept as monad-control/monad-peel/etc, where some transformers are capable of encoding their state within another monad. ErrorT is the simplest example, where you can just turn the value from a to Either e a. While I doubt we could use this with the ContT monad, I would imagine it's possible for ErrorT, ReaderT, WriterT, and StateT at the very least. Ideally, it would be expressed in terms of an existing typeclass. Michael