Haskells の遅延メソッドの長所と短所をさらに探しています
プロ
- 無限のデータ構造の可能性 (例: fibs の 5 [1..] を取る)
- より高いパフォーマンス: 必要以上のことをしないでください (例: head (map (2 *) [1 .. 10]) 最初の 2 だけを計算します)
コントラ
- 厳しい命令があるからこそ、もっと上達します
- Debuggenもより難しくなります
- 必要なメモリ量と速度の予測も難しくなります
敬具
1 に答える
4
まず第一に、遅延評価は Haskell で発明されたものではありません。そのように考えるのは正しくありません。
第二に、Haskell には熱心な評価 (反対に、参照されたときに評価する) の可能性もあります。
第三に、遅延評価機能は他の言語やテクノロジーでも簡単に利用できます。Python のジェネレーター (xrange関数を思い出してください)、C++ でのマイヤーズ シングルトンとテンプレートのインスタンス化、実行時リンカーでのシンボル解決の遅延など、すべてこのアイデアの例です。
いずれにせよ、その考えとそれに対応する語彙に対応することは、ソフトウェア エンジニアにとって決して有害ではありません。
長所と短所については、主要なものに名前を付けました。さらにいくつか名前を付けることができます (データ構造と関数呼び出しを使用して、事実上すべての言語でこれらを実行できることを思い出してください)。
再帰的データ構造。たとえば、要素が円形に配置されたリスト値を作成できます。先頭
nextは「最後の」要素の要素です。このようなリストをトラバースすると、無限に繰り返される一連の要素が生成されます。おそらく最もやる気を起こさせる例ではありませんが、ツリーやグラフなどでも同じことができます。組み込みプリミティブの代わりに遅延データ構造を使用して制御フローを調整する。遅延リストだけでコルーチンを構築することを考えてみてください。これは実際には、より複雑で複雑な評価順序のコインの反対側です (つまり、コントラの 1 つが利点です)。
計算の半自動並列化。これは、遅延評価よりも参照透過性の利点です。それでも、機能は非常に有機的に融合しています。
パフォーマンスに関しては、遅延評価について考えるとき、メモ化がよく思い浮かびます。それを自動的に行うのは難しい (おそらくまだ解決されていない) 問題であり、多くの詳細と落とし穴があります。
したがって、基本的に、より深く見ると、すべての側面に可能性とトレードオフが伴います。ソフトウェア エンジニアとしてのあなたの仕事は、これらすべてを知り、具体的な問題の詳細に基づいて賢明に選択することです。
于 2012-12-27T17:38:27.000 に答える