21 Aug 08:55 2013
Re: [scala-user] Re: Scala compiler crash
Jason Zaugg <jzaugg@...>
2013-08-21 06:55:39 GMT
2013-08-21 06:55:39 GMT
On Wed, Aug 21, 2013 at 5:07 AM, Ian Clarke <ian.clarke <at> gmail.com> wrote:--
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 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 continuations.While portable continuations might seem to be an esoteric feature, in actuality they are extremely relevant to many of the real-world challenges that programmers face today, in particular the problem of building scalable 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 on a single CPU. The existence of the continuations plugin was what convinced me to base our project on Scala.Typically, useful functionality is only deprecated in an API when there is a better alternative. Deprecating the continuations plugin in favor of an unspecified Futures-based system may seriously screw quite a few people who made quite early bets on Scala. I hope you take that into consideration in 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) bugs (I'd wager that there are as many more again undiscovered or unreported), and the way that workarounds for the plugin have leaked into the regular compiler (typer and pattern matcher in particular.) For example, failing to account for the fact that `T <at> 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 them!)
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 "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.