遅延評価でデバッグが困難になる状況
先日、Haskell 界隈で遅延評価によってデバッグがし辛いのはどんな時かと言う話があった。見た感じ、遅延評価によってデバッグのしにくさはそんなに変わらないと言う意見が結構あり、個人的には衝撃だった。僕自身は遅延評価にだいぶヘイトを溜めてる人なので、どういう状況でデフォルト遅延評価が嫌かを実感できる問題を作った。この問題を解けば、きっとヘイトを共有できるはずってわけ。一緒に地獄に落ちような。 なお、かなり主観に寄っていて、結構書き殴ってる部分が多いので、厳密な議論をするにはあまり良い例ではないかもしれない。個人的には、備忘録的な意味合いも強くて、今まで詰まったやつをまとめておくかみたいな感じでもある。 先に結論を書いておくと、 プログラム自体が大きくて [1] 複雑な制御構造をしていて (optional) 以下のいずれかの条件を満たす 遅延評価を機能として使っている デバッグ対象が効率に
GHC IO モナドの中身
Haskell の IO モナドって，中身どうなってたんだろと気になってて，ちょっと調べてみた．そのメモ． IO モナドと RealWorld まずは基本から． IO モナドは， Haskell の根幹となるモナドで， main も IO で書く． GHC では中身は次のように定義されている [1]: -- In GHC.Types module of ghc-prim package newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #)) 見ての通り， IO a は State# RealWorld -> (# State# RealWorld, a #) の newtype だ．あんまり見慣れない State# RealWorld という型と (# , #) という型が出てきたけど， State# RealWo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
