6

厳密な評価が行われている環境では実行できない、遅延評価された言語で実行された賢いことの例がたくさんあるようです。たとえば、Haskell の無限リストや、ツリー内のすべての要素を 1 回のパスでツリーの最小値に置き換えます。

遅延評価された言語では簡単に実行できない、厳密に評価された言語で実行された賢いことの例はありますか?

4

9 に答える 9

8

怠惰な言語ではなく熱心な (厳格な) 言語で簡単にできる主なこと:

  • プログラムの時間とスペースのコストをソース コードから予測する

  • 変更可能な配列の一定時間の更新などの副作用を許可します。これにより、一部のアルゴリズムの高速な実装が容易になります

私の意見では、熱心な言語の主な利点は、コードを思いどおりに実行するのがはるかに簡単であり、コードの小さな変更がパフォーマンスの大幅な変更につながるパフォーマンス トラップがほとんどないことです。

そうは言っても、私は全体的に Haskell で複雑なことを書くことを好みます。

于 2009-03-20T00:34:48.787 に答える
5

いいえ; 厳密な評価では実行できないが、遅延評価 (別名、通常の順序の削減、または左端の削減) では実行できることがいくつかありますが、その逆はできません。

この理由は、遅延評価が何らかの意味で「最も一般的な」評価方法であり、次のように知られているためです。

計算妥当性定理:ある順序の評価が終了して特定の結果が生成される場合、遅延評価も終了して同じ結果が生成されます。

* (ここではチューリング等価性について話しているのではないことに注意してください)

于 2009-03-17T06:14:23.440 に答える
4

いいえ、多かれ少なかれ定義上です。遅延評価言語では、必要になるまでの評価の遅延、ストレージへの影響などを除いて、定義上、活発な (人々は本当に「厳密」を使用していますか?) 評価で得られるのと同じ結果が得られるはずです。したがって、それ以外の別の動作が得られる場合、それはバグです。

于 2009-03-16T17:38:43.820 に答える
1

「Hello, World」プログラム、または基本的に副作用に関連するすべてのものが頭に浮かびます。

厳密な評価では、評価の順序、したがって通常は副作用で重要な副作用の順序について明確な概要があるため、式を評価すると簡単に副作用が生じる可能性があります。これが厳密な評価の基本的な利点であり、ほとんどの言語がそれを備えている理由でもあります。また、C のようなパフォーマンス指向の言語でさえ、値渡しモデルを使用することが多いのはなぜですか。

どちらも同じことができますが、人間の難易度が異なるだけで、厳密な言語で無限リストを完全にシミュレートでき、非厳密な言語で副作用のすべての効果をシミュレートできます。

于 2010-06-09T03:33:55.603 に答える
0

私は Erlang で少しプログラミングしていますが、大学で学んだ遅延評価の欠如にかなりイライラしています。

プロジェクトのオイラー問題のいくつか、特に素数を扱う問題について簡単に調べてきました。

遅延評価を使用すると、すべての素数のリストを返す関数を作成できますが、実際には必要なものだけが返されます。したがって、「最初のn 個の素数をください」と言うのはとても簡単です。

遅延評価を行わないと、「1 からnまでのすべての素数のリストを教えてください」という、より制約の多い結果になる傾向があります。

于 2009-03-17T00:40:05.333 に答える
0

C# などの厳密な評価言語では、値自体ではなく、値 (Func) にサンクを返すことで、遅延評価を実現できます。C# での Y-Combinator の構築の例として、次の方法で行うことができます。

public Func<int, int> Y(Func<Func<int, int>, Func<int, int>> f)
{
    return x => f(Y(f))(x);
}

この宣言は、怠惰な環境ではより簡潔になります。

Y f = f (Y f)
于 2009-03-16T17:46:15.937 に答える
0

Charlie Martin が書いたように、厳密なプログラムと遅延プログラムの結果は同等でなければなりません。違いは、時間と空間の制約および/または言語表現力にあります。不要な値に対する遅延のパフォーマンスへの影響に加えて、遅延言語では、追加の言語概念 (LISP のマクロなど) なしで新しい言語構造を簡単に導入できます。とにかく、怠惰はあなたを噛むことができます Haskell の末尾再帰はどのように機能しますか? 同じ考え方は、厳密な言語よりも複雑になる可能性があります。(haskell コンパイラは、compute+1が make thunk よりも安価であることを認識するべきではありません( x + 1 )か?)

于 2009-03-16T18:40:59.130 に答える
-5

残念ながら、最高の回答と評価された回答は、論理エラーに悩まされています。定理から、Porges は、怠惰な言語でもっと多くのことができるということには従いません。

反対の証拠は、怠惰な言語のすべてのプログラムが厳密な言語で同等のものにコンパイルされるか (さらにアセンブラー プログラムにコンパイルされる)、厳密な言語で書かれたインタープリターによって実行されることです (そうです、インタープリターは究極的にはアセンブラー プログラムです)。

于 2009-04-08T08:33:32.560 に答える