On Wed, Aug 21, 2013 at 5:07 AM, Ian Clarke
> On Tuesday, August 20, 2013 5:09:16 PM UTC-5, Jason Zaugg wrote:
>> First of all, a heads up regarding CPS: We don't have resources assigned
>> for maintenance of the CPS compiler plugin. In fact, we're thinking of
>> declaring it deprecated. It has some architectural issues (most notably:
>> intimate relationship with typechecking under the annotation-driven
>> pluggable subtyping logic) that means it has a long tail of hard- or
>> impossible-to-fix bugs and limitations.
> I would plead that this plugin not be deprecated if at all possible, our
> project <http://swarmframework.org/> is
entirely dependant on it, and I
> think Greg's is too. Moreover, there are very few programming languages
> that support continuations, and even fewer that support portable
> While portable continuations might seem to be an esoteric feature, in
> actuality they are extremely relevant to many of the real-world
> that programmers face today, in particular the problem of building
> distributed and fault tolerant software. In my humble opinion, portable
> continuations are our best chance of achieving the holy grail of allowing
> software to be written that can be scaled across tens, hundreds, or maybe
> even thousands of computers - just as easily as writing software to run
> a single CPU. The existence of the continuations plugin was what
> me to base our project on Scala.
> Typically, useful functionality is only deprecated in an API when there
> a better alternative. Deprecating the continuations plugin in favor of
> unspecified Futures-based system may seriously screw quite a few people
> made quite early bets on Scala. I hope you take that into consideration
> your decision to deprecate it.
[moving to scala-internals]
I would argue that while continuations are a great feature, the
implementation in Scala isn't suitable for building production systems. We
know of folks that have tried this at a large scales and are now keen to
migrate to async.
BTW, this isn't meant in any way as a slight on the implementation of
original CPS plugin. The problems arise when trying to comprehensively
integrate it into the rest of the compiler. Even if you can live with
domain-unspecific type errors that your API users will encounter, you ought
to be worried about the unsolved (and unsolvable)
wager that there are as many more again undiscovered or unreported), and
the way that workarounds for the plugin have
compiler (typer and pattern matcher in particular.) For
example, failing to account for the fact that `T @cps` is not a subtype of
`Any` is an easy way for the compiler to break CPS (well, in theory any
AnnotationChecker based compiler plugin; but there are very, very few of
With all of this in mind, we have to find a way to communicate our view of
CPS to potential new users (we'd rather that *more* projects didn't start
depending on it) while providing some sort of migration path for your
projects. The plugin could be maintained by a third party, for example,
we're not planning to remove the extension points from the compiler. Or
maybe we can suggest ways that you could use macros as your user API like
async and effectful .
I'll also ask Adriaan to chime in. I don't want to push this discussion too
much as I helped to develop scala-async so I might be biased.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.