関数型プログラミング言語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の仕様により、行頭の半角スペースは表示されません。 　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。 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へのレスね 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みたいに感じるなあ 抽象度が違うのは理解できるが

---

---

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

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