#あっ、このコメントがあるのは、GHC.IO.Encoding.CodePage.Table を自動生成するスクリプト （base/codepages/MakeTable.hs)です。と、補足。
##なので、GHC 6.12 では Control.OldException はとりあえず残る方向です。
##ただ、Control.OldException は、コメントにもあるように移行期間として deprecated の警告付きで残されているものです。よって、GHC 6.8 までの例外処理を使っている方は、できるだけ早めに Control.OldException を使ったコードから新しい Control.Exception を使ったコードへと書き換えるようにしてください。
#6.8.x以前のControl.Exceptionをつかうコードを、6.10.x以降のControl.Exceptionをつかうコードに書き変える、単純で安全確実な方法というのはどこかに例があるのでしょうか
#例外をつかったコードに、ghc-6.8.x以前の環境でも、ghc-6.10.x以降の環境でもコンパイルできる可搬性を持たせるにはどうするのが簡単でしょうか
#Control.OldExceptionがあるのなら、-cpp でインポート宣言を分岐すればいいんだけど。
#基本的にはコンパイルエラーを順番に潰すしかないと思われる
#たとえば action `catch` \e -> ... を action `catch` \e@SomeException{} -> ... に直したりだとか
#どっちの環境にも対応しようとするなら -cpp で import するモジュールを分けるのがいいと思う
#個人的には project.cabal の中で
#if impl(ghc < 6.10)
build-depends: base==3.*
else
build-depends: base==4.*
#とかやるのがいいかなあと思う
#cabalize がめんどくさければ cpp のほうが手軽
#Programming in Haskell のレビュアー募集ですが、おかげさまで12名の方に引き受けて頂けることになりましたので、募集を閉め切らせて頂きます。
#一応、GHC 6.8.x 以前と GHC 6.10.x 以降での例外処理の可搬性を持たせるために、GHC 6.8.x に GHC 6.10.x の例外処理を提供する extensible-exceptions というパッケージが用意されています。
##あとは、将来の互換性を全く考えないのであれば、後方互換性のためのパッケージである base3-compat を使うという手もありますね。
#（ただし base3-compat は base とモジュール名が衝突するので cabalize が前提となりますが。）
haskell-ja > Archives > 2009/09/15