この回答に示されているように、seq結合された withundefinedは、等式推論に関して非常に奇妙なことを行います。たとえば、モナドが失敗する可能性があります。別の例がこの質問にあります。
最近、私はそれが同様のことをすることに出くわしました.WHNFへの引数を評価しますが、アクションが評価されるevaluate :: a -> IO aときだけです。これは、「すべてを行うことができるIO」と予想されるため、はるかに安全であるように思われます。IOもちろん、どこでも使用できるわけではありませんが、多くの場合、式を評価する必要性は何らかのIO操作に関連しています (たとえば、s を操作するときに消費スレッドではなく生成スレッドに計算を評価させるなどMVar)。
そこでお聞きしたいのですが、安全性はどのくらいですevaluateか? IOコードに関する推論を破る例を作成することは可能ですか (もちろん含まれます) seq。seqまたは、 （特定のプログラムで可能な場合）の安全な代替品と見なすことはできますか？
いいえ、コマンドによって引き起こされる同じ問題が発生します。seqの最初の引数で使用されるモナドevaluateは、モナドルールが破られます。エルテスの答えのルールに基づいて：
クライスリ圏では、モナドは
returnアイデンティティの射であり、(<=<)構成です。したがって、次returnのIDである必要があります(<=<)：return <=< x = x
return <=< xこれは、プログラムの動作を変更せずにx、任意の有効なモナドに置き換えることができるはずであることを意味します。
関数でそれを使用してevaluate...
evaluate (return <=< undefined :: a -> Identity b) >> putStrLn "hello"
helloを出力します。：に置き換えることにより、同等のステートメントであるはずのものを使用return <=< undefinedしundefinedます。
evaluate (undefined :: a -> Identity b) >> putStrLn "hello"
代わりにPrelude.undefined例外が発生します。
これは、evaluate関数でのみ発生します。returnとまったく同じ型アノテーションがあることに注意してくださいevaluate。上記のコマンドでに置き換えるevaluateとreturn、両方のコマンドの結果のアクションは同じになります（出力されますhello）。