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

1 名前：潜伏していた1 mailto:sage [02/02/16 16:55] 何とか生き残れました。 前スレ pc.2ch.net/test/read.cgi/tech/996131288/l50 関連 >>2 以降 17 名前：デフォルトの名無しさん [02/02/21 16:56] なんと、同じ名前で新スレとは！ なんたる！ 18 名前：デフォルトの名無しさん mailto:sage [02/02/21 17:10] >>17 参照の透明性が…（泣 19 名前：デフォルトの名無しさん [02/02/21 17:23] >>1　は　Haskellにお詫びしろ。 貴様は代入を行った（笑 20 名前：デフォルトの名無しさん mailto:sage [02/02/21 18:07] 実はMonadを使って回避されています……ってワケにも行かないか。>>19 21 名前：デフォルトの名無しさん mailto:sage [02/02/21 18:39] >>17-20 ﾜﾗﾀ 22 名前：デフォルトの名無しさん [02/02/21 20:29] 17=18=19　の自作自演じゃない。 参照透明性くずすな。 23 名前：17 [02/02/21 20:33] 私は17しか書きこんでないっ！ 24 名前：22 [02/02/21 20:41] 失礼。 17−20うまくオチが決まってたので、チャチをいれたくなった（笑） 25 名前：17 [02/02/22 01:37] もしかしたら、再帰呼び出しなのかもしれないな（笑 ＃だとしたら次スレも同じ名前？（笑 26 名前：デフォルトの名無しさん mailto:sage [02/02/22 02:55] 「おっ、Haskell スレにいっぱいレスが付いてる」と思ったら… 27 名前：20 mailto:sage [02/02/22 04:51] 代入と配列（あるいは大きなオブジェクトの部分更新）とMonadの関係について 丁度悩ましい思いをしてるトコなもんで(w。 >>25 その場合、このスレに関する型推論はどうなるのでありますか？(w 28 名前：面白そうだけど、調べた事ないー [02/02/22 19:53] >>27 やってたやってた、蓬莱軒行った奴がそういうテーマ。 なんか、プログラムの停止性と関連付けて、 停止する関数と停止しない関数に分けるのかな？ 多相型と関連付けると、ちいと面倒な結果になりそう... ＃真面目に調べたことないけど 29 名前：20 mailto:sage [02/02/23 12:55] >>28 蓬莱研？もしかすると物理的に近所かもしれない……(w。 ちなみに特に関心があるのはその実装と効率なんでスヨ。 今、メインで悩んでる課題ではないんだけどね。 30 名前：デフォルトの名無しさん [02/02/24 05:33] ghcを使ってちょこちょこ簡単なプログラムを 作って遊んでます。が、しかし！ コンパイルが異常に遅いです。 ghcってHaskellで書いてあるんですよね？ だとしたらHaskellで書かれたプログラムは 遅いということになったりして・・・鬱 実際にghcでアプリケーション作ってる人の 感想を聞かせてください。 31 名前：デフォルトの名無しさん [02/02/26 14:59] hoshu age 32 名前：デフォルトの名無しさん [02/02/26 15:00] www.mondrian-script.org/ これはなんでしょうか？ 33 名前：デフォルトの名無しさん [02/02/28 04:08] 乱数を生成関数では、素直に考えると 参照透明性が確保できませんよね？ （実行するたび帰り値が違うんですから。） なんとか参照透明性を確保する方法ってないのでしょうか？ 誰か教えてください。 34 名前：デフォルトの名無しさん [02/02/28 04:13] >>32 おおHaskell.NETのBetaすか？ いいですねー。 今度Downしてみよう。 35 名前：デフォルトの名無しさん mailto:sage [02/02/28 04:26] >>33 「入力」の仲間だと思えば継続(continuation)かMonadかなぁ。 無限リストで乱数列を表し遅延評価というのも、 形式的には面白いが実際に書くと重いだろうなぁ。 まー、擬似乱数を線形合同法とかでつくるなら、 お手軽には直前に出力された数を呼出し毎に渡すとか……。 36 名前：デフォルトの名無しさん mailto:sage [02/02/28 06:50] >>33 www.sampou.org/haskell/library-j/random.html ほとんど>>35の言う通りのやり方。 >>35 > 無限リストで乱数列を表し遅延評価というのも、 > 形式的には面白いが実際に書くと重いだろうなぁ。 そこまで重くなるとは思えないけど? というか、他の部分も遅いだろうから、 特別その部分が遅い気はしないだろうっていうほうが正しいか(w 37 名前：33 [02/02/28 13:23] >>35 >>36 お答えいただき有難うございます。 >ttp://www.sampou.org/haskell/library-j/random.html この方法ですか。なるほど。 質問してから解決策を考えていたのですが 乱数表を使うか、この方法かどちらかかなとしかないかなと 思っていたので納得出来ました。 それにしてもHaskellのIO型って変ですね。(名前が) 非決定なものは、すべてIO型なんですね。 うーん、もっと良いネーミングしてほしい。 38 名前：デフォルトの名無しさん mailto:sage [02/02/28 13:35] Linux の /dev/random みたいなものかと 39 名前：デフォルトの名無しさん [02/03/01 09:20] >>36 重くなるっていうか、乱数って最新の一個だけが必要なことが多いから 過去の値が全部リストになって残ると、沢山利用した時にメモリを無駄に圧迫するかなと。 GCで回収されるならまだいいんだけど。 40 名前：デフォルトの名無しさん mailto:sage [02/03/01 15:50] >>39 参照されていないオブジェクトは回収されないんですか？ 41 名前：デフォルトの名無しさん [02/03/02 04:02] >>40 クライアントは再帰中なので、 生成された乱数は、参照可能だからかな？ そりゃ、回収されんわな。 42 名前：デフォルトの名無しさん [02/03/02 11:59] >>37 IO monadは、最初は本当に入出力用だったのに、 後からいろいろと付け足したのだと思われ。 別々のmonadにすればいいじゃん、と思うかもしれないが 一緒に使いたくなったときに困る。 monadの合成は、理論的に自明じゃない問題があるので。 43 名前：デフォルトの名無しさん [02/03/02 13:59] 乱数乱数って普通言うけど、実際は乱数系列のことでしょ だから>>36のやり方は別に特殊じゃないよ。 44 名前：デフォルトの名無しさん mailto:sage [02/03/02 14:10] >>41 末尾再起なら回収できないかな？ 45 名前：デフォルトの名無しさん mailto:sage [02/03/02 14:43] つーか、素直にIO monadな>>36使え。 末尾再起じゃなくて乱数リスト回収できない事気にするくらいなら、 リストよりでかいスタックを解放するようにプログラム書き換えろ。 sagesage 46 名前：デフォルトの名無しさん [02/03/05 18:35] たまには age ておこう。 47 名前：言語障害なんです [02/03/08 04:49] Haskell は OOPL 疑惑 www.geocities.co.jp/SiliconValley-Cupertino/6957/HaskellIsOOpl.ja.html >>13はゆーあいさん疑惑 www.geocities.co.jp/SiliconValley-Cupertino/6957/diary200202.ja.html 思っているだけで作る気はない疑惑 www.geocities.co.jp/SiliconValley-Cupertino/6957/mylang.ja.html typo がやたら多いという罠 48 名前：デフォルトの名無しさん mailto:sage [02/03/12 14:32] Haskellのモナドは正直言ってかったるい 49 名前：デフォルトの名無しさん [02/03/13 07:58] age 50 名前：デフォルトの名無しさん mailto:sage [02/03/13 09:04] あーそうだ haskell もやらなきゃ.. 51 名前：デフォルトの名無しさん [02/03/19 22:40] 質問ですいません。 「lambda lifter」って、どういう処理なんでしょうか？ 局所関数(関数内の関数)を展開して外側の関数と一体化する処理らしいですけど 実行速度改善のための最適化処理の一種だと考えてよいのでしょうか？ citeseer.nj.nec.com/lester91modular.html それと関数型言語にある代表的な最適化処理があれば教えてください。 52 名前：デフォルトの名無しさん mailto:sage [02/03/19 22:42] >>51 Cのインラインと違うの？ 53 名前：デフォルトの名無しさん mailto:sage [02/03/19 23:03] >>52 実行時までどんな関数が来るのか分からない らむちゃんなんだから全然違うだろ。 54 名前：無名λ式 [02/03/20 00:44] >>51 lambda liftingというのは、 一言で言えば、自由変数を除去する変換の事です。 ・funarg問題がなくなる ・環境の扱いが簡単になる ・lazinessの境界がはっきりする などなどの利点があります。 lifterはその変換器の名前です。 Super combinatorというのありました。(これは変換後のλ式の名前) Prentice-Hallから処理系実装の本が出ていましたが、 > それと関数型言語にある代表的な最適化処理があれば教えてください。 こういう観点で非常にいい読物だと思います。 # 今やMicrosoft Research(CLI!)のSimon P. Jonesのが一冊、 # もう一冊はHughesじゃなかったかな? 教科書になって答えがWebで配布された奴。 驚きなのはcombinatorが非常に古い概念であるにも関わらず、 λ計算において非常に本質的な役割を担うことです。 55 名前：無名λ式 [02/03/20 00:46] >>53 > 実行時までどんな関数が来るのか分からない > らむちゃんなんだから全然違うだろ。 λ式ちゃんは、Lisp野郎ほど酷くないですけどね。 奴の場合、cons, eval, macroと何でもありなので。 56 名前：デフォルトの名無しさん mailto:sage [02/03/20 01:04] > # 今やMicrosoft Research(CLI!)のSimon P. Jonesのが一冊、 research.microsoft.com/~simonpj/Papers/papers.html ここ (の一番上のとこ) から落とせるやつですな。 57 名前：無名λ式 mailto:sage [02/03/20 10:30] research.microsoft.com/~simonpj/win32-cheat.html これ面白いよね。この作業苦痛じゃないのかな... 58 名前：デフォルトの名無しさん mailto:sage [02/03/20 12:17] >>57 なんだか大変そうですね。これホントに自分でやってるのかな？（藁 59 名前：デフォルトの名無しさん mailto:sage [02/03/21 16:58] 仕事でcygwinを強いられるSimon萌え！ 60 名前：デフォルトの名無しさん mailto:age [02/03/21 21:05] 論文発表打ちage 61 名前：デフォルトの名無しさん [02/03/26 05:40] >>54 コンビネータ、結合子ですか？ 圏論？λ理論の話でしたか？ うーん難しい。 62 名前：デフォルトの名無しさん [02/03/26 23:57] >>61 理論的には難しいとおもうけど、 "Implementing Functional Languages: tutorial" には実装についてわかりやすく書いてありますです。 63 名前：デフォルトの名無しさん [02/03/27 00:00] >>62 サイモン パイソン ジョーンズさんがM$用に書いたやつだよね？ どのチャプターに書いてあります？ (ファイルは持ってるんだけどねー。軟弱ものなので読んでません。) 64 名前：デフォルトの名無しさん mailto:sage [02/03/27 02:13] > Peyton ペイトン 65 名前：デフォルトの名無しさん [02/03/27 09:17] >>63 Lambda lifting については　６章 コンビネータ実装のはなしは "Implementation of Functional Programming Language" というよく似た名前の本の方でした。これも、どこかのWEBサイトで公開 されてたとおもうですだす。 66 名前：デフォルトの名無しさん [02/03/28 04:41] >>65 "Implementation of Functional Programming Language" 本の方は簡単に見つかったけどなー。 判らない。くそー。 67 名前：Super Combinator [02/03/28 10:27] >>66 何がわからないのか、話してみれば? 68 名前：デフォルトの名無しさん [02/03/28 10:28] Peyton Jonesは前に学会で会ったとき、冬のロンドンを裸足で歩いてた…。 別に変人じゃなくてナイスガイなんだけど。発表は楽しいし。 69 名前：66 [02/03/28 22:37] >>67 コンビネータといえばCL式 どんなCL式でもIKSを組み合わせたものまで分解できるらしいけど どうやって？ あとSの意味が判らない。どう使うんだろう？ I = \ x -> x K = \ x y -> x S = \ x y z -> x z ( y z ) でも相手にしないでください。 頭正規形(hnf)って何？といぐらいのレベルですから。 ラムダ理論も知らないんですから。 70 名前：Super Combinator [02/03/29 09:40] >>69 > あとSの意味が判らない。どう使うんだろう？ > S = \ x y z -> x z ( y z ) Distributor. Combinator式は、グラフとして素直に表すことができるから、 部分グラフは、元のプログラムを分割したものと考えられる。 部分プログラムxと部分プログラムyの両方に引数zを渡し適用するのが役割。 x側では引数zは必要なければ、 (K x' z) (y z) てな感じになる。(x ≡ K x') (x z)を(y z)に適用するのは、部分プログラム同士を結合する方法が、 「適用」以外にはないから。Combinator logicやlambda calculusでは。 RAM(Random Access Machine)ではメモリ参照で、データを扱うわけだけど、 Combinator logicやlambda calculusでは、どんどん受け渡していくことになる。 # lambda calculusのβ簡約をメモリ参照で直感的に理解している人も多いと思うが。 71 名前：デフォルトの名無しさん [02/03/29 19:23] >>69 I=SKK Raymond Smullyan の "To Mock A Mockingbird" という本が楽しめます。 翻訳も出ていたと思う。 72 名前：デフォルトの名無しさん [02/03/29 20:47] >>71 『ものまね鳥をまねる』森北出版　isbn 4-627-01901-7 73 名前：69 [02/03/29 22:43] みなさん、親切な解説有難うございます。 「プログラミング意味論」 横内寛文著 「計算論 計算可能性とラムダ理論」 高橋正子著 と読み理解しようと奮闘中なのですが、計算機屋の私にはさっぱりです。 しかし理論はむずかしーな。 一度ものにしてしまうと効果絶大なんですけどね。 もうちょっと、がんばってみます。 >>71 >I=SKK む。なるほど。 上の本で書かれていましたが、改めてみると こういう意味だったんですね。 Sの機能が、ちょっとわかった気がしました。 >>70 >Distributor. > >Combinator式は、グラフとして素直に表すことができるから、 >部分グラフは、元のプログラムを分割したものと考えられる。 >部分プログラムxと部分プログラムyの両方に引数zを渡し適用するのが役割。 中略 >(x z)を(y z)に適用するのは、部分プログラム同士を結合する方法が、 >「適用」以外にはないから。Combinator logicやlambda calculusでは。 なるほど。 Sで式同士を組み合わせる。 もしくはSで式を分解できるということなんでしょうか？ >>71 >『ものまね鳥をまねる』森北出版　isbn 4-627-01901-7 ttp://www.morikita.co.jp/bunya/kensaku-bunya.cgi?id=67 よさそうな本ですね。購入したいと思います。 74 名前：Super Combinator [02/03/29 22:49] >>73 > 両方に引数zを渡し だから'分配器(distributor)'です。 Sはドイツ語だったかの頭文字だったはず。 K=cancel 75 名前：石敢當 [02/04/09 22:39] GHC 5.02.3 がリリースされました。 ただいま amortization の勉強中。 分かったような、分からんような・・・ ということは分かってないんだなぁ。 76 名前：Super Combinator [02/04/10 00:36] >>75 amortizationは、時間のかかる処理を、複数の操作に対してひとまとめにして、 平均の計算量オーダーを下げる手法のこと。 木、ソートされたテーブル、pure functional arrayなどの 再構成、構造調節などで利用される事が多い。 77 名前：デフォルトの名無しさん [02/04/10 20:28] amortizationって何ですか？ どういう物なのか興味あるなー。 教えてSuper Combinatorさん。 78 名前：石敢當 [02/04/10 21:57] > amortizationは、時間のかかる処理を、複数の操作に対してひとまとめにして、 > 平均の計算量オーダーを下げる手法のこと。 そのような雰囲気は分かるのですが、「分かったぞ！」という実感が まだ伴っていません。もう少し勉強します。 .NETというのも名前はよく目にするものの中身はさっぱり分からない のですが、Hugs98 for .NET というものがリリースされたようです。 galois.com/~sof/hugs98.net/ 79 名前：デフォルトの名無しさん [02/04/11 10:18] Cormen, Leiserson, RivestのIntro. Algorithmsに amortized analysisの章がありますよ． 80 名前：デフォルトの名無しさん [02/04/11 11:31] たとえば固定長配列に1ずつ要素を追加していくことを考えます。 満杯になったら新しく大きい配列を用意して全部コピーして追加。 このとき、初期サイズ1で1ずつ大きくして行くとN要素追加するの に合計コピー回数は1+2+3+…+NだからO(N*N)。定数Cずつ大きく していくとしても、コピー回数がC分の1になるだけだからO(N*N) は変わらない。ところが2倍ずつに大きくして行くことにすると、 1+2+4+…+NだからO(N)になるのね。しかし「1個追加するときの 最大計算量」はどの方法でも(その1個であふれた場合はどのみち コピーするんで)変わらない。逆に言えば、最大計算量を考える 変わりにN個の操作全体の計算量を考えてその平均を取ると 1個追加する際の平均的な計算量はO(1)だよね、っていうのが amortized analysis。 81 名前：デフォルトの名無しさん [02/04/12 21:11] ttp://www.cs.columbia.edu/~cdo/papers.html ここに書いてあることかな？ 英語が読めない。 82 名前：デフォルトの名無しさん [02/04/13 19:28] なんか今はnot foundになっちゃうけど、それってChris Okasakiのページだよね。>>81 だったら、そうだと思う。 でもこのスレの人でも、英語は壁になるんだ…。自動翻訳希望？ 83 名前：81 [02/04/14 01:11] そうです。 他力本願全開。 84 名前：石敢當 [02/04/14 23:51] > 逆に言えば、最大計算量を考える > 変わりにN個の操作全体の計算量を考えてその平均を取ると > 1個追加する際の平均的な計算量はO(1)だよね、っていうのが > amortized analysis。 これは良く分かります。ただ、これだけだと amortization などという 言葉を持ち出すまでもなく、単に「平均」ですよね。（違うのかな？） もし単に平均コストのことを言っているだけだとすると、 banker's method だの physicist's method （>>79の本では accounting method と potential method）だのの技法を使い、 多くのページを割いて解説するほどのことじゃないように 思うんです。 >>80の例の場合、配列の確保がサイズに関係なくO(1)で行えると 仮定すると、あふれたときに1度に全部コピーするのではなく、 新しい要素が追加されるたびに要素を2個ずつコピーすることに すれば1個追加する際の「最大の」計算量がO(1)となります。 結局、amortizationの何が良く分からないのかということを 改めて考えてみますと、amortized analysisで得られた平均 計算量が、平均ではなくて最大の計算量となるような実装が いつも得られるのだろうか、ということであるような気が してきました。 まだ良く分かっていません。変なことを書いていたらごめんなさい。 85 名前：デフォルトの名無しさん [02/04/15 10:08] >>84 > これは良く分かります。ただ、これだけだと amortization などという > 言葉を持ち出すまでもなく、単に「平均」ですよね。 「最悪」の場合の1ステップあたりの「平均」ではないでしょうか。 86 名前：デフォルトの名無しさん [02/04/17 14:32] www.teu.ac.jp/kougi/koshida/Prog6/index.html ↑ ない・・・ 87 名前：デフォルトの名無しさん [02/04/17 17:53] www.brl.ntt.co.jp/people/mizuhito/CS/ 　↑ ここも講義録だったような気がするんだけど、つながらない･･･ 88 名前：デフォルトの名無しさん mailto:sage [02/04/18 01:13] >>87 www.ipl.t.u-tokyo.ac.jp/~mizuhito/CS/ 89 名前：デフォルトの名無しさん [02/04/19 00:40] このスレを見て面白そうだと思いHugsを入れてみた関数型の素人です。 最初はやはり名前を入力させてXXXさんこんにちは、だと思い試したのですが putStr "123" とか getLine とか単体では動くのに、次のように組み合わせるとエラーになります。 Prelude> putStr getLine ERROR - Type error in application *** Expression : putStr getLine *** Term : getLine *** Type : IO String *** Does not match : [Char] 一行入力をそのままエコーすることを意図しているつもりなのですが、何故でしょうか？ 90 名前：デフォルトの名無しさん mailto:sage [02/04/19 00:49] >>89 getLine の型は IO String だが putStr は String 型を貰うので 型エラーになります。(IO が付いているかいないかの違いだけど) getLine >>= putStr とすれば意図してるように動きます。 「>>= って何?」などと思うのでしょうが、説明するのは大変なので www.sampou.org/haskell/tutorial-j/ などを読んでください。 91 名前：デフォルトの名無しさん [02/04/22 03:35] 色々試しているのですが、次のコードで ERROR "ファイル名":3 - Type error in function binding *** Term : sel *** Type : a -> IO a *** Does not match : a -> a *** Because : unification would give infinite type というのが消えてくれません。 module Main (main) where sel x = do putStr "(y/n) ? "; c <- getChar 　　　　　　　return ( 　　　　　　　　case c of 　　　　　　　　　'y' -> sel (x + 1) 　　　　　　　　　'n' -> x 　　　　　　　　　_ -> sel x) main = do putStr (show (sel 0)) selの型は Int -> IO Intのつもりなのですが、型を明示しても駄目です。 いじっていると、IO (IO Int)みたいな型がエラー報告で出るときもあります。 このコードはどうすれば通るのでしょうか？ それと、IOを重ねる意味は無いように思えるのですが、IO (IO Int) というのはどういう状態なのでしょうか？ 質問ばかりで申し訳ありません。 92 名前：デフォルトの名無しさん mailto:sage [02/04/22 05:02] >>91 case c of {'y' -> sel (x + 1) ;'n' -> x ;_ -> sel x} この式の型は何でしょう? 93 名前：91 mailto:sage [02/04/22 06:35] IO Int …のつもり…です。 それをreturnで返していますから、selの返値もIO Intで、 selの型は Int -> IO Int … エラーになるということは、間違った理解なのでしょうけれど… 94 名前：91 mailto:sage [02/04/22 06:48] sel (x + 1) と sel x が IO Intなのに、'n' の時の x がただの Int だからいけない…？ とすれば、ただの Int を IO Int に揃える必要があるということですか？ 95 名前：デフォルトの名無しさん mailto:sage [02/04/22 08:29] > IO Int …のつもり…です。 > それをreturnで返していますから、selの返値もIO Intで、 return の型は Monad m => a -> m a です。 >>91 のケースだと m は IO。 > とすれば、ただの Int を IO Int に揃える必要があるということですか？ うん。で、そういう場合に return を使う。 sel x = do putStr "(y/n) ? " c <- getChar case c of 'y' -> sel (x + 1) 'n' -> return x _ -> sel x 96 名前：91 mailto:sage [02/04/22 12:00] 以下のコードで動作しました。ありがとうございます。 module Main (main) where sel x = do putStr "(y/n) ? "; c <- getChar 　　　　　　　case c of 　　　　　　　　'y' -> sel (x + 1) 　　　　　　　　'n' -> return x 　　　　　　　　_ -> sel x main = sel 0 >>= putStr . show (r <- case …にしてその後にputStr "/"とreturn rを続けて書いたら、'n'を打った時も表示されたので) この場合returnはcaseから抜けているだけですよね？ doを使っている場合も、returnを書かなくても、最後の式が返値になるのですね。 97 名前：デフォルトの名無しさん [02/05/01 14:16] return は関数であって、命令ではない。 98 名前：91 mailto:sage [02/05/01 23:13] IO型にするだけで、脱出はしないということですか？ 99 名前：デフォルトの名無しさん [02/05/02 00:29] 返り値という表現に違和感を感じので。 深い意味はないです。return は、返り値を もって呼び出し元へ帰る命令ではなく、単に a 型の値を m a 型の値に写像する関数だと いってみただけです。 100 名前：デフォルトの名無しさん mailto:sage [02/05/02 00:51] 試してみたら、returnの後に文を続けた場合、途中returnに渡した値は無視されて、最後の値が採用されているようです。 成程…Haskellのreturnはreturnしないのですね。 101 名前：デフォルトの名無しさん [02/05/02 02:43] のぶさんのHaskell-MLに登録してみましょう 102 名前：デフォルトの名無しさん [02/05/03 01:36] return とか戻り値をCチックに理解しようとしてる時点でもうダメでしょうって 感じかも。関数型言語の発想が根本からわかってない。 IOモナドって一見して普通の手続き型にも見えますからねえ・・ 関数型が全くわからない人は、HaskellのまえにMLを経由した方が良い というのは正しいのかも。 103 名前：デフォルトの名無しさん mailto:sage [02/05/03 02:08] モナドは手続き型プログラミングの車輪の再発明だって、どっかに書いてあったね 104 名前：デフォルトの名無しさん [02/05/03 10:55] 俺、いつもはMLしか使ってなくてHaskellは詳しくないんだけど、 Haskell（特にGHC）って例外処理とか、入出力じゃない副作用も どんどんIOモナドに入ってるじゃん。 モナドの合成が理論的に難しいかららしいけど、そのうちに現実的な プログラムだと何でも一つのモナドの中で書くことになって、ほとんど MLみたくなったりはしないの？（手続き型言語とまではいわないけど、 「どこでも副作用」って感じで） 105 名前：デフォルトの名無しさん [02/05/03 15:56] >>104 モナドは副作用じゃないのでOK OK。 逆に言うとMLの利点がなくなってくる。 106 名前：デフォルトの名無しさん mailto:sage [02/05/03 16:10] ML、Haskellってお互い仲悪いんですか？ 107 名前：デフォルトの名無しさん mailto:sage [02/05/03 16:11] ゆーざーがね 108 名前：デフォルトの名無しさん [02/05/03 19:18] 仲悪いなんて聞いたこともないぞ。 なかはわるくないです。 MLとHaskelは ちょっと雰囲気は違うような気はしますけどね。 でもまあそれは両方使ってみれば解ることで。 109 名前：デフォルトの名無しさん mailto:sage [02/05/03 20:43] >106 Haskell-MLというのが有るらしいですYO! 110 名前：デフォルトの名無しさん [02/05/04 23:53] Haskellは、純粋関数型言語だから MLの不純さが嫌なのかも？ どうなの？＞ALL 111 名前：デフォルトの名無しさん mailto:sage [02/05/05 00:01] 確かにHaskellの処理系の効率が良くなればMLは不要になる。 112 名前：デフォルトの名無しさん [02/05/05 01:34] MLとHaskellは設計思想自体が全然違う気がします。 ML(Ocaml)は現実的にある程度の副作用を認めている代わりに 使っているとコンパクトな感じがします。 副作用も使えると言うだけで、副作用のある構文を使わずに書く事は 全然出来ますし、遅延評価もコードによって簡単に実現できます。 未だ出来あがっていないものの、ML2000の仕様書では言語自体に 遅延評価など新しい機能がかなり含まれています。 Haskellは純粋を歌ってはいますが、 結局の所モナドというものに問題を押しこんだだけのようにも思え 美しくないようにも思われます。 仕様もわりとごちゃごちゃしている気がします。 言語の性質上ML並みに速くなる事も難しいのではないかと思います。 113 名前：デフォルトの名無しさん mailto:sage [02/05/05 03:11] MLで副作用使わずにどうやってI/Oするの？ 114 名前：104 [02/05/05 14:26] あーなんか煽りっぽくなっちゃってスマソ。俺はHaskellも大好きだよ。(笑) WadlerとかPeyton Jonesとか面白い人が多いし。（そういう問題か？） >>113 一応、MLでもHaskellと同様のmonadicなプログラミングスタイルは可能。 MLだと文法的に面倒で、Haskellを使ったほうが楽だから誰もやらないけど… 115 名前：デフォルトの名無しさん mailto:sage [02/05/05 14:57] 副作用のある関数型言語は 中途半端な感じが払拭できないということでいいのか？ 116 名前：デフォルトの名無しさん [02/05/05 15:21] Ｒｕｂｙ　＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞　Ｈａｓｋｅｌｌ 117 名前：デフォルトの名無しさん [02/05/05 17:42] モナドがあまりに手続き型っぽすぎるので、 Haskllを関数型を知らない人に触らせると、 モナドでC言語かよ！ということをやろうとする。 しかして正しく正面玄関から入ろうとすると、難解過ぎる。 MLの方がそういう意味でも適度に関数型な気がする。 純粋関数型を言うならば、遅延ストリームでゴリゴリ書くのが基本に なってるような言語であるべきかなと思ってみたりする。

---

---

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

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