#(<*>) を定義する必要がないのでわざわざ
#Applicative m =>
#にしなくてよいので。
#よいのでは。
#Applicative m =>
#でも十分だけど、より制限の少ない
#Pointed m =>
#でよいのではと。
#ところで今日の夜は #haskell.jp の日でしたっけ。
#うん、kazu さんの提示されたコードでは Pointed で十分なんですが、Typeclassopedia 本文のコードのほうはまた話が別
#でも今日ってなんかあったっけか
#せっかくだから Typeclassopedia の輪読(?)でもしますか #haskell.jp で。とりあえず日本語訳読んできて疑問点を話し合う的な
#Real World Haskell 読書会参加中。
#現在は 7.4 あたり。
#hGetContents で取得したデータを二カ所で使いたかったら？
#いくつか方法は考えらる。でも、遅延 I/O で取得してきたデータを二カ所で共有（保持）するのは高くつくので、二回読んだ方が良いのじゃない？
#二回読みたくないのはどういう時？
#リソースを節約したい。でも、メモリをたくさん取って高く着くので、二回読んだ方が安くなるのでは？
#Haskell をつかうなら発想の転換が重要。
#既に閉じてしまったハンドルに対して hClose を呼び出したら、どうなるの？
##forkIO や forkOS をすればハンドルはコピーされるの？
#されません。ハンドルをコピーする処理は含まれていないので。どちらかのスレッドでハンドルを閉じると、両方のスレッドでハンドルが利用できなくなります。コピーしたければそういう処理をして下さい。
#ハンドルをコピーするには？
#System.Posix.IO を使ってハンドルから FD（ファイル・ディスクリプタ）に変換して、FD をコピーする。
##でも、この方法は unix パッケージに依存するので移植性がない……。
#おっと、handleToFd は元の Handle を閉じてしまうので注意。
#7.5.1 mapM を紹介するより前に sequence を紹介した方が良いのでは？
#この説明では mapM が魔法の関数に見えてしまう。
###でも mapM が sequence で定義できることは mapM の本質ではないよね。
#（途中で効率性の話がでましたが、それは "foldr/build" で解決されます。）
#sequence を先に説明した方が、アクションの作成（IO のリストの作成）とアクションの実行がきれいに分離されるのでは？
#>> の読みは？ then とか seq とか。
#GHC の内部実装では、今でも thenIO とか bindIO とかを使っています。
##instance Monad IO where
{-# INLINE return #-}
{-# INLINE (>>) #-}
{-# INLINE (>>=) #-}
m >> k = m >>= \ _ -> k
return x = returnIO x
m >>= k = bindIO m k
fail s = failIO s#thenIO がどこで使われていたかは覚えてませんが。
#m >> k = m `thenIO` k ね。
#今日は Real World Haskell の飲み会で誰も #haskell.jp にアクセスできないと思うので、14日にしましょう。 > nwn
#8章に入りました。
#bytesting の性能は C のコードを超えるって……
#bytestring は stream fusion を使って中間データ構造を削除してくれるので、性能はかなりよくなるはず。
#でも、C よりも速くなるかというと……GHC の最適化機能の改善が必要なのではないでしょうか？
#最新の gcc と争おうとすると大変。gcc 3 なら勝てるかもしれないけれど。
#まあ、GHC の最適化上の問題を直して、supercompilation を入れれば C より 10% 速くなるという話もありますが。
##なお twitter でもつぶやきましたが、現在 GHC に直接 supercompilation を追加する試みが行われているようです。http://hackage.haskell.org/trac/ghc/wiki/Supercompilation #終わったのでRWH読書会に移動。まだしばらくやってそうですか? >
#はい。第8章に入ったばっかりなので、もうしばらく続いていると思います。
#ふむ、 HIMA の内部でやる感じになるのかな(って勝手に言ってますが) 了解です
#regex-posix って Windows で使えたっけ？
#今 Text.Regex.Posix の説明（8.3）を読んでいるところ。
#まあ、Real World Haskell の著者は Windows ユーザーには冷たい（というか unix ユーザーしか想定していない）ので、使えなかったとしてもこれは仕様でしょうけれど。
#あっ、bytestring と性能を争っていたのは gcc 4.3 だったかも。ソースがすぐに見つからないので、確証はありませんが。
#gcc 4.3 と比べているのなら、gcc 4.4 には負けるけれどというような話だったと思います。
#会場には Windows ユーザーがいませんね。 > regex-posix
#家に帰ってから調べるか、酒井さんに regex-posix があるかどうか調べてもらうことにしますか。
#ロードされる package のバージョンが原著と違うのは？
#原著が出たのは GHC 6.10.1 がリリースされる直前で GHC 6.8.x を使って書かれていたけれど、翻訳では GHC 6.10.4 に出力を合わせている。
#酒井さん来た。
#++ の効率性について色々。
#性能については、GHC （+ライブラリ）の最適化が頑張っているせいで「一般的な性能分析と、実際に使用する場での性能」が異なってくるのが難しいですね。
#まあ、この段階ではそこまでの分析は求められていませんが。
#Real World = 「浮世」？
#Real World Haskell = 浮世の Haskell
#listMatches の then、else の位置は大丈夫？
##ただし、Haskell prime がでるまで GHC の実装は変更しないと前に言っていました。
#x <- の xより後ろに来ているので、listMatches でのインデントは問題ない。
#最後のが結論ね。
#例外処理どうするのかと思っていたのですが、Control.OldException モジュールを使うようにしていますね。
#Control.Exception の新しい例外処理については手前味噌ですが、私の連載の「例外処理」に関する回を読んでみて下さい。http://itpro.nikkeibp.co.jp/article/COLUMN/20081104/318426/ #Control.OldException と Control.Exception の利用が混在している……。
#読書会終了しました。
#ありました。 > Windows に regex-posix
#Typeclasspedia (の訳)を読んで、ようやく shelarcy さんの連載が Functor から始まった理由が理解できた。3年前かかった。
haskell-ja > Archives > 2009/10/31