Comments on: Continuing with continuations

By: C.K.

C.K. — Mon, 23 Jul 2007 14:51:21 +0000

And if all you want is to jump out of the current chain of (>>=), then you don’t need all the complexity of continuations.

For example: In playing with the DNA to RNA procedure from the ICFP2007 spec, there is a need to break out of the code to the end of the iteration.

I used a “MaybeT” as the simplest solution [1]. Thus I could run (forever $ oneIter) and it would break out as needed by using the fail _ == mzero == Nothing command.

If you need to pass out a result instead of a plain Nothing, then using ErrorT from Control.Monad.Error [2] which is actually ‘Either’ so (Left foo) is more informative than Nothing.

[1] http://haskell.org/haskellwiki/New_monads/MaybeT
[2] http://www.haskell.org/ghc/docs/latest/html/libraries/mtl/Control-Monad-Error.html

By: Magnus

Magnus — Sat, 21 Jul 2007 22:21:45 +0000

dolio, thanks for the comment. I did miss Cale's comment about breaking out of forever.

You've also prompted me to look at Reader, it's one of the many monads I haven't looked closer at.

By: gerel

gerel — Fri, 06 Jul 2007 02:21:16 +0000

CPS is a much simpler concept than Haskell Monads a la Wikibooks:

http://en.wikibooks.org/wiki/Haskell/Understanding_monads

The analogy between nuclear waste (t) robots (>>=) and containers (M t) sucks a lot. If you come with some Lisp background and read that wikibook, your head collapses, seriously.

I know this is kinda off-topic here but needed to say it.

By: dolio

dolio — Fri, 06 Jul 2007 01:29:46 +0000

Not to disparage your efforts, but your code strikes me as rather weird. What you're essentially doing is, I think, at the end of each function, taking the continuation, and sticking something right before it (although that thing may in turn stick something right before it as well). That seems like no more than writing mutually recursive functions, only in a more verbose manner.

The real neat thing about continuations, in my opinion, is that you can use 'forever', but still give the functions inside the loop the chance to break out (which I seem to recall Cale mentioning yesterday, but maybe it got lost in the shuffle). For example:

foreverK fm = callCC (\k -> forever (fm k))

getCharCC break = do c <- liftIO getChar
                     when (c == 'q') $ break ()
                     return c

putCharCC break c = do liftIO $ putChar c
                       when (c == 'x') $ break ()

getCharCC' break = do c <- liftIO getChar
                      when (c == 'q') $ break ()
                      putCharCC' break c

putCharCC' break c = do liftIO $ putChar c
                        when (c == 'x') $ break ()
                        getCharCC' break

test1 = foreverK (\k -> getCharCC k >>= putCharCC k)

test2 = callCC getCharCC'

So, there are two versions; one uses forever and the other just has mutually recursive functions. They'd both loop forever, except that we call 'callCC' outside of the infinite loop, and pass it in (as break), so that when one of the functions detects the exiting condition, it can return to the continuation of (essentially) the infinite loop itself, and terminate.

You can also use the reader transformer to make things a bit less noisy:

foreverK' m = callCC $ runReaderT (forever m)

getCharCC'' = do c <- liftIO getChar
                 when (c == 'q') breakCC
                 return c

putCharCC'' c = do liftIO $ putChar c
                   when (c == 'x') breakCC

breakCC = ask >>= \k -> lift $ k ()

test3 = foreverK' (getCharCC'' >>= putCharCC'')