「限定継続使ったコードで、コンパイラがcrashする」というscala-usersのMLのスレにて、Scala開発者のJason Zauggさんが
https://groups.google.com/d/msg/scala-user/hIHVOpV9uSw/EqvldplVoWIJ
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.
Our vision is to provide a more focussed version of CPS as scala-async, which is implemented with def-macros. It provides a DSL for working with Futures (or other Future-like APIs). Admittedly, this is far less general, but that does have the benefit of eliminating the cryptic type errors which folks often to hit with @cps.
訳
- 私達は*1scala-async(マクロで実装されている)を提供 https://github.com/scala/async
- それはFutureに関するDSLを提供する
- たしかに、scala-asyncは限定継続にくらべて汎用的ではないが、@cpsアノテーションによるわかりづらい型エラーを排除できる利点がある。
以下、個人的感想
まだ決定事項ではないので、なんともいえませんね。しかし、scala-asyncはそういう狙いも最初からあったんですかね。たしかに単なるマクロ(しかもFuture関連限定)のほうが、コンパイラプラグイン(限定継続というとても汎用的な機能)に比べたらメンテナンスは簡単そうです。
しかし、scala-asyncのようなもの以外にも、限定継続の使い道は大量にあるわけで、scala-asyncが限定継続の"代替"というにはあまりにも貧弱というか、代替になりえるわけがないですが・・・。まぁしかし、構造的にそもそも色々難しく、メンテナンス難しいなら、限定継続がなくなるのも仕方ないかなぁ・・・という気もします。
追記:
Scala-Internal の ML での議論の続き https://groups.google.com/d/topic/scala-internals/9Ts3GLsXuOg/discussion
*1:限定継続の代わりに