##モナドのスタック 2 段くらいしか自分で組んだことないけど
#後でちょっと試してみよう
#suparmonad 見た
#たしかに lift . lift . lift ... って
#ドンドンドリフの大爆笑ーになる
#super だ、typo
#でも、このやりかたはどうかなあ
#f = lift . lift の型を限定して書けば、混乱はないと思うのだけれど (explosion というのもよくわからない
#志村ー NoMonomorphismRestriction、NoMonomorphismRestriction
#てきとうに instance 宣言して 2 段でやってみたら IncoherentInstances 指定しろとか言われた
#どのインスタンスを使っていいかわかんなくなっちゃったみたい
#explosion っていうのは、たとえば既存のライブラリに MaybeT みたいに新しいトランスフォーマを入れるとして元々あったトランスフォーマたちに対応するインスタンスかかなあかんっていう話だと思われる
#あー、なるほど
#たしかにそれは書く
#(GHC に怒られた時に)
#だけど一行だけだよ
#GHC 拡張の stand-alone deriving つかう
#初耳
#data Foo a = Bar a | Baz String
deriving instance Eq a => Eq (Foo a)
#newtype Foo a = MkFoo (State Int a)
deriving instance MonadState Int Foo
#こんな書き方がゆるされる
#下のケースでおk
#それはどういう書き方の略記なの？
##そこから抜粋しました
#deriving は行頭に書かなきゃいけないみたいで少しはまった
#(The last argument of the instance must be a data or newtype application)
#(´・ω・｀)
#GHC 6.10.1 では未サポートだった...
#そういえば 6.10.4 の release candicate ビルドしてない。。。
#うーん、GHC はこういう拡張を使ったらどう？って教えてくれるのは良いんだけど
#それがいったいどういう拡張なのかは教えてくれない
#LANGUAGE プラグマじゃなくて OPTIONS_GHC プラグマ + -X では通った...
#これはバグだなー
#まあ、ともかく、一行 MonadState とか書くだけで get, set できるようになることはわかった
#手元では deriving instance Monad Foo も必要だったので二行だけど
#GHC のエラーは不親切で、親切に possibly, ... とか言うときはだいたい外れている
#んー、冷静になると、これって別にモナドを重ねているわけではないな
#StateT つかった例つくってみよう
#そういえばそうですねw > モナド重ねてない
#newtype Boo a = Boo (StateT Int IO a)
newtype FooBar a = FooBar (StateT Char Boo a)
deriving instance Monad Boo
deriving instance Monad FooBar
deriving instance MonadState Char FooBar#あああ、やっぱり行末の空白が
#まあ、それはともかく、これは、手元では通った
#-XStandaloneDeriving 付き
#newtype じゃなくて type したら、もちろん、deriving すらいらなくなる
#はず
#fb1 :: FooBar Char
fb1 = get
#ふむふむ
#うわしかし、ちょっとめどいな、type だと
#newtype のほうがらくだ
#TypeSynonimInstances ?
#あ、そうでもなかった
#どっちやねんw
#type Boo = StateT Int IO
#type FooBar = StateT Char Boo
#これでいいんだわ
#これだと、instance 宣言いらない
#楽さを求めるなら type 使えばいいんですね
#だけど、エラー表示のときに Boo ってでてくれなくて
#StateT Int IO になっちゃう？
#ちょっとかなしい思いをする
#そう
#うーん、そこはコンパイラが空気読むしかないのかなあ...
#type は、あくまで別名だから、展開されてしまって、消えてしまう
#エラー表示のために残してくれてもいいのに...
#postprocessor が欲しくなりますね
#コンパイラのエラーをいい感じに整形してくれるような何か
#でも、残せない理由もあって
#type A = Int; type B = Int は正しいので
#型を明示的にかかないで型推論する場合、A とか B とか言わずに Int というのは、方針が正しい
#あ、そっか、Int を A に戻せばいいのか B に戻せばいいのかわかんなくなるのか
#うむ...
#その点 newtype だと型構築子がついてるから、区別できる
#あとアクセス制御的な意味でも newtype は良いですよね
#俺のモナドの中で勝手に get/put すんじゃねえとかそういうのができるのも強い
#なかみ取り出したいなら、newtype A = A { unA :: Int } とすればいいしね
#おしえてくん登場
#おばんです
#おばんですー
#どもどもー
#さっそく質問いいですか！！？
#例えばあるライブラリを使おうとしたらHoge型構築子がありました。
#ほい。
#で、Hoge型構築子はMonadのインスタンスだとドキュメントはおっしゃってた
#さて、この瞬間Hogeというものに対してどういうイメージというか
#何を思いました？
#うわ、すげー抽象的！！
#イメージ？ イメージかー
#あるいは、じゃあドキュメントのこのあたり調べればHogeを使いこなせるなーとか
#あ、それならもうちょっとわかるかも
#あるいは何に使えそうかを理解できます？
#お、そのへんクレクレーー！！
#もし、ドキュメントの中に fuga :: Int -> Hoge String みたいなのがあったとして
#liftIO . putStrLn =<< fuga 100 とかすれば何かが起きるという予感はするかも
#お
#とりあえず型をあわせようとがんばってみる
#ghci で :i する...
#ドキュメントなんて信じない
#(長門調でおねがいします)
#まーいつのまにかソース読んでたりするけどねー
#その場合、Hogeが何かってのはあまり重要じゃなくてHogeを生成している関数を理解しようとするんですね
#結果的にそうかも
#ふむ。
#上の例を見ると勝手な推測ですあg
#ですが
#=<<によって取りあえず中身を取り出す
#ってことを試みている段階でHogeはやっぱりコンテナのイメージが付いているんでしょうか？
#Monad のインスタンスだってことで、return :: a -> Hoge a と (>>=) :: Hoge a -> (a -> Hoge b) -> Hoge b が使えるってことだけしかわからない
#それとも、Monadごとに=<<に何か細工があったりするわけだから
#=<<が何をしているかを調べようとしている感じでしょうか
#return と (>>=) が実際なにかはまだわからないから、ソースを読む
#そこなんですけど、
#例えばですね、Eqクラスってあるじゃないですか？
#ないです！（うそ）
#何それ（うそ）
#例えばFugaという型がEqクラスのインスタンスだと言われたら
#(==)の実装もまぁ見るでしょうが
#見ないですね
#常識的に考えて
#ともかくFugaが「同じ」ってどういうことよ？って議論が出来るってことをイメージしますよね？
#そうです
#ifの条件式に使えそうとか同一性の判定に使えそうとか
#そして、もしですよ
#(==)の実装が a == b = a % b
#あーすまん
#a == b = (a % b) = 0
#%は剰余ね
#となってたとしたら「あれ？変じゃね」って思いますよね？
#とりあえず、なにもかんがえずに、Fuga のソースを読んで、Arbitrary のインスタンスにして、quickcheck で (==) の性質をたしかめる
#そこ！
#Arbitraryは知らないですが
#つまり等しいということについて
#「性質」を認識してて
#それによってEqという性質についてイメージを持ってるんじゃないかと思ってんですが
#上のEqの例では6は3と等しいけど
#3と6は等しくない
#とか
#それは等しいっていう性質を満してない
#んー、6 == 3 でもいいんじゃね？世界では、いいのでは
#Z/3Z って、普通の対象だし
#Z/3Zって何でしょう？
#日本語でしゃべってなくてすまぬ
#Z/3Z = {0, 1, 2}
#Z -> Z/3Z が (% 3)
#Z は Integer だ、そっちをつかおう
#type Z = Integer だとしてくれたまえ
#==を使ったプログラムを書くときに6==3と3==6とで結果が違うんですよ？
#それでもOK？ってことですか？
#それはおかしい
#そういう例です>上のは
#6 % 3 => 0でTrueだけど3 % 6=> 3でFalse
#ほんとだ、そういう例ですね
#だし当然推移律もなりたたない
#で、そういうルールが背後にあることで
#Haskell の型クラスは、プログラマに「性質を証明すること」を暗に要求します
#Eqクラスに対する==に付いてのイメージがあるんじゃないかと思います。
#でだ。
#>>=とかreturnの実装も、まぁ重要なんでしょうが
#おそらくHogeというMonadのインスタンスには
#インスタンスをあげたのは、
#モナド則が何を意味しているかについての
#モナドを理解している方のイメージというか
#>>=とかreturnを明かしてなかった分だけ
#モナド則について*だけ*のイメージが問えるかなーと思ったのですが
#そうですね
#要するに、Haskell のモナドを使ったプログラミングには、2 種類の考え方があって、
#既存のモナドを使うなら、特にモナド則を意識する必要は無く、たとえば List モナドとか Maybe モナドの各振舞いを覚えておけばいい
#いっぽう、初めてみたモナドと主張する何かについては、注意深く return と (>>=) をみないといけない
#さもないと、さっきわたしが勘違いしたように、(==) が実際には Eq であるべきでない、とかやってしまう
#上の例は引っかけるのが目的ではなく、「あれ？おかしい」と感じる背景には
#で、確かめるには、QuickCheck が一番てっとりばやいよ、というのが個人的な意見
#うーん
#Hogeの実装が正しいかどうかを議論したいのではなく
#「あれ？おかしい」と思った背景にある法則がありますよね
#交代律(？)が成り立つとか推移律(？)が成り立つとか
#この法則が成り立つことを利用して
#==をプログラムの中で使っているんじゃないかな？と思っているんですけど
#そうだとしたらMonadを使う時にはモナド則を満すからこそ
#その法則が成り立つことを背景にしてプログラムの中でMonadを利用しているのではないかな？と。
#(==) は 1. forall x. x==x, 2. forall x, y. x== y ==> y == x, 3. forall x, y, z. x == y && y == z ==> x == z
#の 3 つがないといけないっていう、ことは、モナドの 3 則が必要ってこととも同じですね
#おお同じものも等しいのか
#まぁ数はともかく、これらの法則が「同じ」ということのイメージを我々に植え付けてて
#プログラム中でも==をこれらの法則を期待して使ってるはず。
#Monadのバヤイはどーなんかなーと
#Monad 3 則を期待しているのではないでしょうか
#そうだと思うんですが、モナド則の意味ってエントリがいくつかあるんですけど
#山本さんなんかも書いてたり
#でもね、こういうreturnは書かなくてすむことを言っているとか
#山本さんは、ふつうに迷路をさまよっていて、観察の対象ですね
#どーもコード上の便利のためみたいな解釈で
#そういうものとは違うものを期待してたんですよ。勝手に。
#んーむ
#上のEqみたくすっきりしないのは型の性質ではなく型構築子の性質だから難しいって
#コード上の便利、であり、かつ、法則的、なものなんじゃないのかしらん
#nobsunとかには言われたけど、それでも使いこなしている人には何かしらMonadについてのイメージがあるんじゃないかなーと
#イメージありますよ。個人的には、do がつかえてうれしいなーらんらんって。
#なるほど、それもコード上の話になりますねー
#Applicative も忘れないであげてください
#あと、さっき nwn さんとも話してたことになりますけど、モナド変換子つかって積み上げるの楽しいので
#Monad になってないとげんなりします
#それはある
#Monad 則だけを期待してるプログラム（関数）っていったら Control.Monad の中の関数ぐらいじゃないかな
#そうなんだぁ
#いや、知らないですけどw
#あれ？
#でもね
#もし上のEqの==の実装同様い
#同様に
#Monad則を満さないreturnとか>>=の実装になってたとしたら
#何がしかの期待が裏切られた振る舞いをするんじゃないかと思うんですが
#そうでしょうね
#なんでコンパイルに通るのに、こんな振舞いになっちゃうのみたいな
#それって何か期待できる性質があるんじゃないかな
#まーすぐ言葉にできないものかもしれないのですが
#理解している人なら「あれ？変だぞ？」と思いますね？
#なぜ変だと思うんでしょう？
#何を変だと思うんでしょう？
#それが性質だったりするかも
#3 則のどれを破っているかによるだろうな
#まずはどれでも良いのですが何か例はありませんかねぇ
#言うのが楽な順にいうと、3 番目の (m >>= f) >>= g == m >>= (\x -> f x >>= g) がなりたってないばあい
#おもしろそう！
#do で書いてた時に、途中で fail するなり GHC panic! するなりなんかなる
#やってみるといい
#ありゃ、そこまで致命的なレベルかぁ
#panicって見たことないな
#どーゆー時にpanicするんだろう
#panic はモナド則破ったからでは起こらないと思う
#GHCがワケワカ！って思うんだー
#1 番目 (return x) >>= f == f x と 2 番目 m >>= return == m のどちらかが成り立ってない場合は
#たぶん、コンパイル時にエラーが起きると思う
#そうなの?>nwn
#そう聞かれるとなんか起こる気がしてきたw
#コンパイル時にエラーってのは型の整合性で？
#でもモナド則満してなくてもHaskellは知ったこっちゃないんですよね？
#returnと>>=が実装されてりゃOKなスタンスですよね
#(>>=) をインライン展開してるうちにわけわかめになって panic とかはある気がしなくもなくもない（どっちだよ）
#ごめん、忘れてください
#^^;
#なんとなく気になるのはモナド則が満されてない実装だったときに
#それを見て上のEqの様に「おかしい」と思うのではなく
#使ってみてGHCが「おかしい」挙動をするから変だと分るだけってことのようですね
#かなしいかな、そうです
#本当は紙で検算とかするんだと思う
#GHC が、か、あるいは、それを使って作ったプログラムga
#おかしくなるか
#とすると「モナド則」が背景にあることで皆が何を期待しているかについては
#のどちらか
#もしかしたら「言葉にできないでいるだけ」か「実際何のイメージも存在しない」かでしょうか。
#できれば前者であって欲しい。
#ありがとうございました>ikegami,nwn
#なんとなくちょっとずつ質問のポイントも見えてきたし
#イロイロ収穫がありました！
#サンクスです。
#後者じゃないかなー。『言葉』の定義に Haskell のプログラムを含むのであればモナド 3 則を差し出すだけだし
#えらく曖昧かつ的を得ない質問ですんませんでしたが
#差し出す、とは？
#モナド則が成り立てば、こういう書き換えができるよって示す
#それをひとまず信じといていろいろやるんだっていう
#それはコード上の便利のためのものだということでしょうか
#だとすると後者だということになるか
#うん、使ってみると便利っていう
#うーん。便利なんだ？！その辺がまだまだ修行が足りないなー
#まるでHaskellで自由にコードが書けないorz
##ちょwwww
#モナドじゃない Either a b を、黒魔術でモナドに見せかけてみました
#GHC に通ります
#すきなだけ、BUG しまくってください
#コンパイル通りました。
#Haskell は性善説を仮定しているので
#さて、これはモナド則を満さない？
#1. return x >>= f :=====: f x
#が、このばあい、return は Left しかみてないので
#Right だったときに、ほんげー
#場合によって満さないわけか
#n :: Double -> MaybeInt Double
n d = return d*NotMonad> unMI (n 2.1 >>= return . show)
Left 1879136974
#わわわ
#n :: Double -> MaybeInt Double
n d = return d
*NotMonad> unMI (n 2.1 >>= return . show)
Left 1879136974
#そうです、おそろしいことになるのです
#C のほうが SEGV ってくれるだけましって気分
#どっちもいやです ; ;
#同じくらい
#なるほど、奇妙だ
#unsafeって時点で
#モナド則を満さないことより問題じゃないか？と思ってしまった
#いやまあ、GHC のコンパイルに通るモナドでない何かがすぐに思いつかなかったので
#unsafeCoerce :: a -> b つかっちゃったわけですけど
#ゆっくり考えれば、GHC がモナドだと信じてしまう普通のデータ型はいくらでもありそう
#モナドじゃないのにモナドみたいななにか
##unsafeってプレフィクスつけるのってどうかと思うな>Haskellライブラリ
#いや、むしろ重要で
#どんなプレフィクスがいいですか？
#unsafe ってつけないと、初心者が使っちゃう
#こっちもか>nwn
#いや、それよ。
#使うなと言われるライブラリが提供されるという文化が
#unsafe は safe なときがある
#どうも理解できない
#けど、safe なときがいつか、を知るには GHC のソース全部読まないと駄目
#実際私はunsafeと見た時点でそっぽ向いちゃうな
#で、GHC の開発者とかマニアが、たまに欲しがる
#まあ、たしかに、標準ライブラリとして配るのはどうよ、という気はする
#他の手段では実現困難？この種のやつは
#Id はモナドなので
#PartialId
#部分的な Id をモナドだと信じ込ませようとしているところ now
#hpastetwoってHaskellのコードをはりつけるwikiみたいなものですか？
##Haskell の住人たちのための gist もしくは pastebin
#hpaste.org は、おもに Haskell コードを貼付けて、IRC とかで議論するのに使います
#しらなかったです。
#cppとかも貼り付けられてますね
#キーワードに色付けてくれるのがステキ
#ほい : unsafe つかわない、Monad じゃないなにか
##strange を評価してくれたまい
#あれ、インデントずれてるな、なおしてください
#よくわからんがインデントがずれてしまう、うーむ
#どっかずれてますか？
#strange の定義
#そのままコピペでロードできました
#まあ、それならよかった
#あーほんとうだ
#でもEmacsに貼った時点でも無問題
#確かに期待を裏切ってますね
#何が変でこうなるのかまだ分らないですが
#モナド則ひとつずつ検証すればよいのか
#return x >>= f :====: f x はどうかな
#(left) = (The x) >>= f ---> f x
#めでたし
#The x >>= f ---------> f x
#はいOKです
#m >>= return :=====: m
#mがThe vなら
#The v >>= return ------> return v -------> The v
#OK
#うむ
#mがEmpty ??なら
#Empty ?? >>= return -------> Empty ()
#これは満さない可能性がある
#Empty () >>= return ---> The (Empty ()) /= Empty ()
#2 番目がなりたってない
#Theは噛まないのでは？
#Empty () >>= return ------> Empty ()
#その場合には成り立ちそうな
#あ、ほんとだ
#じゃあ、いちばんめんどくさい 3 番目か...
#(m >>= f) >>= g == m >>= (\x -> f x >>= g)
#うう
#mがThe vなら
#うう
#それは Id が Monad だからだいじょうぶなはず
#m が Empty () のときにおかしくなってくれるとおもう
#あーそうか
#わかった
#(Empty () >>= f) >>= g ------> Empty () >>= g
#-----> Empty ()
#というわけで左辺はEmpty ()
#そうだね、>>= は Empty () をずーっとすどおり
#Maybeと同じになりそうな
#がーん
#Empty () >>= (\x -> f x >>= g) ------> Empty ()
#成り立つかも
#ってことはやっぱりEmpty ()の()が()じゃない場合に成り立たないってことでは？
#でもstrangeの例ではEmpty ()しか使ってないけど
#return x = Empty () にすれば Maybe じゃなくなるかも
#なぜだろう
#でもstrangeは実際奇妙ですよねぇ
#*PartialId> let justmaybe = do x <- Nothing; y <- return 1; return (x,y)
*PartialId> justmaybe
Nothing
#あれ？別に奇妙じゃないのか
#普通のMaybeと同じだったか
#どうやらそのようだ、時間を費やしてしまいもうしわけない
#return x = Empty ()にするってことはMaybeのreturn xをNothingにするってのと同じってことですね。
#それは成り立たなそうなかほりが
#return x >>= f :====: f x
#Empty () >>= f --------> Empty ()
#で最初のは成り立つ
#m >>= return :=====: m
#mがThe vなあ
#なら
#The v >>= return -------> return v -------> Empty ()
#成立しない
#やったー
#で、これで振る舞いを
##なんか奇妙な結果になるstrangeがいるなコリャ
#オオォ
#奇妙だ
#return したら終了
#なるほど、そらそうだ。でも奇妙だ。
#なるほど、でもこの奇妙さってのはモナド則ではなくreturnの意味に対する奇妙さなのかしらん
#やはりreturnや>>=の意味の方に重点があるのかな
#ふむ
#明日は出張なので、のんびり考えてみよう
#わたしも考えてみよう
#圏論で return, >>= に対応するものを考えて、あえておかしくすれば、きっとヘンテコなものができるにちがいない
#モナドにならない物を探すよりすでにモナドになってる何かを壊すほうが簡単なのかもね
#ふむ。
#そう思って Id をいじったら Maybe になったという
#ともかく成り立たないものを考えて、そこに違和感なり不自然さを感じられたら嬉しいのですが。個人的にはね。
#それが個々のMonadのインスタンス個別のものだとそう嬉しくないけど。
#おそくまでありがとうございました！！
#日付も変ったのでそろそろ退散します~
#ごきげんよう
#ごきげんよう
##これ貼るの二回目だったり
#そろそろ自重
#あらもういない？ > cut-sea
#コメントが薄いー（かんけいないけど
#data ListL a = NilL | Scon (ListL a) a
#みたいな逆と、おなじことなんじゃないのかなー
#Scon じゃなくて Snoc (どうでいい
#良い夢をみたいので、妄想してみるのだけれど
#ブートストラップから、なにから、完全に ghc とは独立した Haskell 処理系で、ghc extension をサポートする
#ってものを作るのに、どれくらいの時間がかかるだろうか
#一年じゃ無理かなあ
#読み返してたのでまだいるにはいる>nobsun
#あきらめて、おとなしく、目立ちそうなライブラリでも書くか...
#純粋じゃなくなっちゃうライブラリ
#目立つよ
#Haskellじゃなくなっちゃったみたいな
#モナド則1、2を満すけど、モナド則3を満さないMonadって構成できる？
#日本語になってない
#（わたしもそうだけど）
#以前もそれ言ってましたね？
#そう。
#そういう例ってもしかして無いのでは？という疑惑？
#return, >>= が 1,2 をみたして 3 を満たさないようにつくる、ってことですね
#そうそうす
#確かに3が満さないってのが一番面白そうな議題なんだけどな
#1、2を満すのに3を満さないと何がおこるかが知りたい。
#1,2はなんか基底条件が変って感じの変さで3は再帰条件が変みたいなさ(全然意味不明)
##圏論的には、ηが return で、μが >>=
#だから、arrow なんだけど、可換図を満たさなければ 3. がなりたたない
#(正確にはμじゃないんだけど、うーややこしい
#3. は、確か四角形の diagram に対応するはずだ
#commutativity of mu
#関数合成の結合法則みたいなものだから成り立たないとdo構文がむちゃくくちゃになりそうだとおもうんだけど。実際に構成してその様子がみたい。
#だから、三角形 commutativity of composition ηが成り立つが、四角形 commutativity of mu が成り立たないものを探す
#と、対応する return, >>= がそれぞれη, μからつくれるはず
#見つけられそうですか。
#難しそうなので先に寝ます~
#すみません。朝起きたら例が出てるとラッキーみたいな。
#おやすみです
#面白うそうな話してる。
#いれ違い
#(==) の不自然な話は
#8 Haskell の標準クラス 8.4 導出されたインスタンス
#にも
#非推移律的な (==) 述語は、たとえば、大変苦痛で、プログラムを読むものを困惑させ
#とありあすね。
#なんてタイミングでやってくるんだ[1..100]>>=pen
#でも寝ます。お先に~
#もっと起きてなさい(w
#(w
#おやすみです。
#おやすみなさい
#「たとえば、大変苦痛で、」訳も不自然(w > nobsun
#「大変苦痛で、読むものを困惑させる」気分を良く表わしている迷訳 :p
#確かにイコール的なものに対する直感ほどにはモナド的なものに対する直感はみがかれていないような気がしますね。
#夜更しするといけないので明日考えてみます。
###http://practical-scheme.net/chaton/haskell-ja/a/2009/07/02#entry-4a4ca814-5615a の例は {-# LANGUAGE StandaloneDeriving, MultiParamTypeClasses, GeneralizedNewtypeDeriving #-} で使えます。 #stand-alone deriving は連載の過去の回で使っていたので、「あれっ？」と思って調べました。
#あと、unsafe プレフィックスのつく関数の提供は、普通のモジュールで普通に提供されているのでなくて。基本的には Unsafe.Coerce や System.IO.Unsafe のような Unsafe の名のついたモジュール、または GHC.* のような内部定義用のモジュールに隔離されています。
#unsafePerformIO が互換性のために Foreign で提供されているせいで、一部方針を徹底できない部分もありますが。
#にゃるほどー
#(まだおきてた
#それでも普通に使えるのが嫌だというのであれば、次の base パッケージの分割で unsafe パッケージというのを作って dph-* のような隠しパッケージ扱いにするよう提案してみると良いと思います。
#いや、ぼくはむしろ、簡単に黒魔術できるほうが楽しい派なので、いいです
#そうすれば unsafe パッケージを明示的に使用しない限り、基本的には unsafe の付く関数は使えなくなるはず……
#私も使いたいときには直ぐ使える方が良いですけれどね。
#あと ByteString パッケージにある最大限危険な関数 inlinePerformIO には、unsafe が付いていないと言う事実。
#一応、こちらも Data.ByteString.Internal という「普通の人は使うな」というモジュールに隔離されていますが
#おっと、小文字の bytestring パッケージですね。
##New Build System への移行に伴い、一部 target がリファクタリングされて無くなっていたり、GHC 6.10.* を想定するビルド環境ではビルドできなくなっていることがあるので注意が必要です。
#また、README が古くなっています。target が無い旨のエラーがでたら、Makefile か http://darcs.haskell.org/ghc/ghc.mk に target が存在するかどうかを直接参照した方が良いと思います。 #話題の途中ですが、そろそろ寝ますです
#おやすみなさい
#おやすみなさい
#これに関連して Current の Windows バイナリが暫くの間提供されなくなっていたのですが、6月30日にようやく復活したようです。
##というわけで、Windows でもきちんと New Build System を使った Current がビルドできるようです。ただし、docbook の扱いが少し厳格になっているので環境によってはドキュメントがビルドできないかもしれませんが……。
#GHC のビルド中にパース・エラーが起きる場合ですが、HackageDB にある alex や happy の方が新しいのでそちらを使ってください。
###あっ、alex の方が URL が短い。
#happy もこちらでいけますね。
##あと、happy は流石にホームページの方のバージョンもあがったみたいですね。
#最後に Current からは extra libraries が消えていますが、これは仕様です。
##今後は Haskell Platform ni
#バンドルされるので、そちらを使ってください
##あるいは cabal コマンドなどを使って自分の手でインストールしてください。
#では、そんなところで
#おやすみなさい
#ghc-6.10.4-rc1 Tiger でビルドできたーやったー
#一応ドキュメントでの Data.ByteString.Internal の参照はできなくなるみたいですね。
#patch applied (bytestring): Hide the .Internal modules in the haddock docs
##Haskell platform が本家に載るとは思わなかった、dons にくわえて dcoutt の存在がおおきかったのかな
#初心者にとってインストールが楽になることはいいことだ
#いやいや、誰にとってもインストールが楽になるのは良いことだ、です。
haskell-ja > Archives > 2009/07/02