Haskell Pileシリーズの始まり
この記事では、
あなたに焦点を当て
ます 。 あなたは皆、Haskellの山の周りを回転し、贈り物を開くよう努めています。 最終的に、贈り物自体は開かれません。
誰かが最初の贈り物を開かなければなりません。
Haskellの束が外の世界と相互作用しない場合、ギフトを開く必要はありません。 したがって、IO機能のみがこれを行います。 関数がどの特定のギフトを開くかは必ずしも明らかではありません。 したがって、最も単純な
evaluateを見てみましょう。 あなたに尋ねる...
...ギフトを開くだけです。
プリミティブな値を取得した場合、それだけです。 ただし、ギフト券（コンストラクター）を入手できます。
ギフトを開けますか？ あなたの熱望にもかかわらず、答えはノーです。
evaluateは、1つのギフトのみを開くように求めます。 既に開いている場合は、何もする必要はありません。
ヒント：さらに計算したい場合は、あなたのために仕事をする精神でギフトを作成してください！ 多くの場合、遅延IO計算の評価の例として、 （length xs）を評価します。 しかし、あなたがまだこれを理解していなくても心配しないでください：私はまだ贈り物を作る方法を教えていません！
ギフトは1つしか開けませんが、多くのことが起こり得ます。 これについては以前の記事で書いた。 何らかのIO（副作用）が発生する可能性があります...
副作用により、計算の順序を確認できます。 結局のところ、通常の方法でプログラムを実行した場合、ギフトがいつ開くかはわかりません。 しかし、邪魔されたときに叫ぶように霊に頼めば、私たちはそれについて知るでしょう。 実際、これはまさに
Debug.Traceが行うことです！
コンピューティングがどのように進行しているかを知る方法は他にもあります。 ギフトは、採掘されると爆発する場合があります。 鉱山は「底」（論理的矛盾）とも呼ばれます。
おそらく、爆発は
未定義または
エラー「Foobar」によって引き起こされました。
ブーム。
実践的なアドバイスで終了します。 これまで見てきたように、IOで明示的に要求した場合にのみ、ギフトが開いていることを確認できます。 そうしないと、精神があなたを欺くかもしれません。 結局のところ、Haskellの束を直接
見ることはできないため、ギフトが開いているかどうかを直接確認する方法はありません。
サンクが計算されているかどうかわからない場合は、トレースを添付します。 香水が背中の後ろで怠けている場合、トレースは機能しません。
しかし、多くの場合、予想よりも遅くなりますが、まだトレースが表示されます（香水は怠け者ですが、いつかは仕事をするでしょう）。 スケジュールより早くプログラムを終了するか、完了した計算ステップを印刷すると便利です。
前回：
Haskellヒープでのコンピューティング次回：
PythonでHaskellヒープを実装する、v1発言。 前に言ったこととは反対に、理論的には、サンクがヒープ上でランダムな順序で実行されることを妨げるものはありません。 さらに、IOアクション自体をサンクにすることができます。これは、実際の「スイープ」なしでの値の転送（
IO a ）に対応します。 しかし、私はモナドのためにここにいないので、
IOアクションのギフトに注意を払うだけではありません-すべてがそこでも機能し、間接レベルが1つだけ追加されます。 最後に、無限ループも底と見なされますが、ギフトの開封が永遠に続く写真は爆発的なギフトほど刺激的ではありません。