Re: The case against call/cc

[Paul <paul.degrandis@gmail.com>]

Tacking on even more here - 

One of the major reasons this is 
becoming a hot topic is because of the work being done at Indiana (some 
of which is in the yield paper) and elsewhere.

It turns out, 
static simulation of dynamic delimited continuations gives you extreme 
flexibility and a lot of performance, as well as composibility.
call/cc
 doesn't offer much when compared against a smart CPS-transformation 
system and powerful delimited continuation control forms (for example, 
.NET's async programming model).

Dustin makes a solid point 
though - having stronger control abilities that are composable often 
yields more elegant solutions that involve fewer moving parts - 
something that fits idiomatically within a functional language like 
Clojure.  Additionally it paves the way for functional reactive 
programming.

Currently, a few of us on Clojure Dev are working on
 all of these pieces (delimited continuation control structures built 
upon smart CPS-transforms).

Paul

On Thursday, August 23, 2012 11:47:50 AM UTC-7, Ben Karel wrote:

On Thu, Aug 23, 2012 at 2:23 PM, Mark Dominus <mjd-phil...@plover.com> wrote:

> I thought that since we are all continuation junkies here, we might
> find this interesting:
> http://okmij.org/ftp/continuations/against-callcc.html
>
> The article argues that call/cc is a bad core feature for a language

For those who don't know Oleg's research, and who don't read the
article, take note that Oleg is not arguing against *continuations*,
but only against this particular language feature, the so-called
"undelimited" continuation capture. He has spent a lot of time and
work investigating a related but different feature, called "delimited"
continuations, which he sees as a major improvement:

        Despite sounding pretty much alike, undelimited and delimited
        continuations are qualitatively different. Since a delimited
        continuation is a mapping between contexts, it may truly be a
        function, which returns and can be composed. Undelimited
        continuations are not true functions. Undelimited and
        delimited continuations also differ in expressiveness, and
        this difference has been proven. First-class delimited
        continuations can express any expressible computational
        effect, including exceptions and mutable state. ... The
        limited expressiveness of undelimited continuations has been
        proven by Hayo Thielecke, see the reference and the abstract
        below.

        http://okmij.org/ftp/continuations/undelimited.html#delim-vs-undelim

Oleg's web site okmij.org is a trasure trove of fascinating reading,
and I recommend it for everyone.

Another bit of relevant reading is http://www.cs.indiana.edu/~sabry/papers/yield.pdf which observes that "mainstream" versions of yield (as in Ruby, Python, C#, etc) amount to restricted versions of delimited continuations. The paper Revisiting Coroutines likewise shows that Lua's coroutine system can encode one-shot delimited continuations.