関数型プログラミング言語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の仕様により、行頭の半角スペースは表示されません。 　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。 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へのレスね 482 名前：デフォルトの名無しさん mailto:sage [2008/08/14(木) 18:54:49 ] 山本モナド 483 名前：デフォルトの名無しさん mailto:sage [2008/08/16(土) 19:35:13 ] Haskellはボブマリーの言語? lethain.com/entry/2008/aug/14/global-popularity-of-programming-languages/ 484 名前：デフォルトの名無しさん mailto:sage [2008/08/16(土) 20:24:00 ] コメント欄も読もうな 485 名前：デフォルトの名無しさん mailto:sage [2008/08/16(土) 22:50:09 ] ttp://profile.myspace.com/index.cfm?fuseaction=user.viewprofile&friendid=123319698 こうゆう落ちもある。 486 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 12:30:17 ] Xmonad/Config archive - HaskellWiki haskell.org/haskellwiki/Xmonad/Config_archive の設定ファイル郡を理解できるぐらいまでHaskellについて知りたいんですが どこから勉強すればいいんでしょう？ 知識はXmonadやGhcをソースからインストールできる程度です 487 名前：デフォルトの名無しさん [2008/08/17(日) 13:44:52 ] >>443 >>446 静的で強い型を持つ言語は、単純な実行時エラーを防ぐので テストは軽減する。haskellなどはそのことが数学的に証明されているので プログラマはぬるぽやoutofboundsなどの基本的な間違いにであうことなく、 本質だけを考えることができる。 488 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 14:23:37 ] パターンマッチに失敗すること多くない？ たとえば「空でないリスト」型が欲しいとき、ぬるぽ的な実行時エラーを防げるの？ 489 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 14:47:05 ] ぬるぽは無いけどout_of_bounds発生させまくりですが 依存型のある言語なら防げるかも知れんけど 490 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 15:31:08 ] >>487 おまえ初心者スレにいたHaskell信者だろ。 491 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 18:08:12 ] はいはい両者リングアウト 492 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 18:14:59 ] >>488 それヘボすぎ 493 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 18:26:58 ] モナドがIOに使えるのは分かった。けどどうしてそれをIO以外にも使ってるの？ >Haskell 誰か教えて下さい 494 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 18:36:20 ] Maybe(笑)を証明するため 495 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 18:36:41 ] 便利だから 496 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 18:42:38 ] どんな時に便利ですか？ 497 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 18:59:33 ] モナドのすべて ttp://www.sampou.org/haskell/a-a-monads/html/ の以下の部分を読むとわかるかも Maybe というモナド ひとつの例 リストもモナド 498 名前：497 mailto:sage [2008/08/17(日) 19:11:05 ] 第 II 部：標準的モナドのカタログ の各モナドの利用場面や動機を見るのもいいかもしれない 499 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 19:15:59 ] 一応リストモナドやMaybeモナドが計算に使える、というのは理解しているつもりですが、 便利だからという理由以外にモナドをIO以外に使う理由はあったりしますか？ それだけの理由で使うには扱いが難しくて、プログラムを組む度に頭がオーバーヒートしそうになる 慣れの問題かそれとも理解不足か・・ 500 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 19:25:15 ] >>489 そこでmaybeもなどですよ。 501 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 20:06:22 ] モナドという抽象的な枠組みを考えることで IO, Maybe, List, etcの計算の合成を統一的に扱えるってのが最大の利点なんではないかと。 単に使うだけなら主に慣れの問題だと思う。 いろんな例を見て慣れていけば少しずつ理解もできていくんではないかと。 502 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 20:09:49 ] 自分の作ったモナド上でdo式を書くと、世界の法則を書き換えてるような気分になってちょっと面白い 503 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 20:33:06 ] >>501 レス有難うです 慣れの他に密度の問題もあるかもしれないと思ったり。 他の言語より1行あたりの密度が濃いものになりやすい気がする。 というか濃縮されすぎてわけが分からなくなりやすい気がする。 504 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 20:38:12 ] >>501 計算を統一的に扱うだけであれば、普通の型クラスでいいんですよね？ モナドは値ではなくて型コンストラクタに対するクラスなので、ちょっと違う と思うんですが。 505 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/17(日) 20:39:51 ] モナドっていうと仰々しいイメージがあるかもしれないけど、 所詮はただの代数的データ型とそのデータ型に対して一貫性あるAPIのセットに過ぎないよ。 ところで、　データ型とAPIのセット　のことをなんて呼べばいいの？ 506 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 20:40:10 ] Stateモナドとかの(s -> (a,s))みたいな変な定義が気持ち悪い 型クラス(b,s) -> (a,s)に型bを部分適用したって考えれば意味は通るけど…… 507 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 21:08:43 ] >>505 それが「型クラス」、ではないのでしょうか？MonadやFunctorはちょっと 毛色が違うという認識は勘違いでしょうか？ 508 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 21:17:01 ] www.hyuki.com/haskell/20041228215300 Ord、Eq、Show などの データ型とそのAPIのセット は「型クラス」 Functor、Monad、MonadPlus などの データ型の構築子とそのAPIのセット は「型構築子クラス」 509 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 21:31:22 ] それ単にOrdとかの『類』は*で引数をとらないけど Functorの『類』は*->*みたいに引数をとる、って違いにしか見えない 分けて考えるのはおかしいと思う 510 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 21:37:45 ] >>509 型クラスと型構成子クラスじゃ抽象度が違うよ。 511 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 21:49:13 ] 俺も>>509みたいに感じるなあ 抽象度が違うのは理解できるが 512 名前：507 mailto:sage [2008/08/17(日) 21:58:16 ] 抽象度の違う型クラスを持つことで、値の計算遷移とは別レベルの 遷移を持つことが可能だ、という印象を持つんですけどどうなんでしょうか。 普通の計算を行う裏側で別の次元での計算が行われ、且つそれが 結合法則を満たしている、というのがモナドの定義と考えるのは どうですか？自分は圏論などのこと全く無知なのでHaskellの構文 からの直感的な印象だけなんですけど。 513 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 21:59:06 ] じゃあ類が*->*->*（関数(->)とかタプル(,)とか）に対する型クラスとかは もっと抽象度が違うので別の名前が必要なのか？型構築子構築子クラスとか。 有名な人が書いてるから鵜呑みにしてるだけなんじゃないの？ 514 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 22:31:24 ] >>512 だいたいあってんじゃね？ 見えてる部分で適当に処理を書いたら裏で適当に処理してくれる、 普通のプログラミング言語じゃfor文やif文みたいな処理構造、 あるいはマクロとして提供されるものと同等の処理ができるんだけど、 実態は単に型クラスでしかないので俺定義できるし、高階関数使えるし、表記もシンプルで、いろいろ小細工が利くのが利点。 たとえば、IOみたいにコンストラクタを隠したりすれば脱出不可な構造を作れるってわけ。 結合法則を満たしているってのは、まぁ別に特別なことじゃない。 EqやOrdにも反射律とか推移則とか守らないといけないルールがあるけど、 よっぽどのことがない限り変な実装はしないだろうから、一般のプログラミング言語ではそこまで突っ込まない でもモナドって実態がよくわかんないから、ルールを明記してる。そんだけでしょう。 515 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 22:45:32 ] 念のため補足。 ＞処理構造(略)同等の処理ができるんだけど 普通の言語では処理構造のものが、モナドが利用されてる例としてはErrorモナドとかContinuationモナドとかがあったね。 ＞よっぽどのことがない限り変な実装はしないだろうから、一般のプログラミング言語ではそこまで突っ込まない 浮動小数点の比較と等価性で違う実装がされてるとか、変な実装もあるけど。 個人的にはMonad則は、 値に関して順次実行できる何かで、値に対して何もしない処理もできる何かだ、というルールだと解釈してる。 516 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 22:50:03 ] 変な実装＝全順序じゃない、と読み替えてくれ。 コンピュータのメモリ節約を考えれば生の浮動小数点型を使うのもまっとうな実装だわｗ 517 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 23:19:23 ] ごめん、誤解を招くといやなのでもう一つ補足…… ＞値に関して順次実行できる何か これは実行順序じゃなくて値の計算する方向を言ってるだけだよ。 g.f x がxにfを適用してgを適用するってのと同じことだよ。 実行順序は普通のモナドもIOモナドも方向は決まってないよ。 518 名前：初心者修業中 mailto:sage [2008/08/17(日) 23:37:55 ] ん？ 実行順序を明確にするのがIOモナドの目的の一つ と認識していますが。 そういう意味ではないのかな… 519 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 23:41:24 ] Haskellをみて日本のhaskellコミュって元気なの？ 他の言語に比べて内と外をわけすぎるようなそんな印象をもってる。 なんでだろ？ 520 名前：デフォルトの名無しさん mailto:sage [2008/08/17(日) 23:58:38 ] >>518 たとえば、 1:2:3:[]は、 1:2:3:[] → 1:2:[3] → 1:[2, 3] → [1, 2, 3]と簡約されるかもしれないし、 1:2:3:[] → [1, 2:3:[]] → [1, 2, 3:[]] → [1, 2, 3]と簡約されるかもしれない。 でも結果は一緒でしょ？ 同じように、 Hello, Worldって出力 >> 一文字入力 >>= 前の文字を出力 みたいなのは、まぁ言ってみれば(不正確だけど) [Hello,Worldって出力, 一文字入力, 前の文字を出力]みたいな並びにされる(と思われる。実装はカプセル化されていて不明)。 この並びがプログラム終了後にコンパイラにわたって、コンパイラがこれを順番に処理していく。 実はこの並びをプログラム終了後以外に評価する方法があって、それがUnsafePerfomedIOって言う関数。 getContentとかは実はこれを使って実装されている。 Unsafeという名前が示すように、素人にはお勧めできない。(getContent自体は普通に使える。) 521 名前：デフォルトの名無しさん mailto:sage [2008/08/18(月) 00:02:55 ] Maybeの特化にしか見えません 522 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/18(月) 00:25:49 ] >>519 世界的に全く元気がありません。 ちょこっと変なライブラリを書いたと思えばそれっきり離れていっている人も多数。 523 名前：デフォルトの名無しさん mailto:sage [2008/08/18(月) 01:36:55 ] >>520 後者の簡約は型がおかしいし、1:2:3:[]ではなく、 f x = (unsafePerformIO $ print x) `seq` xで f 1:f 2:f 3:[]だった場合、前者と後者の簡約順序ではprintの順番が違ってくる。 前者は3,2,1で後者は1,2,3 一方で(>>=)は最左最外簡約でも最右最内簡約でも 左から順にしか値が定まらないようになってる。 putStr "Hello" >>= (\ _ -> getChar) >>= (\ c -> putChar c) (>>=)の右辺が関数だから左辺の値が定まるまでa >>= bが最終的な値に簡約できないようになっている。 524 名前：デフォルトの名無しさん mailto:sage [2008/08/18(月) 03:17:18 ] >>522 元気無い理由って何でしょうか。他に元気ある言語ってあるのかな。 525 名前：デフォルトの名無しさん mailto:sage [2008/08/18(月) 04:14:24 ] ruby 526 名前：デフォルトの名無しさん mailto:sage [2008/08/18(月) 08:38:27 ] >>520 > 1:2:3:[] → [1, 2:3:[]] → [1, 2, 3:[]] → [1, 2, 3]と簡約されるかもしれない。 型が滅茶苦茶だよ。 > この並びがプログラム終了後にコンパイラにわたって、コンパイラがこれを順番に処理していく。 意味不明。なぜプログラム終了後にコンパイラが出てくる。 ランタイムライブラリとごちゃまぜになているぞ。 527 名前：デフォルトの名無しさん [2008/08/18(月) 10:05:00 ] Haskellにこういう奴が多い気がするのはなぜだ 528 名前：デフォルトの名無しさん mailto:sage [2008/08/18(月) 10:21:37 ] 「こういう奴」と書けばどんな奴を指してるのか分かってもらえると思ってるような、 想像力の貧しい奴がこのスレに多いような気がする

---

---

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

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