4

継続をファーストクラスのオブジェクトとして公開することに対して平準化された批判のいくつかは何ですか？

ファーストクラスの継続があるのは良いことだと思います。これにより、命令の実行フローを完全に制御できます。上級プログラマーは、特定の種類の問題に対する直感的なソリューションを開発できます。たとえば、継続はWebサーバーの状態を管理するために使用されます。言語の実装は、継続に加えて有用な抽象化を提供できます。たとえば、グリーンスレッド。

これらすべてにもかかわらず、ファーストクラスの継続に反対する強い議論はありますか？

4

7 に答える 7

7

現実には、継続を使用できる便利な状況の多くは、throw / catch、return、C＃/Pythonのyieldなどの特殊な言語構造ですでにカバーされています。したがって、言語の実装者は、独自のソリューションに使用できる一般化された形式でそれらを提供するインセンティブをあまり持っていません。

一部の言語では、一般化された継続を効率的に実装するのは非常に困難です。スタックベースの言語（つまり、ほとんどの言語）は、基本的に、継続を作成するたびにスタック全体をコピーする必要があります。

これらの言語は、基本的なスタックベースのモデルを壊さない特定の継続のような機能を一般的な場合よりもはるかに効率的に実装できますが、一般化された継続を実装することはかなり難しく、価値がありません。

関数型言語は、いくつかの理由で継続を実装する可能性が高くなります。

  1. これらは継続渡しスタイルで実装されることがよくあります。つまり、「呼び出しスタック」はおそらくヒープに割り当てられたリンクリストです。これにより、現在のフレームをポップして新しいフレームをプッシュするときにスタックコンテキストを上書きする必要がないため、継続としてスタックへのポインタを渡すのは簡単です。（私はCPSを実装したことがありませんが、それは私の理解です。）
  2. これらは不変のデータバインディングを優先します。これにより、スタックが作成時に指していた変数の内容を変更しないため、古い継続がはるかに便利になります。

これらの理由により、継続はほとんど関数型言語の領域にとどまる可能性があります。

于 2009-12-03T01:01:10.187 に答える
4

まず、継続に関しては call/cc だけではありません。Mark Feely の論文から始めることをお勧めします: A better API for first class continuations

次に、制御演算子のシフトとリセットについて読むことをお勧めします。これは、連結を表す別の方法です。

于 2009-09-23T05:59:46.917 に答える
4

重要な異議は、実装コストです。ランタイムがスタックを使用する場合、ファーストクラスの継続には、ある時点でスタックのコピーが必要です。コピー コストは制御できますが (優れた戦略については、第 1 級継続が存在する場合の制御の表現を参照してください)、可変変数をスタックに割り当てることができないことも意味します。これは、関数型またはほぼ関数型 (Scheme など) の言語では問題になりませんが、OO 言語ではかなりのオーバーヘッドが追加されます。

于 2009-12-03T00:39:52.307 に答える
2
  1. ほとんどのプログラマーはそれらを理解していません。それらを使用するコードがある場合、それを使用できる代替プログラマーを見つけるのは困難です。
  2. 一部のプラットフォームでは、継続を実装するのは困難です。たとえば、JRubyは継続をサポートしていません。
于 2009-09-22T06:14:05.083 に答える
0

Call / ccは、高度な関数型プログラミングの「goto」です（ここでの例）。

于 2009-09-22T06:16:34.750 に答える
0

ruby 1.8 では実装が非常に遅かった。1.9 では改善されており、もちろんほとんどのスキームにはそれらが組み込まれており、最初からうまく機能しています。

于 2009-09-22T07:20:03.217 に答える