Two demonstrations of this operational style that involve scheduling are Poor Man’s Concurrency Monad and a aTicTacToe implementation. See the project web site for more examples.

You can see my write-up on how it is used in sendfile here,

http://happstack.blogspot.com/2010/07/sendfile-071.html

I would love to hear what you have to say about it.

For sendfile, the library provides a ‘recursive’ function, but the user needs to be able to do some stuff between each recursion. The user of sendfile library cares about controlling when the function is resumed, and working with the intermediate values. But it does not want to know about the internals of the sendfile function or what data needs to be propogated from one call to the next. The Iter provides a great way of doing this. (And allows us to hide the fact that the data which needs to be propogated is platform dependent).

In happstack, it used so that users can provide functions which process the contents of multipart/form-data and impose quotas, and decide if a value should be stored in RAM or saved on the disk. And, it needs to be able to do it in ‘constant’ space. I have not documented this feature in detail yet but you can see the code here:

http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-server/src/Happstack/Server/HTTP/Multipart.hs

Search for InputIter.

In this case, the user provides the function that does the work, but the happstack library needs to do things in-between recursions. But the ‘private’ data which needs to be passed each recursion can be different for different functions. Once again the Iter allows those differences to be wrapped up and hidden. But this time it is so that the library code can avoid having to know the inner details and can work with them in a generic manner.

I still hope to apply the concepts to IxSet so that you can store the keys in RAM, the the values on disk. Haven’t looked at that in detail yet though.

thanks!
- jeremy

To clarify, the continuation-based writer is used internally as part of the corecursive queue transformer, but it cannot be used as an argument to the transformer.

It is believed to be impossible to define MonadFix on the standard continuation monad, but as far as I am aware, this is not definitively known. Levent Erkök wrote about this conjecture in his Ph.D. thesis Value Recursion in Monadic Computations, where he proves a theorem that seems to support the conjecture.

However, we now know that the statement of Erkök’s conjecture needs to be made more precise. For example, the codensity monad is a continuation monad that uses higher-ranked types to hide the type of the result. It appears in Edward Kmett’s category-extras and Mauro Jaskelioff’s Monatron library, and is the key to Janis Voigtländer’s paper. Interestingly, the codensity monad admits an instance for MonadFix, as demonstrated by Monatron but not category-extras. However, the codensity’s MonadFix does not appear to be well-behaved, as I don’t know of any interesting examples where it converges.

Also, I’ve heard Erkök’s conjecture informally stated as “there are no useful fixpoint operators on continuations”, which my paper “Lloyd Allison’s Corecursive Queues” throughly refutes. Not only did I demonstrate a fixpoint operator on the continuation monad, I also demonstrate a practical application where it’s use seems to be required!

If you are really interested in the studying the relationship of MonadFix, the continuation monad, and other continuation-like monads, you should probably take a look at “Recursion is a Computational Effect” by Dan Friedman and Amr Sabry. I don’t understand all the details, but they implement mfix on the continuation monad using unsafePerformIO, and use it to implement “LETREC + CALL/CC = SET!” in Haskell.

It seems likely that there is something here yet to be discovered. At the very least, there are explanations to be made and things to be definitively confirmed or refuted.

One can verify my claim above by installing Edward Kmett’s category-extras package, and applying his Codensity transformer to the original code. Also, I think I see what you tried to do with freshCod, however, your code produces a depth-first renumbering, not breadth-first as is desired.

It’s an interesting idea though; is it possible to somehow “layer” the monads on each other without resorting to transformers? Basically, instead of combining the effects of two monads, can you use one monad to structure the computation inside another monadic language while keeping them more-or-less separate?

type FreshCod n = Codensity (Fresh n)

runFreshCod :: Num n => FreshCod n a -> a
runFreshCod m = runFresh (runCodensity m return)

freshCod :: Num n => FreshCod n n
freshCod = Codensity fresh

lazyRenum :: Num n => Tree a b -> Tree n n
lazyRenum = runFreshCod . renumber
   where
     renumber (Leaf    _    )
        = do n <- freshCod
             return (Leaf n)
     renumber (Branch  _ l r)
        = do n <- freshCod
             l' <- renumber l
             r' <- renumber r
             return (Branch n l' r')

The two liftings are also mentioned in Monad Transformers and Modular Interpreters in Section 8.3, which includes a few other references to where each has appeared in the literature.