19:59 kazu_: 始めますかー。
19:59 kazu_: こっちは、Typeclassopedia です。
20:00 himabot: HIMA はじめますよー (今回は Typeclassopedia を吊るし上げる会です)

20:00 kazu_: どう進めます？
20:00 nwn: どうしましょうか
20:00 kazu_: バラバラと質問を書いて行く？
20:01 kazu_: あるいは、論文を上から順に進んで、適宜質問を出す？
20:01 nwn: 順番のほうがいいんでないかなーと思います
20:02 ikegami__: はじめにアンケートをとることを提案します
20:03 kazu_: では、1) 思いつきで質問する、2) 順を追って質問する。のどちらかに投票して下さい。
20:04 ikegami__: Q. Introduction にある 4 つのことがらに、どれかひとつでも心当たりがある [y/n] or そもそもその4項目が意味不明
20:04 nobsun: こんばんわ
20:04 nwn: こんばんは、ただいま今日の進行について話し合っております
20:05 nwn: とりあえず、今日は Typeclassopedia に
20:07 kazu_: うーん。反応ないな。
20:07 nwn: 僕は 2 のほうがいいかなーと
20:07 kazu_: とりあえず、2) の上から順に行きましょう。

20:07 kazu_: では、序論。
20:08 kazu_: モノイドとモナドはどう違うのか？
20:09 kazu_: MonadPlus はモノイドですか？
20:11 msakai: mplusを演算、mzeroを単位元とするモノイドになっているはず。
20:11 nwn: でも同じ物ではありませんよね
20:11 nobsun: モナドの上にmzero と mplus だから
20:11 kazu_: 一応。
20:11 kazu_: [65] Dan Piponi. From Monoids to Monads. http://blog.sigfpe.com/2008/11/from-monoids-to-monads.html.
20:12 kazu_: は、読んだんですが、さっぱり分かりませんでした。
20:12 kazu_: あとでやってもいいのですが、モナドを >=> で表現すると、Monoid に見えます。合ってますか？
20:13 nwn: @type (>=>)
20:13 lambdabot: forall a (m :: * -> *) b c. (Monad m) => (a -> m b) -> (b -> m c) -> a -> m c
20:13 nwn: m -> a b ga
20:14 nwn: a -> m b が return と (>=>) で Monoid にできるように見えるってことですよね?
20:14 kazu_: そうです。もう、Monoid にしか見えません。> nwn
20:14 msakai: Kleisli composition ですね。
20:15 kazu_: Kleisli って、どう発音するんですか？
20:15 nobsun: クライスリー
20:16 kazu_: クライスリーについて学ぶには、何がお勧めでしょうか？
20:17 nobsun: わたしは学んでいないので、msakaiさんが詳しいはず。
20:16 msakai: モノイドとは違って型が合致するものしか合成できないという違いはありますが、それ以外は似たようなものですね。
20:17 kazu_: あと、上記の参考文献に、モナドという言葉は、モノイドから作られたと書いてあります。
20:17 kazu_: この辺の事情は、どなたかご存知ではありませんか？
20:18 taninsw: ブログに堂々とモノイドだと書いちゃってた。訂正しなきゃ……
20:18 itto100pen: なんかとなんかの合成語とかとみたような
20:19 ikegami__: http://haskell.org/haskellwiki/User:Michiexile/MATH198/Lecture_7
20:19 ikegami__: Haskell コード付きなのでわかるヨ
20:20 kazu_: 結局、モナドとモノイドは、別ものだと思っておけばいいですか？
20:20 itto100pen: 圏論の基礎にも Kleisli圏の解説ありますか？わかりやすい？持ってる人
20:20 ikegami__: 筆者はスタンフォード大で教鞭をとっているMikael Vejdemo Johansson先生
20:20 msakai: monad は triad と monoid の合成だったかな
20:21 nobsun: triad って三つ組？
20:21 kazu_: うーん。では、triad が分からないと、さっぱり分からないんですね。
20:22 nobsun: MonoidであってMonadでないものを考えればどうかしらん。
20:22 msakai: モノイドの概念を圏論的に一般化して定義すると、モナドもある圏のモノイドになるのですが、とりあえずは別ものと思っていいと思います。
20:23 msakai: 圏論の基礎にも Kleisli圏の解説はあるけど、Haskeller向けではないかと。

20:23 kazu_: とりあえず、先に進みましょう。
20:23 kazu_: Parsec では Applicative スタイルを使うべきなんでしょうか？
20:24 kazu_: ちなみに、Parsec 3 は、Applicative のインスタンスになっているので、RWH にあるコードは読み込まなくても OK です。
20:24 nwn: 好き嫌いの問題じゃないかなーと思います
20:24 msakai: triadは三つ組みです。モナドは昔はトリプルと呼んだりしてたので、その関係かと。
20:25 msakai: 書きやすい方にすればいいかと思います。
20:25 ikegami__: パースしたい文法の設計段階では、むしろ do 記法のほうがやりやすいというのが個人的な感想
20:25 nwn: でも個人的には好きです JSON パーサはきれいだと思う http://github.com/yav/parsimony/blob/master/examples/ParsecJSON.hs
20:25 nobsun: 漠然とした感覚なんだけど。imperativeに書きたいならMonad、Functionalに書きたいならApplicative
20:25 ikegami__: 逆に、文法がきっちりきまってるなら、 do はバグの元なので避けるべき
20:26 nobsun: 好みからだけだけど。do はすきになれない。
20:27 msakai: パーサーを書くときに do を使うことが原因になるバグがちょっと想像できないのですが、
20:27 msakai: 何か例はありますか?
20:27 kazu_: あー、力の大きい方を使うとバグを招きやすいんですか。。。制約されていた方が、バグが少ないと。。。
20:27 msakai: あ、なるほど。
20:28 ikegami__: do の中での「上下」」の順番で、答えが変わっちゃったり、do の let のせいで評価されちゃったり
20:28 nwn: Applicative だと間に計算が入れにくい(いい意味で) って言うのはあると思う
20:28 msakai: Applicative はパース結果の値を持ち運んで、組み合わせたりするのがちょっと面倒くさい感じが……
20:29 nwn: どれ使ったらいいか思いつかないときは素直に Monad で書くw

20:28 kazu_: ところで、
20:28 kazu_: http://haskell.org/haskellwiki/Do_notation_considered_harmful
20:29 kazu_: を読んだんですが、感情論のような感じで、論理的な理由は読み取れなかったです。
20:29 ikegami__: considered_harmful ってのは、たいがいどれもそうではないかと : 感情論
20:30 nobsun: たぶん感情論になるとおもう。Pointfreeで書くとどうかというのと変らない議論かも。

20:31 kazu_: では、次に行きましょう。
20:31 kazu_: 図の辺で、質問はありませんか？
20:31 nobsun: Functionalに書くということは、関数合成に類するもの
20:32 nobsun: を多用するので、ちょくせつ、引数にさわらない。
20:32 ikegami__: point-free は、partial function つかわないかぎり、reasoning of programs に意味があるでしょう
20:32 nobsun: というわけで、Applicative はパース結果の値を持ち運んで、組み合わせたりするのがちょっと面倒くさい感じが……
20:32 nobsun: となる
20:32 nobsun: じゃないかな。

20:32 itto100pen: zip.ap fmap.(id &&& wtf)　って何？
20:33 ikegami__: wtf は what the fuck の jargon
20:33 ikegami__: それ以外は、Haskell にふつうにあります
20:34 msakai: ap fmap とかキモすぎる……
20:34 nwn: @type ap fmap
20:34 lambdabot: forall a b (f :: * -> *). (Functor f) => ((a -> b) -> f a) -> (a -> b) -> f b
20:34 itto100pen: それぞれにid と wtf して zip するってことかな。
20:35 nwn: @type ap ap `ap` ap
20:35 lambdabot:     Occurs check: cannot construct the infinite type: a = m (a -> b)
20:35 lambdabot:     Probable cause: `ap' is applied to too few arguments
20:35 lambdabot:     In the second argument of `ap', namely `ap'
20:35 nobsun: ((a -> b) -> f a) って
20:35 nobsun: どういう関数？
20:36 kazu_: どこからともなく Functor が現れてますね。
20:36 msakai: Functor が出てきてるのは fmap 使ってるから
20:36 itto100pen: what the fuck ってどういう意味？
20:36 nobsun: なんてこったい！
20:37 ikegami__: http://en.wiktionary.org/wiki/what_the_fuck
20:37 nwn: ap って Monad m => m (a -> b) -> m a -> m b だったような
20:37 nwn: と思ったけど instance Monad ((->) e) で消えてるのか
20:37 msakai: そうそう。
20:37 nwn: @type ap
20:37 lambdabot: forall (m :: * -> *) a b. (Monad m) => m (a -> b) -> m a -> m b
20:37 nobsun: 関数をたねに、値を構成するってどういうこと？
20:38 nwn: _|_、_|_ を使う
20:38 nobsun: それって。。。
20:39 nwn: たぶん const 1 とかそういうのじゃなかろうか
20:40 nwn: それ以外渡すと _|_
20:40 nwn: そうだね
20:41 msakai: (a -> b) -> f a な関数を受け取って、(a -> b) -> f b な関数を返すんだよね。
20:41 nobsun: なにしてるのこれ
20:41 msakai: (a -> b) があれば、fmap で f a -> f b が得られるから、
20:41 nobsun: ふむ
20:42 msakai: (a -> b) -> f a の返り値に適用して、f b が得られる。
20:43 itto100pen: でどういうときに使える？
20:43 msakai: ap :: ((a -> b) -> (f a -> f b)) -> ((a -> b) -> f a) -> ((a -> b) -> f b)
20:43 ikegami__: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html#v%3Aap
20:44 msakai: 個人的にはこんな関数使う気にはなれないなぁ
20:44 ikegami__: liftM ハリガネおかわりだだだだだー のかわりに `ap`
20:45 itto100pen: ap fmap
20:45 nobsun: pointfreeをつかうと頻繁にでてくる ap
20:46 itto100pen: zip.ap fmap.(id &&& wtf)　をわかりやすく書き直してください。おながいします。
20:46 nwn: だが断る
20:46 itto100pen: な、なんと。
20:49 itto100pen: ちぇ、後でひとりで調べてやる。
20:50 msakai: zip . ap fmap . (id &&& wtf) は型がおかしなことになってるね > itto100pen

20:46 kazu_: g <$> f1 <*> f1 <*> f2
20:47 kazu_: f `liftM` m1 `ap` m2 `ap` m3
20:47 kazu_: つくづく、Monad は Functor のサブクラスであるべきだったと思いまする。。。
20:48 nobsun: Goferのころはそうだったんですけどねぇ。
20:48 msakai: なんでやめちゃったのかねぇ。
20:48 kazu_: Funtor に行ってもいいですか？
20:48 nwn: はーい
20:49 kazu_: fmap って pure と <*> で作成できるんですよね？
20:49 nwn: fmap f x = pure f <*> x
20:50 nwn: ですね(たぶん)
20:50 kazu_: pure だけのクラス → <*> も加えたクラス → join も加えたクラス
20:50 kazu_: みたいになっていないのはどうしてですか？
20:50 ikegami__: low がいるから
20:51 nwn: s/low/law/ ?
20:51 msakai: law?
20:51 ikegami__: ほうそくのことです、すみません
20:51 kazu_: 圏論では、関手ありきだからということですか？
20:52 kazu_: pure だけのクラスには、法則がない？
20:52 nobsun: fmap g . pure = pure . g ?
20:53 msakai: pureだけだから、fmapもないのでは? > nobsun
20:53 nobsun: ああそういうことか
20:53 shelarcy: そのためにも、Subclass のメソッドを使って Superclass のメソッドを定義する機能が欲しいですね。 > Monad は Functor のサブクラスであるべき
20:53 shelarcy: http://hackage.haskell.org/trac/haskell-prime/wiki/ClassSystem#Probablyno
20:54 kazu_: 僕は圏論はまったく分からないのですが、プログラマーとしてはアトミックなメソッドを積み上げて、クラス階層を作りたくなります。
20:54 shelarcy: クラス階層を直すべきという提案は Haskell prime でも http://hackage.haskell.org/trac/haskell-prime/wiki/StandardClasses
20:54 nobsun: Functorありきじゃないかな。
20:55 nobsun: Functorの特殊化を積み上げている感じがする。
20:56 kazu_: そうんな感じですね。
20:56 ikegami__: たしかに、アトミックなメソッドを積み上げるには同感するけど
20:57 ikegami__: もしそうなったら、アトミックなところでつまづく初心者プログラマ続出、ということもあるかもしれない
20:57 shelarcy: なお、昔は Monad を使って Functor を定義した FunctorM という型クラスがありました。
20:57 shelarcy: http://cvs.haskell.org/Hugs/pages/libraries/base/Data-FunctorM.html
20:57 msakai: FunctorM って Kleisli category の上の functor みたいなやつだよね。たしか。

20:58 itto100pen: ところで Pointed を「基点付き」と訳すの？
21:00 itto100pen: なぜ pointed と表現するのも合点いかない。

20:59 msakai: FunctorMはmapをfmapに一般化するように、mapMをfmapMに一般化するクラスと。
20:59 msakai: ここでの話にはあまり関係ないか。
20:59 ikegami__: IO がモナドなので、とりあえずモナドさえわかればプログラム書ける、というのは、それはそれで個人的に納得する
21:00 ikegami__: main :: IO ()
21:00 msakai: アトミックなメソッドを積み上げる結果として、めったに使わないクラスが乱立するのが嫌だったんじゃないかなぁ。
21:00 ikegami__: 「まず Functor からだ」「えー」みたいな
21:01 kazu_: でも、それは作る人の立場であって、使う人にはあんまり関係ないですよね。
21:01 kazu_: liftM って書くより、fmap と書きたいです。。。
21:01 shelarcy: Monad クラスのインスタンスだけ定義したい時に、Functor クラスのインスタンスを先に定義しなければならないという制約はうっとうしいと思います。
21:01 msakai: で、めったに使わないと思っていたやつにも意外に使い道があったりして、階層の見直しが提案されてるのかなぁ、と。
21:01 shelarcy: > Subclass のメソッドを使って Superclass のメソッドを定義する機能なしで、階層化した場合
21:01 lambdabot:   Not in scope: data constructor `Subclass'Not in scope: `のメソッドを?..
21:02 shelarcy: あっ、lambdabot がいるから ＞　には大文字を使うべきでしたね。
21:02 msakai: 使う人の立場でも、クラスがたくさんあったら結構うっとおしいかと。
21:03 kazu_: そうですか？ すべての Monad が Functor や Applicative であっても、僕はうっとうしくないと思いますけど。。。
21:03 nwn: Applicative 使って WrapMonad すればいいかなーと > liftM より fmap
21:03 ikegami__: オレオレMonadをつくるとき
21:03 ikegami__: instance ... をたくさんかくのを許せるかどうか
21:04 msakai: たとえば、NumのSuperclassにAddtiveGroup, AdditiveMonoid, MulticativeMonoid, Magma, … とかあったらどうですか?
21:04 ikegami__: (もちろん、法則を満たしていることは、プログラマが証明しなければならないのが Haskell のオキテ
21:05 kazu_: 法則を守るのは作る人ですよね。
21:05 msakai: 数学的にはより正しいけど、僕には結構うっとおしいです。
21:05 itto100pen: そういえば Kleisli triple には関手である制限もなかったような。
21:05 shelarcy: numeric-prelude 「私の出番だな！」
21:05 shelarcy: http://hackage.haskell.org/package/numeric-prelude
21:05 itto100pen: triple の定義には
21:05 msakai: うん。numeric-preludeを念頭に書きました。
21:06 msakai: Kleisli triple の条件から functor の条件が導けたような。

21:06 kazu_: Num のスーパークラスがたくさんあると、使う人は、どううっとうしいのですか？
21:08 nwn: Num のインスタンスを書くと、Num が欲しいだけなのにスーパークラスのインスタンスを何個も書けと怒られる
21:08 nwn: というのが理由
21:09 msakai: 上の例だと、:type (+) としたら (+) :: (AdditiveMonoid a) => a -> a -> a 、:type (-) としたら、(-) :: (AdditiveGroup a) => a -> a -> a と表示されることになるでしょう。
21:09 kazu_: Num のインスタンスは、どういうときに作りますか？ 僕は作ったことはないような。。。
21:09 nobsun: 結構つくりますよ。Num のインスタンス
21:10 nobsun: 1 とか 2 とかを使いたいとき。
21:10 msakai: 覚えなくちゃいけないクラスが増えるだけで僕は結構つらいです。
21:10 kazu_: 1 とか 2 とかって、どういう意味でしょうか？
21:10 shelarcy: data Zero = Zero
21:11 shelarcy: dara Succ a = Succ a
21:11 shelarcy: 見たいな型つくって、
21:11 msakai: よくあるのは有限体のmodulo演算をしたいときとか
21:11 itto100pen: 自然数型
21:11 shelarcy: 1 = (Succ Zero) としたい時とか
21:12 nwn: Num のインスタンス作ってるのではこれが面白かった http://martijn.van.steenbergen.nl/journal/2009/10/18/transforming-polymorphic-values/
21:12 kazu_: うーん。暗号では modulo をよく使うんですが、Num クラスにすると、もっとエレガントに書けるのかなぁ。
21:12 nwn: ようするに、(+) とか (-) とかを DSL 的に使いたいときに Num のインスタンスにするといい
21:15 taninsw: haskell programming tipsにPeano数を作ってgeneligLengthで遅延カウントという話がありましたが、そういう使い道でしょうか<data Zero = Zero
21:19 shelarcy: そういう話がありましたか。使い道は他にも色々とありますが、説明し切れません。> data Zero = Zero
21:13 nwn: ということかも
21:13 kazu_: 分かりました。クラス階層には、ほどよいバランスがあって、最初はそれがわからなかったってことですかね。
21:14 kazu_: 使ってみたら、Monad は Functor のサブクラスの方がよかったじゃんと思う人が多くなった。
21:15 shelarcy: いや、逆じゃないかなぁ？
21:16 kazu_: 逆とは、何の逆ですか？
21:16 shelarcy: 実際に使ってみたら、Gofer のようにサブクラスにしておくよりも依存関係を切り離した方が良かった。
21:17 shelarcy: という意味で逆といいました。

21:16 itto100pen: Functor制約なしでデフォルトのfmap 定義しておくのって無理？
21:17 nobsun: fmapが必要ないなら、実装をかかないというぬけみちはあるけど。
21:17 nobsun: instace Functor f
21:18 nobsun: whereなしで。
21:17 msakai: fmap = liftM
21:18 msakai: すでにMonadのinstanceなら、fmap = liftM とすればいいかと。
21:18 itto100pen: instance じゃない方で。class Monad; fmap = liftM; ...
21:19 nwn: それだと型制約が必要になる
21:19 itto100pen: やっぱり無理か。
21:19 nwn: class (Functor m) => Monad m where fmap = liftM
21:19 itto100pen: 制約ついちゃうね。
21:20 nwn: あーでも kazu_ さんの言ってることってこういうことですよね。
21:20 shelarcy: fmap = liftM とか書きたければ、やっぱり Superclass のメソッドを定義する方法が欲しくなります。
21:20 itto100pen: 「ない方で」と書こうと思ったら最初「内包で」になった。
21:20 msakai: それ、複数のクラスがデフォルト実装を定義していたときに、どれにするか困るから、という理由で却下されていたような。
21:21 nwn: さっき書いたコード Monad と Functor が逆だw
21:21 nwn: class (Monad m) => Functor m where fmap = liftM
21:21 shelarcy: で、どういう文法・機能で実現すれば良いの？　という問題になるわけですが。
21:21 itto100pen: 逆の制約か。
21:22 itto100pen: 制約じゃないか。ともかく逆。
21:23 shelarcy: ここの議論で合意を取るのは時間がかかります。なので、現実解としてとりあえず依存関係を切り離すことにしたのじゃないのでしょうか？

21:24 kazu_: そろそろ、Applicative に行ってもいいですか？
21:24 shelarcy: はい、どうぞ。
21:24 nwn: わーい
21:25 itto100pen: 埋もれたのでもう一回。Pointed って起点付きって訳すの？
21:26 ikegami__: 日本語で読んだことない
21:26 msakai: おなじく。
21:27 itto100pen: pure または return と pointed という言葉が結び付かない。
21:29 snak: 基点は、http://d.hatena.ne.jp/m-hiyama/20090430/1241083671 から取ったんじゃなかったかな
21:30 itto100pen: その基点は別の意味の基点ですよね > snak
21:30 snak: 単に訳語として引っ張ってきただけなので、中身の意味は良くわかってません…
22:02 itto100pen: 基点付きの件 #himaya にて少し納得がいってきました。 > snak

21:24 kazu_: Applicative が副作用を実現できると書いてありますが。。。
21:25 kazu_: これは、Applicative スタイルで sequence みたいな関数が書けるって意味でしょうか？
21:26 nwn: seq [] = pure []; seq (a:as) = (:) <$> a <*> seq as
21:27 kazu_: それです。[IO a] -> IO [a] になるから、副作用が実現できた。わーい。ってことでしょうか？
21:27 nwn: うーん、多分ずれてる気がする
21:29 nwn: seqence が書けるというのと、副作用が実現できるというのは別なような
21:29 ikegami__: うん
21:30 kazu_: すると、副作用が実現できるとは、どういう意味ですか？
21:30 nwn: Haskell は副作用を全て Monad に詰め込む、その Monad は必ず Applicative にすることができる
21:31 nobsun: ああ。副作用について議論するなら、まずは定義をちゃんとやらないと
21:31 nobsun: 話がかみあわなくなるよ。
21:32 kazu_: typeclassopedia で副作用というのは、IO のことだけです。
21:32 ikegami__: というか、副作用ではないですよね
21:33 ikegami__: typeclassopedia では sorts of "effectful" computations と言っていて
21:33 ikegami__: Applicative クラスは "effectful" computation の抽象化ですよと
21:33 ikegami__: (それだけじゃないけど、とりあえず
21:34 ikegami__: そして、Applicative も隠しています
21:35 ikegami__: Monad より弱い制約で
21:35 ikegami__: その弱さが重要（個人的な感想
21:36 kazu_: 本当だ、原文では side effect という言葉は使われていませんね。
21:36 ikegami__: 『原文を読みましょう』
21:37 kazu_: http://www.soi.city.ac.uk/~ross/papers/Applicative.html
21:37 kazu_: このオリジナルの論文では、sequence から話が始まっています。
21:38 ikegami__: はい
21:39 kazu_: この論文の文脈でも、typeclassopedia の文脈でもいいんですが、effectful とは何ですか？
21:39 ikegami__: pure computations じゃない、計算（これではわからんか
21:40 nobsun: 環境への影響
21:40 nwn: Maybe とか Either e とかも effectful
21:40 kazu_: 環境って、ランタイムが動く環境ですか？
21:42 ikegami__: そこも誤解の元だなあ
21:42 kazu_: 一般の命令型言語の人にも分かるように説明をお願いします！
21:44 ikegami__: 状態を持ちまわりながら計算するようなプログラミングで
21:44 ikegami__: そのような状態空間を環境 environment といったりする、のかな
21:44 nobsun: 束縛のあつまり=環境
21:45 nobsun: でどうですか。
21:45 itto100pen: Maybeの状態とは？
21:45 nwn: それは単に 状態の型が Maybe なだけ
21:46 kazu_: State Applicative とか作れますか？
21:46 itto100pen: 状態が Just か Nothing？
21:47 nwn: itto100pen: たぶんそう でも effectful な計算が全て状態を持ち運ぶわけではない
21:48 nwn: Maybe は、どっかで計算が失敗したら全体の計算を失敗させるという "effectful" な計算を抽象化している
21:49 ikegami__: typo... でも "certain sorts of effectful computations" といってるので
21:49 nwn: さっき例として Maybe を出したのはそう言う意味だった
21:49 msakai: こういう論文に出てくる effect というのは普通は computational effect のことで、
21:49 msakai: http://homepages.inf.ed.ac.uk/gdp/publications/Overview.pdf のIntroductionの冒頭くらいのラフなコンセンサスで言っているのだと思います。
21:51 ikegami__: Applicative についてきっちりわかりたかったら、http://www.soi.city.ac.uk/~ross/papers/Applicative.pdf
21:51 ikegami__: を読むのがいいとおもう、Haskell に王道なし―Euclid
21:54 nobsun: 副作用の話はすこし説明を考えます。(ぱっと説明できないのはよくわかっていないからです)
21:56 ikegami__: ぎゃくに、ほわんとわかりたかったら、Applicative の具体例とプログラミングを見ればいいと思う
21:57 ikegami__: Monad がある意味デザインパターンであるようにApplicativeもデザインパターン

21:57 kazu_: effect の訳語はなんですか？
21:57 ikegami__: 混乱を避けるためにエフェクトにすればいいとおもいます
21:58 kazu_: うーん。
21:58 kazu_: カタカナだと、結局分かった気になれないです。
21:58 nwn: 「効能」とかどうでしょう
21:58 nobsun: 効果、影響
21:59 ikegami__: とにかく、手続き型プログラミングではあまり意識しないものです
21:59 nobsun: 意識するんじゃないのかしらん。
21:59 nobsun: 命令型
22:00 kazu_: 効果という概念があって、それは命令型にはない概念なんですね？
22:00 ikegami__: typeclosspedia にもどりますが、「ほにゃほにゃと書いたら、それApplicativeでできるよ！」と書いてありましたよね
22:01 ikegami__: Applicative は idiom だと、作者自身が言ってるので
22:01 ikegami__: おぼえよう、高校英語のように

22:03 kazu_: Applicative で、他に質問はありませんか？
22:03 ikegami__: Applicative の利点とはなにかとか?
22:04 kazu_: 言い忘れましたが、利用例は RWH の Parsec の章を見て下さいね。
22:04 ikegami__: なんで、Applicative で書くか
22:04 kazu_: msakai さんが、コンパイラーに優しいと言っていましたが。。。制約が強いから。。。
22:05 ikegami__: Applicative がわかれば、人間にも優しいですよ
22:05 msakai: コンパイラというかApplicativeのinstanceを書く側かな。
22:06 kazu_: それで、Parsec 3 は Applicative な実装になっているのか確かめたのですが、Instance になっているだけでした。。。
22:08 msakai: あらら……
22:06 nwn: pure な計算と effectful な計算を簡単に混ぜられるのが楽だなーと思います
22:08 kazu_: Monad でいいじゃんという反論には、どう答えますか？ > nwn
22:09 nwn: うーんと、例えば a :: m a で b :: m b って言う計算があったとして、b の結果だけ欲しいと
22:09 nwn: そういうときに a *> b とか書けるのはいいなあと
22:09 nwn: a が欲しいときは a <* b
22:10 kazu_: a >> b と書けばいいのでは？
22:10 kazu_: "<<" って、ないんでしたっけ？
22:10 msakai: a <* b も effect は a, b の順番なのでしょうか?
22:10 nwn: a <* b を monadic に書くと do { a' <- a; b; return b }、少しめんどい
22:10 nwn: msakai: a <* b = const <$> a <*> b
22:10 msakai: なるほろ
22:12 kazu_: do { a' <- a; b; return b } は、間違いですか？ a' を使っていませんが。
22:12 nwn: はう、その通りです
22:12 nwn: do { a' <- a; b; return a' } ですね
22:13 kazu_: あ、効果は a、b の順で、a の結果を返したいんですね。
22:13 nwn: そうですそうです
22:13 kazu_: たとえ、<< が存在していたとしても、意味が違いますね。
22:14 ikegami__: Applicative 元論文にも Sec. 5 Applicative versus Monad? があります
22:14 nobsun: Applicativeって効果の順を表現できるのか。
22:14 nwn: miffy ちゃんと iffy ちゃん問題ですね
22:14 kazu_: お、なんなく、分かってきました。> Applicative

22:16 fubabz: Haskellの歴史的にみて，ApplicativeはMonadより後なのでしょうか？
22:16 taninsw: a b c で bの結果だけ取り出したいときは a >* b <* c ？
22:16 nwn: だと思います。
22:16 nwn: えーっと、やったことないけど結合順位的にだめそう
22:16 nobsun: ずっと後です。Applicative
22:17 nwn: > Just 1 *> Just 2 <* Just 3
22:17 lambdabot:   Just 2
22:17 nwn: あ、いけた
22:17 msakai: 歴史的には Monad > Arrow > Applicative の順
22:17 taninsw: > Just 1 *> Just 2 *> Just 3 <* Just 4 <* Just 5
22:17 lambdabot:   Just 3
22:17 nwn: wwww
22:18 taninsw: 何か面白い……
22:18 fubabz: Typeclassopedia にはMonadの不備みたいなことが書かれていたのでそうじゃないかと思ってました
22:18 kazu_: Nothing を挟むとどうなるんですか？
22:18 nwn: 全体が Nothing になります
22:19 nwn: これが miffy ちゃんと iffy ちゃん問題です: http://www.mail-archive.com/haskell-cafe@haskell.org/msg59077.html
22:19 taninsw: > Just 1 *> Just 2 *> Just 3 <* Nothing <* Just 4 <* Just 5
22:19 lambdabot:   Nothing
22:19 kazu_: > Just 1 *> Nothing *> Just 3 <* Just 4 <* Just 5
22:19 lambdabot:   Nothing
22:20 kazu_: Maybe だと、全体が Just になったときだけ、この場合は真ん中が返されるんですか？
22:21 nwn: そうみたいですね、この使い方は今日初めて見たのでよくわかりませんが
22:21 ikegami__: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html#v%3A*%3E
22:22 ikegami__: (*>) Sequence actions, discarding the value of first argument.
22:23 nobsun: > Nothing *> Just 1
22:23 lambdabot:   Nothing
22:23 nwn: ちなみに a *> b = flip const <$> a <*> b です
22:23 nwn: flip const <$> Just 1 <*> Just 2
22:24 nwn: > flip const <$> Just 1 <*> Just 2
22:24 lambdabot:   Just 2
22:24 kazu_: なんか Lisp の prog1 みたいだ > "<*"

22:24 fubabz: 記事にあるように，みんな本当は「class Applicative m => Monad' m where 云々…」にMonadを置き換えたいのでしょうか？
22:25 nwn: 人によると思います
22:25 fubabz: メリット，デメリット両方ある？
22:26 nwn: うーんデメリットとしてはスーパークラスのインスタンスを書くことを強制されること
22:26 nwn: メリットとしては型階層が「きれい」になることって言うのがあると思います
22:27 fubabz: さっきの話ですね スーパクラス

22:26 kazu_: では、そろそろ Monad に行ってもいいですか？
22:26 nwn: どうぞー
22:27 fubabz: はい
22:27 shelarcy: この調子で行くと、今日中に終りそうに無い気が…
22:27 shelarcy: はい、どうぞ > Monad
22:27 kazu_: Monad で止めましょう。
22:28 fubabz: 遅刻してきたので進行ルールを理解してないのですけど，Q&A方式ですか？
22:28 nwn: fubabz: とりあえず順番に読んでいってその章の疑問を話すって感じです
22:28 kazu_: 疑問点を書いて下さい。
22:28 fubabz: わかりました

22:28 kazu_: 結局、>=> を使って書くと、Monad は Monoid でいいんでしたっけ？
22:29 kazu_: return >=> g = g g >=> return = g (g >=> h) >=> k = g >=> (h >=> k)
22:29 nwn: Haskell の Monoid のインスタンスにはできない、しかし圏論においてはモノイドとみなすことができる、ということだったと思います

22:31 kazu_: 他に質問はありませんか？
22:31 kazu_: 僕はこの章が一番分かりやすかったので、他にはないです。
22:32 nwn: 疑問ではないのですが、Monad を理解した人間は Monad のチュートリアルを書こうとするっていうところがおもしろかったです
22:32 nobsun: そうなんですか？↑
22:32 nwn: s/Monad を理解した人間/Monad を理解したと思った人間/
22:32 kazu_: 説明好きなら、書きたくなりますよねー。
22:33 itto100pen: mappend = (>=>) とか instance 宣言しようとしたらどうなるの？
22:34 nwn: えーっと、mappend :: m -> m -> m, (>=>) :: (a -> m b) -> (b -> m c) -> (a -> m c)
22:34 msakai: 圏論においてはモノイドとみなすことができるというのは、>=> をモノイド演算としてというわけではないです。
22:35 kazu_: なんか、join を二項演算子とみなすと、Monoid と見なせると、読んだ記憶がありますが。。。
22:35 msakai: そうです。 join が演算で return が単位元。
22:35 itto100pen: a b c がそろってないとうまく宣言できない？
22:35 heita: がが
22:36 fubabz: ぼくも「圏論においてモナドは、return、fmap、そしてjoinによって定義されます」という記述に興味をもちました．
22:36 nwn: m = (a -> m b) = (b -> m c) ってやろうとするから a,b,c をそろえないといけなくなる
22:36 heita: それって、定義としてそうだという以外に、実用的な意味はあるんですか? > Monoid としての Monad
22:37 msakai: プログラミング上のメリットは特にないかも。
22:37 heita: or まだ発見されていないと。
22:38 nwn: Monad 則が見やすくなります。僕は Monad 則こっちで覚えてます
22:38 fubabz: >==を使ったMonad規則は，よく見ないとわかりにくいですね
22:39 ikegami__: 可換図という絵で描くとわかりやすい、というひともいる : http://haskell.org/haskellwiki/User:Michiexile/MATH198/Lecture_7
22:40 shelarcy: >=> は 6.8.x で入ったので、これは入れた人の功績だと思います。
22:41 fubabz: 実際に自作のMonadインスタンスをMonad則にあうよう実装する時に楽になる，なんてことはないのでしょうか？
22:42 shelarcy: 6.8.2 http://www.haskell.org/ghc/docs/6.8.2/html/libraries/base/Control-Monad.html
22:42 shelarcy: 6.6 http://www.haskell.org/ghc/docs/6.6/html/libraries/base/Control-Monad.html
22:44 taninsw: さきほどのHaskell Primeのページに、Make join a method of Monad, interdefined with (>>=) とありましたが、 >=> で定義できるようにはしないんでしょうか
22:45 shelarcy: そういう議論はまだ行われていないと思います。 > >=> で定義

22:39 kazu_: 他の質問はありませんか？ > Monad
22:39 itto100pen: monadとmonoidの関係に似たもっとなじみのあるペアないですかね。それがあれば理解しやすそうな。
22:42 ikegami__: なじみのあるペア、で考慮中
22:43 ikegami__: groupoid : http://pantodon.shinshu-u.ac.jp/topology/literature/groupoid.html

22:43 kazu_: すいません。そろそろ僕は時間切れです。
22:44 kazu_: 来月のことを話し合いたいのですが、誰か担当して頂けませんか？
22:44 nakanowatari: Wave で行うというのはありですか？
22:45 nwn: invite してくれるなら
22:45 nakanowatari: invite します。
22:45 ikegami__: アカウントないひとがかわいそう : Google Wave
22:45 kazu_: 逆に chaton じゃだめなのという気もします。
22:45 nobsun: わたしはchatonがいいなぁ。
22:45 nwn: chaton 負荷テスト
22:46 msakai: chatonでいいとは思うけど、Waveも面白そう。
22:46 shelarcy: chaton の利点
22:46 itto100pen: groupoid、よりなじみがなさそうな。
22:46 msakai: って、waveのアカウント持ってないんですが。
22:46 shelarcy: Web 上にログが残る、twitter から投稿できる
22:46 shelarcy: 欠点
22:46 ikegami__: lambdabot がいない
22:46 msakai: lambdabotがいない
22:46 nakanowatari: wave でしたら、現状 30 名くらい invite できますよ。
22:46 msakai: けこーん
22:46 shelarcy: Web 上にログが残る（残って欲しくないことも）
22:47 shelarcy: オフレコとか
22:47 ikegami__: Wave の開発環境と時間さえもらえれば、lambdawave つくります
22:47 itto100pen: fermat の時代に戻って文通
22:47 nwn: のろし
22:48 msakai: 毒電波
22:48 shelarcy: みんなが twitter から投稿すると、API 数の制限に引っかかるかもしれない
22:48 ikegami__: それはある
22:48 nwn: ここまで Lingr が出てない件について
22:48 msakai: たしかに。
22:48 shelarcy: アカウントないです。> Lingr
22:49 shelarcy: （単に面倒くさいだけ）
22:50 nwn: 一応ここからアカウントは作れます http://lingr.com/user/signup?letmein=haskell

22:50 kazu_: すいません。方法はお任せしますので、誰か担当して下さい。
22:50 kazu_: あと、12/5 は友人の結婚式で都合が悪いです。
22:50 kazu_: 12/12 に変えるとまずいですか？
22:51 nwn: 僕は平気ですが、だれかやってみませんか?
22:52 ikegami__: ぼくは途中でダウンした経験があるので、ほんとうにすみません
22:52 nwn: HIMA とか言い出した人としてはやるひとがコロコロ変わるのがいいと思っています
22:53 nwn: ikegami__: 気にしてませんよー :-)
22:53 nwn: そのかわり HAMA の反省として誰か一人ががんばって成り立たせるのはよくないっていうのがあります
22:54 nwn: それじゃあチームを組もうかってなるけど、そのチーム内で力のバランスが生まれると誰か一人に偏る可能性があるのも良くない
22:55 ikegami__: 1d6
22:55 ikegami__: @dice 1d6
22:55 lambdabot: 1d6 => 2
22:55 nwn: !?
22:55 ikegami__: こんな感じで、常連グループが賽をふる
22:55 ikegami__: 「またおれだー」
22:56 nwn: おもしろいけど賽だけふってもw
22:58 nwn: 個人的に nobsun がやったら面白いんじゃないかっていう気がしてます
22:58 nwn: 翻訳者つながりで
22:58 nwn: ... やりませんか?
22:59 nobsun: あら。指名されちゃった。では。
22:59 nwn: おねがいします!

22:59 nobsun: ところでどういう準備が必要ですか。
23:00 ikegami__: アナウンスかな
23:00 nwn: えーっと、1. 日時,場所の指定 2. テーマの設定 3. アナウンス という感じでしょうか
23:00 ikegami__: 12/12(土) の 20:00 - 22:00
23:00 ikegami__: が、前例を引き継いだばあい
23:01 ikegami__: テーマは良くわかりません
23:01 nwn: テーマを決めれるのが主催者の特権です
23:01 ikegami__: なるほろ
23:01 nwn: あと構成も自由にいじれます
23:02 nwn: 発表したり、他の人に発表させたり、etc etc...
23:02 nobsun: テーマは「入出力、副作用、参照透明性をどう説明するか」というのはどう？
23:03 ikegami__: なるほろ
23:03 nobsun: いつも上手い説明のしかたがわからなくなる。
23:03 nwn: おお、「副作用とは何か」などのコンセンサスを取ることのできるすごくよいテーマだと思います
23:03 shelarcy: Typeclassopedia の続きは？
23:03 ikegami__: それは、やりかた出たら Wiki にのこしておこう
23:03 nwn: それは nobsun 権限 > typeclassopedia の続き
23:05 nwn: 言い換えれば主催者権限
23:05 shelarcy: 確かにそうですね。 > nobsun の権限

23:05 kazu_: すいません。コンピューターはこのままで、抜けまーす。
23:05 nwn: kazu_: おつかれさまですー
23:05 nobsun: おつかれさまです。
23:05 shelarcy: お疲れ様でした。
23:05 itto100pen: foldable traversable 変換子 まだやりたいですね。
23:05 kazu_: お疲れさまでした！
23:05 itto100pen: 乙
23:06 taninsw: おつかれさまでしたー
23:06 msakai: お疲れ様でしたー
23:06 fubabz: ありがとうございました＞kazu_
23:07 heita: お疲れさまでした

23:05 ikegami__: http://www.haskell.org/haskellwiki/IO_inside
23:07 ikegami__: IO の説明は HaskellWiki が良く書けてるとおもいます : "Haskell I/O has always been a source of confusion and surprises for new Haskellers."
23:09 nobsun: さっき、どなたかが言ってたけど、命令プログラマは副作用云々は気にしないとういうのはほんと？
23:10 nwn: 「命令プログラマ」というものをそのように定義するなら、その通りだと思います
23:10 itto100pen: 副作用こそpure？
23:11 fubabz: 気にする場面もあると思います．意味がちがうかもしれないけど
23:11 ikegami__: 言ったのはわたしです
23:12 nobsun: 意味はともかく、Haskellの話をするときなぜ、IOとかMonadとかがでてくるのでしょう？
23:12 ikegami__: main :: IO () だからじゃない?
23:12 heita: 最初に hello world を書こうとするから。
23:12 itto100pen: 訳なんですが
23:12 itto100pen: 「もしあなたがMonadの裏にある洞察について理解していなかったとしても、型の導くままに進めば、インスタンスを作ることができます。このことが実際に洞察を理解する長い道のりに繋がっていることに驚くことでしょう。」
23:12 itto100pen: ga
23:12 itto100pen: がよくわからない。
23:13 nobsun: どこ？
23:13 itto100pen: インスタンスを作ることが
23:13 nwn: 「型の導くままに進め」== Follow the types
23:13 itto100pen: 長い道のりにつながる？
23:13 heita: Typeclassopedia では、「洞察」は真の理解とか、イメージの把握という意味で使われているので、
23:13 ikegami__: 副作用について気にしない、といったのは C プログラマで printf の返り値を気にしない人とかそういういみ
23:14 heita: Monad を理解するのには長い時間がかかるけど、型の導くままに進むのがその第一歩だ、という意味では?
23:14 itto100pen: 「長い道のりの第一歩です」くらいがよい？
23:15 nobsun: いつも思うんだけど。いわゆるREPLでためす言語で、Hello, world! って意味ある。
23:15 heita: あー、その話、RWH読書会でもしてたっけ。
23:15 nobsun: なんか変。
23:15 nwn: あんまりないと思うな。factorial を書くほうが自然に感じる

23:15 ikegami__: Hello, world の例は、
23:16 ikegami__: 「プログラムの意味」を取り出す方法が printf 系しかないから
23:16 ikegami__: たいせつ
23:16 heita: K&R では、「Hello world は、言語の使い型(コンパイルの仕方とか、実行の仕方)を理解する方法」として
23:16 ikegami__: でも Haskell は、それ以外にも方法がある
23:16 heita: 最も単純なプログラムの例として、提示されているよね。
23:17 nobsun: そう。42 とか
23:17 nobsun: 6 * 7 とかから始めるのが正解だと思うんだけど。
23:18 ikegami__: それを表示する方法がないと
23:19 nobsun: 表示という行為が、意味にはいっていると？
23:19 ikegami__: いや、初心者プログラマが、意味を知るための方法
23:19 nobsun: そのためのREPL
23:20 nobsun: でも。表示できない値もある。
23:21 shelarcy: REPL 前提なら
23:21 shelarcy: > print "Hello World!"
23:21 lambdabot:   <IO ()>
23:21 ikegami__: IO はむりです
23:22 shelarcy: でも良い気がするけれど。……って lambdabot ……
23:22 nwn: > return 1 :: IO Int
23:22 lambdabot:   <IO Int>
23:22 shelarcy: おとなしく
23:22 shelarcy: > 6 * 7
23:22 lambdabot:   42
23:23 ikegami__: うん
23:23 shelarcy: しかないか…・。
23:23 shelarcy: > "Hello " ++ "World!"
23:23 lambdabot:   "Hello World!"
23:24 shelarcy: なんか非常に人工的な例ですね。
23:26 ikegami__: REPL が信用ならねー、って場面も実際には多いんじゃないだろうか

23:26 nobsun: てな話を次回にしたいな。すみません、私もこれでおちます。おやすみなさいませ。
23:27 shelarcy: おつかれさまでした。
23:27 nwn: おやすみなさいー
23:27 fubabz: ありがとうございました
23:27 msakai: おつかれさまー
23:28 nakanowatari: Wave の Invite については、<hidden> at gmail.com 宛に GMail アカウントでメールくだされば招待リストに追加しますです。
23:29 ikegami__: あう
23:29 ikegami__: Wave のほうが IRC よい利点とか聞きたかったのに
23:30 ikegami__: byorgey とリアルタイム通訳対話できるとか?(ノルウェー語?)
23:30 nwn: mjd
23:30 ikegami__: いや、Google Wave の最初のデモで、英仏同時通訳 Chat してたから...
23:31 nwn: あー、でも日本語はだめそうだよね
23:31 shelarcy: Opera をサポートしてくれていません。 > 悪いところ
23:31 shelarcy: "Sorry, it looks like you're using a browser that isn't supported during the preview of Google Wave."
23:32 nwn: むしろ共同編集とかそのあたりの機能が HIMA 的にはよさそうかもしれない
23:32 ikegami__: ふむ
23:33 ikegami__: たしかに、疑問をひとつひとつ付箋にはりつけて、スレッドがのびていったほうがうれしいな
23:33 nwn: リアルタイム輪読
23:34 nwn: できるかどうかはわからないし HIMA 的かどうかも主催者次第だが
23:34 ikegami__: Google Doc を使えばできるかも
23:35 fubabz: Waveであそぶ方がおもしろくて，Haskell議論が進まなくなるとかw
23:35 nwn: ありそうw
23:37 taninsw: http://gyazo.com/78c0c327dfe254d51878cfca6ede5b27.png 付箋はりつけてく感じは簡単にできそうですね
23:40 himabot: Applicative かわいいよ Applicative
23:41 nwn: いまさっき bot 共を殺したのでとりあえず締めましょう おつかれさまでした!
23:41 shelarcy: おつかれさまでした。
23:41 ikegami__: おつかれさまでした
23:42 fubabz: ありがとうございました
23:44 msakai: おつかれさまでしたー
23:44 taninsw: おつかれさまでした
23:44 itto100pen: 乙かれ様