関数型プログラミング言語Haskell Part9

1 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 16:41:29 ] haskell.org www.haskell.org/ 日本語サイト www.sampou.org/cgi-bin/haskell.cgi www.shido.info/hs/ 過去ログ 関数型プログラミング言語Haskell Part1 pc.2ch.net/tech/kako/996/996131288.html Part2 pc2.2ch.net/test/read.cgi/tech/1013846140/ Part3 pc8.2ch.net/test/read.cgi/tech/1076418993/ Part4 pc8.2ch.net/test/read.cgi/tech/1140717775/ Part5 pc8.2ch.net/test/read.cgi/tech/1149263630/ Part6 pc11.2ch.net/test/read.cgi/tech/1162902266/ Part7 pc11.2ch.net/test/read.cgi/tech/1174211797/ Part8 pc11.2ch.net/test/read.cgi/tech/1193743693/ ・2chの仕様により、行頭の半角スペースは表示されません。 　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。 381 名前：デフォルトの名無しさん mailto:sage [2008/08/08(金) 14:34:11 ] >>379マジだ ttp://www.amazon.fr/dp/2841771210/ フランスでは流行ってるんだな 382 名前：デフォルトの名無しさん mailto:sage [2008/08/08(金) 14:42:46 ] 感覚的には日本のRubyと同じ感じじゃないすかね。 383 名前：デフォルトの名無しさん mailto:sage [2008/08/08(金) 16:16:02 ] >>381 いつの本の話してんだか。 この本の和訳プロジェクトはつぶれたね。 384 名前：デフォルトの名無しさん mailto:sage [2008/08/08(金) 19:15:39 ] >>382 全然違う。Rubyは世界的にPythonを急追している。 385 名前：デフォルトの名無しさん mailto:sage [2008/08/08(金) 23:55:14 ] 急追して、、いたけど結局ダメだった、というのが現在のところだよ 俺も1.9がちゃんとしたモノになるまではrubyは使うべきではないと思う。 386 名前：デフォルトの名無しさん [2008/08/08(金) 23:59:16 ] そうか？ そもそも本当に10月に発売できるか分からんぞ。 387 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 00:21:55 ] コレすでに3回発売日伸びてる 年内出れば御の字 388 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 00:33:37 ] >>385 それがほんとかなぁ。とおもってgoogle trendsでruby,python,perlの検索数を比較させて みたけど、国によって微妙に違うね。 usaなら、2006ねんごろからperlが凋落しきって、python,rubyとならんで、2006中頃から、 rubyが一歩抜けて、perl,pythonが同等になっていた。 italyは、同じような時期にperlが落ちてきてるけど、pythonがかなり強くって、perlとruby が同等 japanが、perlの凋落が進んできてるけど、usaやitalyほどではなくて、一番ですね。2番め がrubyで徐々に増えてる。pythonは完全に横ばい。 chinaはpythonの伸びがかなり強い。そんなにrubyは使われてない。 indiaは日本と傾向が似てるな。 israelはrubyは絶滅ぎみ。 google全体ではrubyが一番強くなってきてるけど、これはusaでのruby人気が支えてる ような感じだな。europaとchinaではpythonが強く、それ以外の国ではperlが強いかな。 389 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 04:23:59 ] >>384 世界的にみても、わかって言語を選んでいる人よりも バズワード追ってるだけの人のほうが多いからね。 390 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 06:09:31 ] Haskellって本当にLLって言っていいのかな。 基本コンパイラだし、インタプリタも軽量とは言い堅いし。。。 391 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 06:13:31 ] LLじゃないだろw 392 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 08:06:03 ] > 基本コンパイラだし GHCばかり取り上げられてHugs涙目 393 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 08:07:11 ] >>392 そんなあなたをはぐはぐ。w　あーっ！ではないよ。 394 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 08:22:00 ] 初心者なんですが、Haskellが型については静的であることを選択した 理由って何かあるんでしょうか。純粋であることや遅延評価が、静的 型やコンパイル時の最適化を要請するということなんでしょうか？ 395 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 08:27:55 ] GHCはHaskell解釈系ランキング第一位！ 「やっぱりGHCだね」 396 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 09:06:49 ] >>394 静的なのは、最適化も大きいだろうけど、 むしろ安全性を狙ってるという要素が大きいんだろう。 遅延評価なのはコンパイル時の最適化にプラスなのかなぁ？ これは理論的に停止できる関数は必ず停止できるっていう、 これまたある種の安全性？が主な目的だと思うけど ( if true (answer foo) (nonStop baa) ) みたいな文を考えよう（Haskellの文法忘れたから適当）。 397 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 10:14:15 ] 別に"動的型付け-純粋-非正格-インタプリタ型"の関数型言語もあり得るよな 効率はどうなんだろう、"動的型付け-正格"の言語よりさらに遅いことは想像が付くが 398 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 10:28:23 ] >>394 Goferがそうだったから。 で、なんでGoferがそうだったのかというと、Mirandaがそうだったから。 399 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 10:37:45 ] >>396 遅延評価は最適化にマイナスだよ。少なくともメモリ空間の最適化には全く向かない。 400 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 10:44:26 ] 遅延評価なんて 今日はやらない 401 名前：396 mailto:sage [2008/08/09(土) 10:50:37 ] >>399 そうだよね。 コンパイル技術がすげー発達して高速になれば、話は変わるだろうけど。 （まぁ、コンパイル技術が「すげー発達」すれば、どのコンパイル言語でもマシン語と同じスピードが出るんだから、意味ない話） あと「理論的に停止できる関数は必ず停止できる」は意味不明だとか、 文じゃなくて式だとか、気づいたけど後の祭り、いわゆるアポステオリorz 402 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 11:02:51 ] >>395 Guarded Horn Clauses 403 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 11:31:02 ] 手続き型言語は、ノイマン型計算機を抽象化することで生まれてきたので、 評価方式としては、式、文の逐次的解釈が当然になる。 関数型言語は、ラムダ式から出て来たから、 その評価形式をどうするかというのが一つのポイントになる。 遅延評価は最左最外簡約の研究から出て来た。 効率がどうのこうのというより、 新しいプログラミングパラダイムを産み出したので、 (例えば無限リスト、無限木の積極的利用) 研究され続けているんだと思う。 404 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 11:32:55 ] >>402 GLOBAL HONORED CROWN www.noah.co.jp/ghc.php 405 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 11:37:31 ] 関数型とか意味がない言語だと思うけどねぇ 何ができるってわけでもないし HaskellでWindowsは作れないしLinuxも作れない Webサーバも作れないしDBも作れない 意味がない 406 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/09(土) 11:44:54 ] >>405 www.thenewsh.com/~hws/ 407 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/09(土) 11:45:52 ] ごめん、今からインディージョーンズ見に行くから急いでるから！ 408 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 11:47:37 ] まあ普通はモデルを現実に合わせるよな。 代入だらけのプログラムをSSAとかいう形式に変換するとか。 409 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 11:48:09 ] >>394 純粋関数型言語・遅延評価で、 型なし・インタプリタ言語ってあるよ。 変態言語 Lazy K がそれ。 ある意味では Make とかもそうかも。 少なくとも、 純粋関数型言語・遅延評価と、 コンパイル言語かインタプリタ言語か っていうのはあまり関係ない。 純粋関数型言語・遅延評価は、 シンプルな手続き型よりもインタプリタを書くのが難しい、 っていうのはあるかもしれないけど。 純粋関数型言語であることと静的型であることは、少し関係があるかも。 純粋関数型言語でかつ動的型というのは、概念的にあまり良い食い合わせではないとは思う。 動的型っていうのは、関数の世界では「型無し」ってことになると思うんだけど、 いずれにせよアドホックなエラー処理が必要になって、 純粋関数型的にアドホックなエラー処理というのは少なくとも美しくない。 410 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 12:17:29 ] >>409 遅延評価でインタプリタ。破壊的関数が作れないというものなら、R言語くらいしか知らない。 411 名前：394 mailto:sage [2008/08/09(土) 12:56:14 ] 皆さんレスありがとうございます。 論理的に組み合わせ悪いというよりは、静的型のメリットを選んだ ということなんでしょうか。 静的型VS動的型というのは、安全VS自由ということだと思うんですが、 Haskellは安全を選んだということなのかな。純粋関数型としては、 副作用に関連する不具合から自由なのが売りだと思うので、更に 静的型によって徹底的に信頼性を上げてるという感じなんでしょうか。 >>409 純粋関数型であること(参照透明であること)と動的型が食い合わせ 悪いというのがちょっと分かりませんでした。動的型は実行時不具合 の問題が付きものと思うのですが、参照透明との関係をよろしければ 少し詳しく教えていただけマスでしょうか。 412 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 13:08:18 ] そもそも関数型言語に意味が無い 413 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 13:13:08 ] >>411 動的型を使うと、アドホックなエラー処理が必要になるよね？ っていうか、それがないと動的型を使ううまみがないと思うんだけど。 ここでいうアドホックなエラー処理っていうのは、 対象オブジェクトの型をプログラムで認識して、 意図しないオブジェクトが来たときにエラー処理するってことだけど。 このエラー処理にIOを使わないなら、 それは多相型やクラスを使っても同じ結果が得られるよね。 だから、Haskellに動的型を組み込む必要性は、 意図しないオブジェクトが来たときIOを使ったエラー処理をしたいときに限られると思う。 で、純粋関数型言語は参照透明性ゆえにIO処理するの苦手。 まぁ、動的型っていうのはプログラム中で型を認識できないと意味ないよね？ っていう時点で、カリー・ハワード対応との関係で微妙っていう気にするけど。 僕が考えているのは、そんな感じ。 414 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 13:17:44 ] 上っ面を語り合って自己満足か Haskellに多いやつらの典型だなｗ 415 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 13:18:59 ] グリーンスパンの第10法則が発動すると、どんな言語で書こうと 動的でマルチパラダイムな言語で書いたのと同じになる。 416 名前：394 mailto:sage [2008/08/09(土) 13:33:07 ] >>413 なるほど、理解しました。ありがとうございます。 417 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 13:50:48 ] >>405 せいぜい生きる力を養ってください 418 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 13:54:52 ] >>416 implementationの本を読むといいよ Peyton Jonesのがpdfで読めるはず 419 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 14:11:34 ] >>418 俺はPJのが好きだな。 静的型付けとグラフ簡約が運命的な出会いであることがわかった。 420 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 14:19:55 ] >>413 なんか議論が無茶苦茶じゃないか？ 例えば「型エラー」を「0除算エラー」に置き換えても論理展開が変わらん >このエラー処理にIOを使わないなら、 >それは多相型やクラスを使っても同じ結果が得られるよね。 動的型の重要な利点は、型をいちいち書かなくてもいいという利便性だよな 多相型やクラスを使って動的型をシミュレートするのはすごく面倒だから、この利点を享受できない それから、GHCではerrorやundefinedで発生したエラーをIOモナド上で捕捉できる。念のため 421 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 14:26:59 ] だな。Haskellの例外処理で不足があることはそうそうないと思う。 あと、動的型のメリットを例外処理だけに限定するのは視野が狭すぎる。 LISPのメリットはアドホックな例外処理か？そうじゃないと思う。 422 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 14:39:32 ] >>420-421 納得できないのなら、それで良いです。 僕も、べつにそんなに優れた論拠だと思ってないから。 423 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 14:55:35 ] 俺も>>413はひどい文章で内容もないと思う。 >>416が理解したのが驚愕。 424 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 15:20:10 ] 本当だ、マジで何言ってるのかわからん すげえ 425 名前：394 mailto:sage [2008/08/09(土) 15:22:47 ] 動的型のメリットは型を単に書かなくて済むことだとは思えないんですが。 それだけであれば、コンパイルで発見する不具合をテスト時に見つけよう とする、つまり面倒なことを後回しにしてるだけ、ってことになりませんか？ 426 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 15:23:15 ] 別に動けばいい 427 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 15:30:45 ] 何でも指せるポインタってのはメチャ便利なんですよ。 S式なんて最たるもので、静的な型付けは不能あるいはワイルドカード的。 静的か動的かはトレードオフの問題。 428 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 15:42:04 ] >>425 不具合を見つけるタイミングが遅くなるという対価を払って、記述の利便性および変更の容易さという報酬を得る ちゃんと取引として成立してるじゃないか もちろん「型を書かなくて済む」こと以外にも利点はある 特定の静的型付け言語ではそもそも型を付けられないようなコードが許容されるとか 429 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 17:38:51 ] >>425 lispを使ってる限りの印象だが 都合のよい所だけ型宣言が出来るというのは柔軟性につながるかな。 プログラムの最適の仕方も静的/動的で違いがあると思うよ。 型なんで考えずにアルゴリズムだけ作っちゃえができるからね。 それでも型を意識したプログラミングをすることはあるが。 でも、haskellでもポリモつかえばある程度型無視ラピッドプログラミング は可能じゃないか? 430 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 17:41:42 ] じゃあOCamlでいいじゃん 431 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 17:44:14 ] >>430 haskellって参照透明性ってかなりのメリットだと思ってるけど。 432 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 17:49:41 ] 注意してかけばいいだけの話 Hashkellはメリットを殺すデメリットしかないだろ 433 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 17:56:37 ] 正直、exists型が標準になれば動的型付けは不要じゃね？ en.wikibooks.org/wiki/Haskell/Existentially_quantified_types 434 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 17:57:26 ] >>430 OCamlはstrictだから。残念。 435 名前：394 mailto:sage [2008/08/09(土) 19:55:26 ] >>428 コンパイル時に問題が抽出されることと、テストによって抽出されるのでは 質的な違いがあるんじゃないですか？テストは結局は人間がやるものだし、 不具合の可能性を低めるということにしかならないけど、コンパイルでの 不具合検査は対象となるプログラムの論理的正しさを証明していることに なるかと思います。 容易に変更ができたとして、不具合がどこに潜んでいるのか分かりにくい というのは非常に問題あると思いますよ。コンパイルで分かるのならば、 これは明白でしかも機械的に全てが晒されますから安心です。 436 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 20:20:59 ] Rubyは危険だしセキュリティリスクしか そんざいしないしな 437 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 20:23:09 ] >>435 確かに、バグがどの段階で発見されるかには質的な違いがある でも、静的な型検査だって全てのバグを検出できる訳じゃないから、 結局、動的検査との安全性の違いは程度問題 その上で、静的な型検査の利点がコストを上回るという判断は当然ありえるし、 そう判断したなら静的型言語を使えばいい 438 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 20:28:12 ] >>435 静的型チェック馬鹿ですやん 439 名前：394 mailto:sage [2008/08/09(土) 20:39:50 ] >>437 例えば、参照透明ということについてはどうでしょうか？こちらも、副作用を許容 すれば、プログラム中に登場する変数の中身が何に変異しているかどうかが 分からなくなり、実行してみないと問題が検出できない、ということになります。 参照透明を強要するのも、型を強要するのも、結局その辺がクリアできない プログラマというのはそれらに関連する不具合を出してしまうんだと思いますが どうでしょうか。気をつければいい、というのは簡単で規模が小さなシステムでは 言えることで、そうでなければ膨大なテスト工程が必要になってしまうのでは？ 440 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 20:46:48 ] OCamlが参照透明じゃないから嫌ってどういう事を言ってるの？ refとかで破壊的な変数が作れるから嫌とかそういうレベルの話じゃないよね。 それだったらref使わなければいいだけだから。 逆に、Haskellの参照透明で良い所ってどのへんなの？ OCamlのでも、ErlangのでもなくHaskellの参照透明性が良い理由を説明してほしいんだが。 441 名前：394 mailto:sage [2008/08/09(土) 21:04:32 ] >>440 参照透明でない、ということは値が望んだ通りの値であることを 保証するためにどこまでも神経質にテストをしなければならない、 ってことですよね。 一人で開発するのであればいいですが、多くの人の手によって 間違いがあってはならないシステムの開発をする際、「それは 禁じ手だから止めてね」と口約束するだけってのは非常に怖い わけです。だからこそ、テストの工程が膨れ上がる。 Haskellに自分が惹かれている大きな理由の一つは、この辺の 頑固さを貫いていることですね。 442 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 21:19:02 ] 参照の透明性があれば、 それだけでテストが必要なくなるわけでも、 テストが簡単になるわけでもない。 そうなるのはトイプログラムだけ。 嘘だと思うなら、GHC, Hugsなどのバグトラックをみてみればいい。 443 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 21:21:51 ] テストが減ることを数学的に証明してみせれ。 444 名前：437 mailto:sage [2008/08/09(土) 21:22:55 ] >>439 何が言いたいのか良く分からん 俺は「気をつければいい」なんて一言も言ってないよ >>428に書いたように、動的か静的かの間でトレードオフが成立すると言っているだけ >>441 OCamlの変数は変更不可だよ 変更できるのは参照(ref)で、これは変数とは別物 だから、口約束するまでもなく変数の値が変わらないことは保証されてる 445 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 21:26:07 ] >>440 参照透明性を壊さないと入出力できないのが嫌 446 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/09(土) 21:37:36 ] >>443 数学的に無理だから、統計的に証明するわけですよ。 実際に〜〜でした、ってね。 ヒューマンインターフェース系の論文が参考になるんじゃないかな。 あっちは全部そんな感じ。 447 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 21:38:56 ] >>441 Haskellでもやろうと思えばIORefとかで事実上破壊的な操作が可能になるわけですが、 これについてはどうお考えで？ 「HaskellでIORefは使うな」っていうプログラミングルールを設定することは 「OCamlでref使うな」っていうルールを設定することと本質的に違わないと思うんだけど それについてはどうなんすか。 448 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/09(土) 21:40:14 ] インディージョーンズ、あれは予算が無いからあんなにちゃっちい水晶髑髏なのか？ どう見てもアクリル製のガワの中に反射板入れただけやん。 UFOとかエイリアンとか、考古学じゃなくてSFやん。 突っ込みどころ満載な映画でした。 かしこ 449 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 22:13:11 ] monadとラムダの簡単な練習いっぱい したいです。どこがいい問題集頂戴 450 名前：デフォルトの名無しさん mailto:sage [2008/08/09(土) 22:23:39 ] >>449 do記法を使わずにliftM、liftM2、joinを実装 Continuationモナドを実装 451 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/09(土) 23:30:03 ] >>450 また何も考えずにそういうこと言う。 >>449 ja.doukaku.org/ 452 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/09(土) 23:31:04 ] 英語が読めるなら projecteuler.net/ 453 名前：デフォルトの名無しさん mailto:sage [2008/08/10(日) 05:05:51 ] >>451 モナドとλの練習なら>>450はいい案じゃないか。 いっぱいじゃないけど質的にいい。 454 名前：デフォルトの名無しさん mailto:sage [2008/08/10(日) 05:08:55 ] そんなことが書きたいんじゃなかった。 >>419 PJのって何？本もpdfもPJのでしょ？ 455 名前：デフォルトの名無しさん mailto:sage [2008/08/10(日) 08:02:29 ] PJは Implementation of Functional Programming Implementing Functional Languages,(D. Lesterと共著) を書いていて両方公開。 www.haskell.org/haskellwiki/Books 456 名前：デフォルトの名無しさん mailto:sage [2008/08/10(日) 08:05:37 ] >>449 www.haskell.org/haskellwiki/Tutorials 457 名前：デフォルトの名無しさん mailto:sage [2008/08/10(日) 13:23:16 ] >>454 すまん、>>455のImplementing...のほうを言いたかった。 458 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/10(日) 13:39:12 ] >>453 >>449は本当にモナドとラムダの練習のためだけに問題をほしがっているのかどうかってこと。 それに、初心者は何か目に見えて動かせるものを書きたがるものさ。 誰かに見られることを想定して書くのと、「動けばそれでいい」だけで書くのとでは、 やっぱり前者の方がいろいろ調べたりすることで勉強になる。 459 名前：デフォルトの名無しさん mailto:sage [2008/08/10(日) 15:23:20 ] >>455 そこ載ってなくね？ｗ research.microsoft.com/~simonpj/Papers/slpj-book-1987/index.htm research.microsoft.com/~simonpj/Papers/pj-lester-book/ >>457 サンクス。目次しか見てないけど、 Implementationがパターンマッチや型など広く扱ってて、 Implementingはコンパイラのコアな部分を主に扱ってる感じ？ 静的型付けとグラフ簡約の運命的な出会いというからそうでもない？ まあImplementingのほうを読んでみます。 >>458 そうですね。 460 名前：デフォルトの名無しさん mailto:sage [2008/08/10(日) 16:23:15 ] 載ってるよー グラフ簡約と運命的な出会いというと遅延評価じゃないかね。 特にPJ的には。 461 名前：419 mailto:sage [2008/08/11(月) 14:41:51 ] >>460 まあグラフ簡約は前提として、それを効率的に実装するには静的型付けがイイんだよ、 と、約20年前に読んだ時に思った。 462 名前：419 mailto:sage [2008/08/11(月) 14:44:37 ] 20年前じゃなくて15年前だった。かなり記憶が混乱してるな、俺 orz 463 名前：デフォルトの名無しさん mailto:sage [2008/08/11(月) 16:05:22 ] >>461 あまり理解できてなかったんじゃない？w 464 名前：デフォルトの名無しさん mailto:sage [2008/08/11(月) 16:13:31 ] >>463 かもしれない。 できれば君が読んでポイントだと思ったところを挙げてくれると皆の参考になると思う。 465 名前：デフォルトの名無しさん mailto:sage [2008/08/11(月) 16:20:35 ] PJの最初の本だと、 例え動的型チェックをやろうとも、そのコードは、 他の普通のコードと一緒でスーパー・コンビネータになって、 グラフ簡約されるだけだから、コンパイル時に型チェックを済ませることが、 スーパー・コンビネータのグラフ簡約上、特に有利だとは思えません。 466 名前：デフォルトの名無しさん mailto:sage [2008/08/11(月) 17:39:55 ] 横から口はさんですまんが、静的型がついていたほうがパターンマッチが速くならね？ 467 名前：デフォルトの名無しさん [2008/08/13(水) 09:02:33 ] Haskellの継続ってSchemeとは違いありますか？ 468 名前：デフォルトの名無しさん mailto:sage [2008/08/13(水) 10:48:15 ] call/cc のようなものはありません 469 名前：デフォルトの名無しさん mailto:sage [2008/08/13(水) 11:17:46 ] >>468 MonadCont の callCC :: ((a -> m b) -> m a) -> m a のことじゃないの。 >>467 俺も気になる。違いはあるだろうけど、どう違うのか。 470 名前：デフォルトの名無しさん [2008/08/13(水) 11:23:16 ] やっぱりそうですか。継続ベースのアプリ 作るとしたら、ステートモナドに次のアクション 入れておくとかですかね。 471 名前：デフォルトの名無しさん mailto:sage [2008/08/13(水) 13:45:50 ] MonadContだと、型の関係で、無限ループするような式は書けない。 # mfixとか使えば別だけど。 例えば、Schemeで次の式は書けるが、MonadContでは書けない。 (call/cc (lambda (c) c)) (call/cc (lambda (c) (set! foo c))) つまり、次の式は型が付かない。 callCC (\c -> return c) callCC (\c -> lift $ put c) 要は、callCCで捉えた継続をそのcallCCの外に出せない。ただし、 callCC (\c -> ... callCC (\c' -> c c') ...) のように、内部で別のcallCCを使って、それで捉えた継続を外に出すのはOK。 あと、変な例として、 callCC (\c -> return (Right (c . Left))) はOK。でもやっぱり無限ループはできない。 472 名前：デフォルトの名無しさん mailto:sage [2008/08/13(水) 14:58:55 ] >>471 だとすると、smlのcall/ccを使ったco-routineみたいなことはできないということ？ 473 名前：デフォルトの名無しさん mailto:sage [2008/08/13(水) 17:43:19 ] smlのcall/ccを使ったco-routineは知らないけど、co-routine自体はできる。 import Control.Monad.Cont foo = callCC (\c0 -> do c1 <- callCC c0 c2 <- callCC c1 c2 10 undefined) bar = (do c1 <- foo c2 <- callCC c1 callCC c2) main = print $ runCont bar id 474 名前：デフォルトの名無しさん mailto:sage [2008/08/13(水) 18:18:41 ] >>471 HaskellでYコンビネータを書くとき型が問題になるけど、 実質的には fix f = let g = f g in g で問題ない。 それと同じように、 loop = callCC (\c -> let g = c g in return g) とすれば do { l <- loop; liftIO $ print 0; l } のように無限ループを書ける。 (これの変数付きループ版が MonadLib にあった。) (call/cc (lambda (c) c)) がどう使われるのかよく分からないけど、 実質的には同じことになるんじゃないかな? (call/cc (lambda (c) (set! foo c))) callCC (\c -> lift $ put c) は IORef を使うと問題なくできる。 State だと無理だけど、新しく再帰的なデータ型を定義してやれば、 あまり便利では無さそうだけど一応できた。 475 名前：デフォルトの名無しさん mailto:sage [2008/08/13(水) 22:46:51 ] オラ本の執筆遅れてます 著者にプレッシャﾖﾛ 476 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/13(水) 22:51:05 ] どうせ買わないので暖かい目で見守るだけです。 477 名前：デフォルトの名無しさん mailto:sage [2008/08/13(水) 23:21:14 ] Schemeのcall/ccってその時点の継続を勝手にキャプチャして渡してくれる んですよね？Haskellではそういうのは無いと思っていいんでしょうか？ 478 名前：デフォルトの名無しさん mailto:sage [2008/08/14(木) 00:04:58 ] >>477 モナド無しでということなら無い。 そもそもcall/ccは副作用があるし。 479 名前：デフォルトの名無しさん mailto:sage [2008/08/14(木) 13:47:21 ] >>474ができると言ってるじゃないか 480 名前：デフォルトの名無しさん mailto:sage [2008/08/14(木) 17:35:34 ] あれはモナド有りでの話だよ。 481 名前：デフォルトの名無しさん mailto:sage [2008/08/14(木) 18:53:40 ] ごめん、>>479は>>477へのレスね

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef