HIMA #3

hima3.log

nobsun: ここはHaskellプログラミングに興味をもつ人が，とりとめなく，おしゃべりをする場所です。
nobsun: またり部屋も用意してあります。> http://chaton.haskell.jp/matari/
nobsun: そろそろですね。
nobsun: 進行をどうするかちゃんと考えていませんが、「副作用」とその周辺の話題について、とりとめなくやりたいとおもいます。
nobsun: 「副作用がなくてなぜゲームが書けるのか」というところからはじめましょう。
fubabz: こんばんは
kazu: こんばんは。
nobsun: この疑問を誘発しているのは「Haskellは副作用がない」という宣伝だと思っているのですが。そうですか？
nobsun: こんばんは
kazu: そうです。
kazu: 宣伝している方の副作用の意味と、受け取っている方の副作用の意味がかみ合っていません。
nobsun: で、そのとき、副作用＝入出力という図式が受取側にあります？
kazu: 受け側は、Haskell をあまり知らない、命令型プログラマー(OOを含む)だと仮定して答えていいですか？
nobsun: はいそうです。
kazu: 受け側の副作用とは、グローバル変数を変えたり(状態を持ったり)、入出力したりといったことです。
nobsun: これは素朴な疑問なんですが、
fubabz: 破壊代入がない事を副作用がない，と思っているのではないですか
nobsun: グローバル変数を変えることと、入出力とはどこで結び付いているのでしょう。
kazu: それが状態って意味です。> fubabz さん
nobsun: 状態がない＝副作用がない？
kazu: 命令型プログラマーの言う副作用とは、同じ引数を与えたときに、異なる値を返したり、値を返すこと以外に仕事をしたりすることをいいます。
nobsun: 命令プログラマにとっても、値を返すことが計算の目的という感覚があるんでしょうか？
fubabz: 命令型にも関数はありますから，副作用の概念もあります
kazu: いいえ。ただ、副作用のない関数は、同じ値を与えたときに、同じ値を返し、しかもそれ以外のことはしないと教わります。
kazu: なので、printf なんかは、副作用(出力)があり、もっぱら副作用の方を使うと説明します。
kazu: なので、printf に関して言えば、目的は副作用です。
nobsun: もし、printfが常に0を返す関数であっても、コンソールに変化があるので副作用というわけですね。
kazu: そうです。
kazu: printf は、出力した文字数を返します。
nobsun: ということは、副作用がないということと参照透明性とは別のこと。
kazu: printf("Hello\n") は常に6を返します。しかし副作用があります。
fubabz: 自分はそう感じていました＞nobsan
kazu: nobsun さんのいう参照透明性の意味が分からないので、答えられません。
nobsun: ああ。わざと曖昧にしているのですが。逆に命令プログラマは参照透明性ということを気にするものですか？
kazu: 僕の最近の結論を先に言わせて頂くと twitter に書いた通り、Haskell に副作用がないと表現するのは、命令型プログラマーにとっては誤りです。
kazu: Haskell には、入出力(という副作用)はあります。でも、状態(という副作用)はありません。
kazu: Haskell の入出力という副作用を表現する型は IO です。
kazu: IO 型から純粋な関数は呼べますが、純粋な関数から IO は呼べません。(unsafePerformIO は除く。)
nobsun: つまり、副作用はないけど、入出力は表現できるという表現は、良くないということですか？
fubabz: 参照透過性は純関数型プログラミングの基本なので，命令型の中にいるかぎりでは，気にしないですね
kazu: よって、Haskell では、入出力という副作用を持つコードと純粋なコードを完全に分離しています。ここが大切です。
kazu: 純粋な関数の部分は遅延するけど、IO の部分は順番が決まっています。
kazu: で、ここまで命令型プログラマーに分からせることができたら、状態がないのにどうやってプログラムを書くのかということを分からせてあげればいいと思います。
nobsun: 遅延しても順序は決っているという説明ではだめですか。
metanest: 命令型の世界にいても、最適化で不変式としてループの外に出せるかどうかが違うから参照透過性は気にするかな？　私の場合
kazu: 発想を変えると状態がなくなる問題も多いし、引数に状態を渡して行けば、グローバルな状態なんていらないよと。
kazu: 引数で与えるのが面倒なら、State モナドもあるよと。
nobsun: その場合、参照透明とはどういう意味で使っているのですか？
kazu: 遅延しても順番は決まっているというのは、何を指してそういっているのですか？ > nobsun さん
kazu: IO ですか？ 純粋な関数ですか？
nobsun: IOと純粋な関数の区別をそもそもしていないんです。
nobsun: 値の依存関係を持ち込めば順序を指定できますよね。
nobsun: foo . bar
fubabz: 順番を決定的にするための>>＝の事じゃないでしょうか
kazu: はい、できます。
nobsun: は、bar の計算が先で、fooがあと
nobsun: foo (bar x) でもいいですが。
kazu: 「遅延しても順序は決っているという説明」と言われましたが、多くのチュートリアルでは「遅延評価では順番は決まっていない」と説明されていますね。
kazu: 遅延評価は順番が決まらないので入出力と相性が悪いと書かれています。
kazu: そもそも、この説明は間違いなのでしょうか？
nobsun: 順序が決ってないのではなく、解らない、あるいは解りにくいという説明になっていませんか？
mad: 横から失礼します。こんばんは。
kazu: 解らないとは、どういう意味ですか？ 決まっているなら、分かるでしょう。。。
nobsun: 出現順序が計算順序を反映しないという説明ではないでしょうか。
mad: foo (bar x)では一般的にfooの評価が先です
fubabz: 順番が決まらないと外界と作用できなくなるので，Haskellではモナドで解決したと理解しています
nobsun: fooの評価がさきですが、作用はfooが後です。
kazu: fubabz さん、その理解が正しいとしても、その説明(これまでの典型的な説明ですが)がよくないと思います。
kazu: 命令型の人には、さっぱり分からない説明になっています。
kazu: 繰り返しになりますが、Haskell には副作用を扱う型 IO があって、そこは順番が決まっているという説明がいいと思います。
kazu: これならモナドを持ち出す必要はありません。
fubabz: それで納得しますか？
kazu: そして、謎は状態がないのに、どうやってプログラムを書くのだろうという一点になります。
nobsun: はい、そこへ誘導できるといいと思っています。わたしも
nobsun: 。
kazu: 多くの人は、それですんなり理解できると思いますよ。> fubabz さん
fubabz: 自分は理解できなかったのでモナドにはまって苦しみました
nobsun: Haskellerはなんとなく納得できないかも。
kazu: 納得できない人がいるとすると、これまでさんざんモナドとか言われたけど、理解できなかった人が、この期に及んでそんな説明をされても。。。というパターンじゃないでしょうか？
kazu: Haskeller は、どうして納得できないのですか？ RWH でも、こういう説明でしたよ。
nobsun: 「順番がきまっている」というのはIOの特権ではないからです。
nobsun: ああでもちがうな。
kazu: 遅延評価では順番が決まらないけど、入出力はIOモナドによって順番が決まるって最初に説明をされたら、だれでも理解できず、モナドで苦しむのではないでしょうか？ > fubabz さん
fubabz: 他の人はどうかわかりませんが，自分はできるだけ関数型らしく書きたいというのがあるので，モナドにこだわりました
kazu: 僕は Lisp を 15 年ぐらいやってから Haskell に入りましたが、「関数型らしい」とはまったく分かってなく、「関数型らしい」ということを知りたくて Haskell を学び始めました。
fubabz: まぁ，自分はそのひとりなので，今更ムダだといわれてもこまりますけど
nobsun: IOモナドと言わずに、IOとだけ言っとけばよかった。？
kazu: はい。> nobsun
nobsun: わたしも。そう思う。
kazu: モナドという言葉を出すなら、100ページぐらい紙面を取って、徹底的に解説すべきです。
kazu: そうでないのであれば、モナドという言葉は出さない方がいいでしょう。
kazu: 「ムダ」って何を指していますか？ > fubabz さん
fubabz: 「入出力はIOモナドによって順番が決まるって最初に説明をされたら、だれでも理解できず、モナドで苦しむのではないでしょうか」←これを私がやったのですが，否定されましたから
fubabz: もっといい近道があればよかった，といういみです
kazu: 僕も、同じ道でしたよ。
kazu: 他の人に同じ道を通れとは言いたくないのです。
nobsun: でも、IOモナドをIOに変えてもあまり本質は変らなくないですか？
kazu: それは、Haskell を理解しがたいものにしてしまいますし、ひいては Haskell の普及も阻害するような気がしています。
kazu: 本質は説明の仕方を大胆に変えましょう。ということです。
nobsun: モナドという概念が余分に入る分、わかりにくくしているのか。
kazu: Haskell には IO という型があって、それは副作用を扱う型で、順番が決まっている。
fubabz: そうですか．足をひっぱってすいませんでした．しばらくROMします
kazu: そう言ってもらえるだけで、Haskell が分かった気分になれると思うのです。
kazu: いえ、いろいろ突っ込んで下さい。 > fubabz さん
nobsun: つっこみよろしくです。> fubabz さん。
kazu: みんなが納得して、統一感のある説明をするようにしないと、Haskell が普及しないと思うので。
kazu: ところで、nobsun さんは、Haskell は表現しているだけだから副作用がないっていう発言をよくされますね？
nobsun: 状態がないのに、なぜ入出力が表現できるか？
nobsun: というところに移りましょうか。
kazu: 状態がないのに、なぜ入出力かではなく、状態がないのに、どうやってプログラムを書くのってことではないですか？
nobsun: ああ、なるほど。
kazu: もう一度書きますが、ところで、nobsun さんは、Haskell は表現しているだけだから副作用がないっていう発言をよくされますね？
nobsun: はい。
kazu: もしそれが正しいなら、Java にも副作用はないと思います。Java でも何がやりたいか、表現しているだけですよ。
nobsun: それは、ランタイムを考えていないからです。
nobsun: 私の場合は。
kazu: ランタイムを考えないなら、Java にも副作用はないですね？
nobsun: いえ、変数の値を変えるという表現が含まれているので、副作用があります。
kazu: Hello World の Java プログラムにも副作用があるんですか？
nobsun: 私にとって副作用は、同じスコープで変数の値を変更することです。
nobsun: Hello WorldのJavaのプログラムに副作用があるとは思いません。でもJavaという言語には副作用があると思っています。
nobsun: ああ。でも一貫していない気がしてきた。
kazu: nobsun に分かって頂きたいのは、Java の Hello World のプログラムには、副作用がある(というか入出力という副作用しかない)と世間の人は考えているということエス。
kazu: そういう人たちに Haskell を普及させようという場合に、nobsun さんの言葉は通じないと思います。
nobsun: そう思うようになりました。ので、今回のお題というわけです。
nobsun: :)
kazu: 僕の観察したところでは、nobsun の副作用の意味は、世間の副作用の意味とは違うので、nobsun さんは副作用という言葉を使わない方がいいのではないでしょうか？
kazu: 自分のいいたいことは、別の言葉を使って説明するといいでしょう。
kazu: 人に「Haskellには副作用があるのか？」と聞かれたら、「副作用の意味が分からないので答えられない」というか、彼らの副作用の意味を受け入れて「ある」と答えるかの、どちらかがいいと思います。
nobsun: はい。了解。
nobsun: おそらく。状態というところでも同じことがおこります。
kazu: Haskell には状態はないと思っていますが。。。
taninsw: こんばんわです
kazu: こんばんは。
nobsun: 状態がないのに副作用があるんですか？
taninsw: ランタイムがIOを扱うのを副作用と呼ぶのなら、ランタイムには状態もあるのでは、とか。
nobsun: ああ。また副作用といっていまった。
kazu: 「状態」で起こりうる同じこととは何ですか？
nobsun: 意味が一般の命令プログラマとは違うということです。
nobsun: おそらく。
taninsw: Stateモナドがあるのに状態がないとはどういうことか、とか？
kazu: 繰り返しになりますが、一般の命令プログラーが言う副作用とは1)入出力と2)状態です。
nobsun: はい。
kazu: Haskell は 1) はありますが、2) はありません。と僕は思っています。
kazu: nobsun さんの状態という意味が、他のプログラマーの状態と違うとは思えないのですけれど。。。
kazu: State モナドは、単に裏で引数を渡しているだけですね。> taninsw さん
nobsun: そうかもしれない。
nobsun: 状態は表現できますが、状態はありません。という言い方はどうですか？
kazu: あー、出た。「表現」！
nobsun: ああ。これか。
taninsw: それはそうですが、状態という概念を扱ってるのには変わりはない、と見る事もできる、と思います。
kazu: 命令型プログラマーは、たとえば for 文がないのにどうやってループが書けるの？ と思っています。
kazu: これに答えるのは簡単ですよね？
kazu: 状態はないけど、状態をエミュレートできると僕は説明します。> taninsw さん
nobsun: プログラムの話と、プログラム言語というメタな話が混乱しているかも。
taninsw: 言語仕様として状態は無いが、エミュレートする事で、状態を扱える、という理解です。前者の状態は「識別子と値の束縛」という狭義の意味で、後者の状態は、設計的に見た広義のものです。
nobsun: 状態がなくてプログラムが書けるか？は前者の意味ですよね。
kazu: そうでしょう。> 前者
nobsun: 状態とは変化するものですよね。
taninsw: だと思います。ただHaskell初心者は誤解するかも、と。
kazu: そうです。
nobsun: ということは、変化しないものとの対比がある概念ですよね。
kazu: そうです。
nobsun: もし、束縛関係が変化しないなら、状態はないといっていいですよね。
kazu: いいんじゃないですか？
nobsun: 重箱のすみですが、「識別子と値の束縛」は変化がないなら、状態とは言えない。
nobsun: ああ。ほんとに重箱のすみだった。
taninsw: 前者の定義にのっとればそうだと思います
kazu: 命令型の人には、発想を変えると状態がなくても多くの問題は解けることと、どうやって状態をエミュレートするかってことを教えてあげればいいと思うです。
kazu: Haskell で 2 年ぐらいプログラムを書き続けていると、本質的に状態を持つ問題の例を挙げる方が難しくなってきます。不思議だ。
nobsun: そうだと思います。
nobsun: 状態がないので、そもそも問題を状態(の変化)として捉えることがなくなるんですよ。
kazu: だから、State モナドの利用例を説明するのが難しくなります。。。
nobsun: つまり、状態がないのにどうやってプログラムするという疑問を解決できたというより、そもそも状態を使って解決するという発想がなくなるんです。
taninsw: 自分は万年初心者なので分からないのですが、どういうエミュレートのパターンがありますかね。再帰で状態変数を持たせて回す？
nobsun: いえ、単に引数と、結果に状態を追加するだけです。
taninsw: GUIアプリケーション等も自然にそう設計できるようになりますか？
kazu: 僕がエミュレートといったのは State モナドのことです。
kazu: 現状では、GUI プログラムを書く場合、C ライブラリにバインドするので、C ライブラリが状態を仮定している以上、Haskell でも State モナドを使うことになると思います。
taninsw: なるほど
kazu: Yi っていう Haskell で書かれたエディタがあるのですか、これはどうやって実装されているのでしょうね。
kazu: maoe さんが興味を示されている FRP を学ぶと、IO が絡んでも、もっと関数的に書けるんでしょうか？
kazu: http://d.hatena.ne.jp/maoe/20091121/1258773681
kazu: たとえば、for がなくてプログラムが書けるの？っていう質問への答えは、ここに書いています。
kazu: http://www.mew.org/~kazu/material/2008-haskell.pdf
heita: 今日は人が少ないのかな?
nobsun: よりfunctionalにというのは、どういう感覚ですか？
kazu: その感覚を身につけたいと思っているだけなので、習得できてない今、どういったものか想像も付きません。
kazu: ただ、The Haskell School of Expression は読みましたので、その延長上にあるとすると、宣言的な DSL なのかなぁとは思います。
heita: liftIO を頻繁に挟み込んだり、unsafePerformIO しなくて、という意味だと推察……
kazu: ちなみに、Haskell でネットワークのコードを書いていると、do ばかりで、命令型言語と変わらないなぁという感じです。。。^^;
kazu: あー。僕は最近 IO に関して悟りを開いたので、unsafePerformIO は要らなくなりました。> heita さん
kazu: この悟りは、難しくて説明できません。
nobsun: そこをなんとか、言葉に。
heita: Erlangのプログラムみたいに、メッセージとそれに対応する処理だけを記述するような DSL っぽいものがあって、IO と処理記述が分離されるような構造になるのがいいと思う。ちょっと、実際に書いてみないと、うまくいくかどうか判らないけど。
kazu: うーん。たとえば、サーバーを書くとします。
kazu: 通常のモードでは syslog に、デバッグモードでは stderr にログを吐きたいと思うでしょう。
nobsun: はい。
kazu: main では、"-d" オプションを optDebug みたいなものにパースして、これをグローバル変数として読みたくなるので、unsafePerformIO とかつかちゃってました。
kazu: optDebug を参照しているところでは、if optDebug then return () else initSyslog とか、if optDebug then hPutStr xxx else syslog xxx とかしたくなるわけです。
kazu: でも、IO はファーストクラスなので、main のみで optDebug を参照し、そこで Config を作成する訳です。Config { init = initSyslog, writeLog = syslog } とかです。
kazu: これを渡して行けば、optDebug を下位の関数で参照することはなくなります。
nobsun: MonadReader ?
kazu: こういうことを突き詰めて行くと、うまく説明できませんが、深く Config を渡す必要はなくなったので、unsafePerformIO は要らなくなりました。
kazu: ReaderT と IO を合成すると、liftIO ばかりになって、プログラムを書くのが嫌になります。なので、使いません。
nobsun: 明示的に渡す？Config
kazu: あくまで、Config を必要な関数の引数として渡しているだけです。でも、関数Aが必要とする情報はこれ、関数Bが必要とする情報はあれ、という風に分割できるようになるので、深く渡す必要がなくなって(ここはうまく説明できない)、コマンドライン引数を全体から参照する必要はないやって、気分になれました。
kazu: あー、なんか説明できる気がしてきた。
kazu: 今までのサーバーのコードは、main から深く深く命令が連なっていました。それを、ライブラリにできるところは、すべてライブラリにしたんですよね。
kazu: すると、main では、ライブラリに渡す IO を組み立てて、そのライブラリに渡すことになります。
kazu: 今までは、ライブラリの先に、その IO があった訳ですが、今はライブラリと、その IO は同じレベルにあります。だから、ライブラリに ConfigA と、ConfigB を部分適応した IO を渡すので、ConfigX を深く渡している気分じゃなくなったのでした。
kazu: 分かるかなぁ？
nobsun: むむ。
nwn: 部分適応
nwn: ってなんでしょうか
sakai: 部分適用のことでは。
kazu: runNetworkServer :: Config -> IO () -> IO () という汎用的なネットワークサーバーライブラリがあるとします。(select() の壁を越えるための。)
kazu: で、runWebServer :: WebConfig -> (Request -> IO Response) -> IO () という Web サーバーライブラリがあるとします。
kazu: で、webServer :: Request -> IO Response という Web サーバーを書いたとします。(200 とか 404 とか返すコード)
kazu: こうしておくと、main から
kazu: runNetworkServer cnf (runWebServer webCnf webServer)
kazu: とか書けるんですよね。
kazu: cnf と webCnf は、コマンドライン引数から main で作成します。
kazu: こういう風にライブラリ化してないときは、runNetworkserver の向こうに runWebServer があって、深くて、引数を渡して行くのは嫌だなぁと思っていました。
kazu: 今は、main から両方にほいって渡すだけって気分になれました。
kazu: こんな感じなんですが、分かります？
nobsun: その悟りを得たあとから、元のunsafePerformIOを使いたかったときの感覚はどういうものに見えますか？
heita: 外界(config)に依存していた関数を、引数で渡される情報(config)だけに依存する純粋な関数に書きかえたってことですか。
kazu: IO がファーストクラスという意味と、高階関数の使い方を分かっていないやつだった。ですかね？
kazu: そうですが、高階関数で深い部分を浅瀬に引き上げたとうことです。> heita さん
kazu: その内、今作っている Web サーバーは公開します。
kazu: www.mew.org の Apache を置き換えたあとになりますけどね。
heita: おー、mew.orgを支えられる品質のものになるのですか。すごい。
kazu: 速度的には、Apache と遜色内ですよ。ベンチマークによれば。。。
kazu: 今は、必要な機能を付けて行っているところです。
kazu: 話題を変えてもいいですか？
nobsun: はい。
heita: 副作用に?
kazu: 関数プログラマーが言う、参照透明性と effect の意味を教えて下さい。
heita: 参照透明性は、変数の状態(bind)が常に変わらないこと(?)
nobsun: 参照透明性はすこしわかりにくいです。本来の意味は、「等しいものを等しいもので置き換えても意味は変らない」ということをなりたたせる条件です。
heita: おー、失礼。
nobsun: 参照透明の議論をしたペーパーがあったのですが、sakaiさんが読んでいたとおもいます。なんというペーパーでしたっけ > sakai さん
nobsun: Harald Søndergaard and Peter Sestoft
nobsun: effect の方は私もよく掴めていません。外界への影響という意味かなぁと思っていますが。。。
sakai: 参照透明の議論をした論文のURLを一応はっておきます。http://dx.doi.org/10.1007/BF00277387
sakai: effectはちゃんとした定義は知らないけど、値以外の意味の総称だと思ってます。
nobsun: 「値」以外の「意味」ということは、Oprationalな意味ということですかねぇ。
kazu: 値以外には、たとえば何があるのですか？ > effect
nobsun: 副作用！？
sakai: 副作用とか非決定性とか。
sakai: 非停止性なんかもeffectと考えることあり。
nobsun: では、effectual computation というのは？
sakai: それから、例外とか大域脱出とかもか。
nobsun: ふむふむ control か。
sakai: effectual computation は文字通り effect を持つような計算じゃないのかな。
sakai: どっかででてきた用語?
nobsun: Applicative の記事
sakai: あ、Chatonにあるこれか。
nobsun: そう。
sakai: やっぱり、effectを持つような計算でいいと思う。
nobsun: ふむふむ。
sakai: ただ、あまり気にする必要はないとは思うけど、computationは少し特殊なニュアンスがあるかも。
sakai: Moggi の Computational lambda-calculus and monads あたりの話では value と computation の区別が大事で、そこでの意味が念頭にあると思うので。
nobsun: WadlerとかもMonadはComputationを表現するというようなことを最初いっていたのはそこが大元ですかね。
sakai: うん。Moggiが大元だと思っていいと思う。
sakai: 一応、URLを。
sakai: http://www.disi.unige.it/person/MoggiE/ftp/lics89.pdf
sakai: http://www.disi.unige.it/person/MoggiE/ftp/lc88.pdf
nobsun: ありがとうございます。
sakai: まったくもって、プログラマ向けではないけれど……
nobsun: さて、22時になりました。ひとまず HIMA 3終了を宣言しておきます。この場所は明早朝5時ごろまでは、このままにしておきます。参加していただいたみなさまありがとうございます。ROMのみなさまもありがとうございます。
sakai: お疲れ様でした～
nwn: お疲れさまでしたー。
shelarcy: おつかれさまでした。
taninsw: おつかれさまでしたー
kazu: 遅くなりましたが、お疲れさまでした。

matari.log

nobsun: ここはHaskellプログラミングに興味をもつ人が，まったりと，おしゃべりをする場所です。
nakanowatari: テストです。
[1..100]>>=pen: 今起きた。間に合った。食糧買ってきます。
nobsun: あらら。逆転生活ですな。
sakai: もうすぐHIMAだけど、ご飯を食べに行ってこよう……
kazu: 読み始めました。
ltakeshi: こんばんわ
nobsun: こんばんわ
ltakeshi: HIMAの方は議論が白熱してて、ただのxmonadユーザには手が出せなくて
ltakeshi: なんとなく傍観中です
nobsun: いえいえ、どんどんわりこんでくださいな。
nobsun: xmonadの使いごこちはいかがですか。
ltakeshi: 悪くないです。
ltakeshi: 慣れてしまうと戻れなくなってしまうのが困り者です。
ltakeshi: 個人的にはもう少し日本語の情報が増えるとユーザが増えないかなと思ってはいるのですが > xmonad
nobsun: フロートするのが前提のアプリケーションのとき使いにくくないですか？
[1..100]>>=pen: xmonadってタイル型だったのか。
nobsun: たぶん、[1..100]>>=pen さん向き
ltakeshi: 基本shell+firefox(opera)+audacious程度で生きてる人間には割と楽です。
[1..100]>>=pen: タイルいっぱい出すと１枚当たりの面積は小さくなります？
metanest: 超漢字版があるとか？ (ぉ
nobsun: いやそれは [1..100]>>=pen まちでしょう。
ltakeshi: まぁタイルいっぱい出すと減りますが、減らさない方法もあります。
[1..100]>>=pen: 「面積小さくなる」って表現かたいかった。狭くなります？だな。
[1..100]>>=pen: どうやるんですか？減らさない。
nobsun: でもすくなくとも余白がないぶん、もったいない感はないとおもう。
ltakeshi: たしかtab
ltakeshi: みたいな感じのレイアウトが設定できたはずです
[1..100]>>=pen: タイルといっても分割だけじゃないんですね。
[1..100]>>=pen: それはいいかも。
ltakeshi: http://haskell.org/haskellwiki/Image:Arossato-config.png
ltakeshi: こんな感じです。
ltakeshi: 上の方にtabがあるのが分かるかと。
[1..100]>>=pen: 他のウィンドウマネージャのスクリーン切替えにあたるようなものですね。
sakai: tabは面白いですね。
ltakeshi: そのようなものだと思います。ただ、仮想スクリーンも存在しているので、私は主にそちらを使っています。
ltakeshi: s/スクリーン/デスクトップ/
nobsun: 私は軟弱なので、gnomeの中で使ってます。xmonad
taninsw: あちらがわで、既に流れているけどもIOと順番の話があったので、とりあえず自分の理解を。
taninsw: 「(ちゃんと結果が返されるときは)評価順序に限らず必ず同じ結果が出るのは保証されている、だから評価順序なんて気にせず宣言的に表現を書きなさい。」というポリシーがまずある。
taninsw: 「でも、それじゃIOつらいよね。だから評価順序はやはり無視できない。ちなみにHaskellは最外最左簡約。順番はちゃんと決まってる。さあ頑張れ!」というのは、まあ可能なんだろうけど正直ツラいので、制約(unsafeな関数を使わない)の下で順番を保証する仕組みを作っといた。それがIOモナド。
taninsw: こんな理解でいいんでしょうか
nwn: 簡約と評価ってどう違うんでしょうか? 僕にはその違いがわからないので、せっかく評価順序を気にしないようにしたのに、こんどは簡約のやり方を気にしろ、というのは意味がよくわかりません。
[1..100]>>=pen: 次のRWH本読書会いつ頃になりそうですか？
nobsun: cut-sea いる？
sakai: 簡約は式の変形のこと、評価は式からそれが表す値を計算すること、かな。
taninsw: いや「簡約のやり方を気にしろ」というのは正直ツラいのでIOモナドで隠蔽したという意味です。
taninsw: IOモナドを作った(そしてunsafeを使う人だけが気にすればいい
nwn: IO モナドを作るってどういうこと? instance Monad IO を書くことですか? それとも具体的な IO を組み立てるってこと?
taninsw: instance Monad IO を書くことです。
taninsw: IOモナドの中身を見たことはないので、ただの想像ですが
nwn: ふむ。なるほど。taninsw さんのいってることが何となくわかってきました。もうちょっと自分でも考えてみます。
sakai: そういえば、11月はRWH本読書会やらなかったんでしたっけ。
nobsun: Haskell Nightがあったので。:)
sakai: そういばそうでした。
sakai: そういえばそうでした。
sakai: そして、12月にはHaskell忘年会。
[1..100]>>=pen: RWH本読書会は今月はなしですかね。
[1..100]>>=pen: 今月はない方がイベントが多いので助かります。
[1..100]>>=pen: 来月までにeratta増やしておけますし(w
sakai: ちょっw
[1..100]>>=pen: 2刷で修正が決まった後からいっぱい報告(w
[1..100]>>=pen: 細かいことですが「おこなった」は「行なった」ですか、それとも「行った」ですか？ > nobsun