Haskellでのエラーの扱い方。あるいはApplicative, Monad等とliftが多くなることについての考え。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @nushio その問題は、歴史的な理由だけで生じているわけではありません。現在の Haskell (+GHC 拡張)にはスーパークラスのインスタンスやメソッドを定義する機能がないので、階層化すると modularity が損なわれるのも問題となっています。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @nushio あっ、Functor → Applicative → Monad 階層化すれば全ての Monad はApplicative になる（ことを強制させられる）はずですが、

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @nushio 階層化してしまうと新しく Monad を定義する人は例え必要なくても Applicative → Monad の順番でインスタンスを定義しないといけないて modularity が損なわれてしまうという意味ね。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @nushio で、今この辺の問題を解決する為に、スパークラスのデフォルトインスタンスを定義する機能が提案されているわけです。 http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @nushio あっ、Haskell 2010 から Haskell 言語仕様 → ライブラリではなく、ライブラリの変更 Proposal → ライブラリを変更　→ Haskell の言語仕様の形で言語仕様にあるライブラリを変更できるようになりました。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @nushio ただし、Functor → Applicative → Monad 階層化のように拡張機能を入れる必要のあるものや、例外処理のようにいきなり変えると既存のコードや処理系への影響が大きいものに関しては、変更順序を意識して漸進的にしか変えられませんが。

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @nushio この辺については、前に行なわれた Prelude の catch や System.IO.Error の catch と try を削除するためにとりあえず非推奨化しようとした時の話が参考になると思います。 http://j.mp/hbVtkd

shelarcy（しぇらーしぃ） @shelarcy

@tanakh @nushio .｡oO（Ticket での議論を読めば特に読む必要はありませんが、私の twitter での言及がこの辺にあります http://twilog.org/tweets.cgi?id=shelarcy&word=catch&date=101227 )

nushio @nushio

@shelarcy @tanakh なるほど。田中さんも前にエラーの扱いではまってましたね。そもそもmonadiusもcatchか何かが古くなったせいでいまはコンパイルできなくなってたはず。

nushio @nushio

@shelarcy @tanakh Haskellはまだまだ成長途中の言語なのですね。変更があったら自分もその意味を理解してちゃんと使えるようにしとかないと・・・。