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

1 名前：潜伏していた1 mailto:sage [02/02/16 16:55] 何とか生き残れました。 前スレ pc.2ch.net/test/read.cgi/tech/996131288/l50 関連 >>2 以降 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の方がそういう意味でも適度に関数型な気がする。 純粋関数型を言うならば、遅延ストリームでゴリゴリ書くのが基本に なってるような言語であるべきかなと思ってみたりする。 118 名前：デフォルトの名無しさん [02/05/05 18:12] いいんじゃねえの？ 多目的言語なんだから。 119 名前：Super Combinator [02/05/05 23:13] >>104 > Haskell（特にGHC）って例外処理とか、入出力じゃない副作用も > どんどんIOモナドに入ってるじゃん。 最近Haskellの動向は探ってないんだけどこれ本当? IOErrorがIOモナドmoduleにあって、 HaskellがIOError以外ろくに例外をsupportしないだけなんだと思ってたよ。 120 名前：デフォルトの名無しさん mailto:sage [02/05/06 02:01] 勉強中だからよく分かんないけど、state モナドの事？ 121 名前：デフォルトの名無しさん mailto:sage [02/05/06 03:57] MLと（Haskellとも）離れますが、 モナドを使うと、手続き型言語を 関数的に解釈することができますか？ 122 名前：デフォルトの名無しさん [02/05/06 10:53] >>121 「関数的に解釈」の意味がよくわからない。 Haskellでインタープリタが書けるか？ という意味じゃないよね。 123 名前：デフォルトの名無しさん [02/05/06 11:38] sato-www.cs.titech.ac.jp/prism/index.html 124 名前：デフォルトの名無しさん mailto:sage [02/05/06 12:35] >>122 モナドを使うと、どうみても副作用な操作でもfunctionalな 操作と解釈できるわけですが、それと同じように手続き型言 語のプログラムに純関数的な意味を与えることができますか？ という意味です。 125 名前：デフォルトの名無しさん mailto:sage [02/05/07 00:50] >>124 Idealized Algolとかいうのがなかったっけ。 126 名前：デフォルトの名無しさん [02/05/07 01:16] グローバル変数が見当たらないんですが・・・ 127 名前：デフォルトの名無しさん mailto:sage [02/05/07 18:47] >>121 >>124 できません。 強引に無理矢理こじつけることならできるかもしれないけど意味無し。 128 名前：デフォルトの名無しさん mailto:sage [02/05/07 19:13] >>124 モナドを使えば、代入、逐次的実行、手続き型ライクなI/O、例外などを 純関数型の枠組みで扱える。gotoくらいならもともとモナドに関係なく 等価な純関数型言語に変換することができる。 Cは無謀だがMINIMAL BASICくらいなら、純関数型とみなすことは可能だろ う。 129 名前：Super Combinator [02/05/07 20:21] >>124 Denotational semanticsじゃ駄目? domainの性質がやっかいになるから、いいことないけど。 そもそも「簡単に」できるくらいなら、関数型言語の存在意義が… 130 名前：デフォルトの名無しさん [02/05/07 22:49] Haskellで書いたプログラムに、関数的意味を与えうるなら、 手続き型の言語のインタープリタを Haskell で書いたら、 その言語の意味を与えたことになる？ ならない？ 131 名前：デフォルトの名無しさん mailto:sage [02/05/07 23:11] >>130 なるんじゃない？ きちんとやれば操作的意味論だろ。 132 名前：デフォルトの名無しさん [02/05/08 00:35] 結局、Haskellは非正格言語なのが問題じゃない？ 実際に各項が何時評価されるか？どういう順番で評価されるか？ ということが予測しづらい(できない)からねー。 その点、正格言語や手続き型言語は評価の順序が一目瞭然だからねー。 Prologにカットオペレータがあるように、Haskellも競争書き込みで 評価の順序を、ある程度コントロールできる様にしたらよいのかな？ 133 名前：デフォルトの名無しさん mailto:sage [02/05/08 00:39] >>132 ？？ 問題なのは結果であって、 順番なんてどうでも良いだろう。 順番じたいが望む結果に含まれる (例えば入出力とかGUIとか)なら、 そこだけモナド使えば良いしさ。 134 名前：デフォルトの名無しさん [02/05/08 07:47] >>133 133も書いていますがコンピュータの入出力は ストリームを基本としているものが多いですよね。 しかし、ストリームにとって並び方も結果の内ではないでしょうか？ プログラムは外部と入出力して、なんぼのものだと私は思っています。 ゆえにストリームのようなモノに対して実行順序がコントロールできることは プログラミング言語にとって重要であると思います。 そうじゃなきゃPrologもカットオペレータなんて付けなかった と思います。 あと私のような消防には、実行される順序が予測できないと デバッグしづらいです。(もしかして、こっちが本題か？) 135 名前：デフォルトの名無しさん mailto:sage [02/05/08 08:13] >>134 ほんとに消防だな。Haskellだって ストリームの順番が狂うわけはないだろう。 ストリームは「いくらでも長くなりうる列」 というデータだ。関数型の基本はデータの値を 求めることなんだから、モナドなんか用いなくたって ちゃんと求まる。 136 名前：チュウボウ [02/05/08 09:56] なんで副作用って困るの？　よく聞くはなしでは 　副作用あり＝＞参照透過性がない＝＞数理論理的でない 数学って、まったく副作用のない構成になっているの？ 137 名前：デフォルトの名無しさん mailto:sage [02/05/08 10:03] > 数学って、まったく副作用のない構成になっているの？ 副作用がなんなのかわかってる? 138 名前：デフォルトの名無しさん [02/05/08 10:04] 副作用が無ければ、デバッグ簡単 139 名前：チュウボウ [02/05/08 11:10] ＞副作用がなんなのかわかってる? オレの理解 　状態という一種の記憶域のようなものがあってその値が 　変わること。 数学ではオートマトンとか除けば、状態のような概念は 知らない。 140 名前：デフォルトの名無しさん mailto:sage [02/05/08 11:55] >>136 評価順序に依存してるから 141 名前：チュウボウ [02/05/08 12:32] 順序なしで考えるより、順序を指定されて考える方が楽じゃない？ 142 名前：デフォルトの名無しさん mailto:sage [02/05/08 12:34] >>141 そう思えるのはモノが単純な場合だけ 143 名前：チュウボウ [02/05/08 12:49] 状態（もの）と動作（働き）があった方が考えやすい気もする。 主語＋述語が人間の頭にあってるような気がする。 （状態があるならば副作用があると思ってる） ペトリネットなんかかじってみてると、そんな気がしてきた。 ttp://www.aichi-pu.ac.jp/ist/~qua/intropn/intropn.html 144 名前：デフォルトの名無しさん mailto:sage [02/05/08 15:04] 副作用って､関数が値を返す以外の何かの作用を起してしまうことでしょ。 「なぜ関数プログラミングは重要か」に副作用が無い事のよさが力説されてた。 実感湧かなかったが。 145 名前：デフォルトの名無しさん mailto:sage [02/05/08 18:09] >>143 日本語は主語なんかなくても良い言語だよ。英語カブレめ（ｗ 実際この書き込み(145かな？)のなかに主語のある文は一つもないが、 意味はちゃんと通じるだろ？ 146 名前：５月病 [02/05/08 18:24] オレも人並みにSOE本ながめたりして、haskellの理解に 努めたわけよ。モナドの意味もつかもうとしてがんばった んだけど、あるときふと、こんなに無理して副作用さけよう という努力はなんなんだろうと感傷的になるわけよ。 147 名前：デフォルトの名無しさん mailto:sage [02/05/08 18:26] Cでグローバル変数はやめよう、と似たようなもんじゃないの？ 148 名前：チュウボウ [02/05/08 18:35] >>145 >日本語は主語なんかなくても良い言語だよ おお、そうであった。日本語は述語だけでつうじるのだ。 日本語こそ真の関数型言語であった。なんてわけないか。 149 名前：デフォルトの名無しさん mailto:sage [02/05/08 18:47] >>146-147 つーか… プログラムって要するに「入力と出力の関係を記述する」 ってだけで良いはずなのに、状態を持ち出すとよけい面倒に なることも多いでしょ。 150 名前：５月病 [02/05/08 19:00] モナドを使い、高階関数を使い、入力と出力の関係だけで ストイックに記述する。そうすると見えるすばらしい世界 を教えてください。 151 名前：デフォルトの名無しさん [02/05/08 19:02] >>149 > 入力と出力の関係を記述する 時系列的な入力と出力の表現には内部状態があった方が記述が楽。 あと、入力の長さが不定なときも。 だから入力に対して反応するタイプのプログラムでは状態記述がないと不便。 >>145 主語がなくていいのは主語が明らか（容易に推測可能）な時だけだよ。 フォーマルな文章では日本語だって主語が必要。ここはかなりインフォーマルだからね。 ちなみに英語でも命令形などでは明らかな主語が省略されている。 152 名前：デフォルトの名無しさん [02/05/08 19:14] >>151 なんで、ストリームやモナドなどではプログラムの動作が完了した時点では 入力が決定して、出力も決定する筈ということに注目して、 実行時に対応関係を組み立てるわけだ。 153 名前：デフォルトの名無しさん mailto:sage [02/05/08 19:19] 無限列から無限列への対応関係を陽に書くことはできないが、 無限列の有限部分列から有限部分列への対応関係なら書ける。 そしてその対応関係が再帰的に定義できているなら、 限りなく計算を続けられる。 ただ、有限部分列の入力から続きを計算する際に何度も同じ計算が 繰り返される場合がある。そういう場合は内部状態としてメモしておけば 計算効率が改善される。 154 名前：デフォルトの名無しさん [02/05/08 19:21] >>153 現実的にはどんなケースがありますか？ 155 名前：デフォルトの名無しさん [02/05/08 19:39] 無限ストリームはメッソドの呼び出しを遅延評価するように しておけばJavaなんかでも再帰的に記述できるよ。 156 名前：デフォルトの名無しさん mailto:sage [02/05/08 19:49] >>154 httpプロクシサーバとか。 リクエストは無限列とみなせる。 以前にあったリクエストなら、内部状態としてキャッシュしとけば 速くなる。この場合でも副作用は別に必須じゃないけどね。 157 名前：デフォルトの名無しさん mailto:sage [02/05/08 20:42] 多分もっと技術レベルが高かったら萌えるんだろうなぁ。 今はC、C++、C#、Javaで手一杯だよ･･･ 158 名前：デフォルトの名無しさん mailto:sage [02/05/08 20:47] >>156 副作用が絡むのは配列やオブジェクトの部分更新とかが絡むときが典型。 もちろん更新する値以外も全部複製してしまえば副作用は消せるが、 効率は･･････（ガクガクブルブル） ---- >>155 遅延評価は評価の仕方を「メモ」って行くわけだが、 結構、後でそのメモ・ツリーを辿るのに時間がかかったりする。 159 名前：153 mailto:sage [02/05/08 20:50] >>157 てひひひー。C#は全然把握してないッスー。 160 名前：デフォルトの名無しさん mailto:sage [02/05/08 21:19] C#っていってももともとは.net frameworkのために作られた言語だからね。 シンタックスだけはJavaに似てるけど。逆に言語から仮想環境を想定するとしたら どんなものになるんだろね。Hakell、というより関数型言語全般のために 作られたようなもの。あるとしたらどんなもんでしょ？ 161 名前：153 mailto:sage [02/05/08 21:28] 仮想環境ッスかー？何ッスかー？ 162 名前：デフォルトの名無しさん [02/05/09 01:26] Parallel Graph reduction Virtual Machine (PGVM) ? 163 名前：134 [02/05/09 01:31] >>135 >ストリームは「いくらでも長くなりうる列」というデータだ。 確かに漏れも、そう思います。ストリーム() しかし、haskellのモデルではIO入出力はストリーム(ぎリスト)ではないですよね。 ということは結局、評価の順序が入出力に影響するはずですよね。 評価の順序を強制するためにモナドというものを利用しているんじゃないですかねー？ どうなんでしょ。 164 名前：デフォルトの名無しさん [02/05/09 01:48] www.yfcbookshelf.com/ml_lisp_scheme.htm ここの下の所に「Programming Languages：Concepts and Constructs 2/E」 の「日本語訳版を期待」という文字が見えるんですが、今翻訳中なのでしょうか？ もしそうなら超期待！！ >>158 どうも効率面を問題にされているようですが、 私自身たいして関数型言語の経験はありませんが、 仕事の関係上感じている事です。 コンパイラ作ってると、この副作用がないというのが 結構オプティマイズに有効だったりするので、 結構これからの言語の核にすえるのは悪くないと最近思ってます。 計算の依存関係が明白でないと最近のスーパスカラーみたいに 命令スケジュールが必要だと面倒です。 全体的とはいわなくても部分的には関数型言語が高速化への寄与大きいと考えています。 計算機の並列度が上がってくると、少し考え方を変えてみるのも悪くはないと思っています。 ちなみにモナドはあんまり良くわかっていません。(TT) だれか教えてくれー 165 名前：デフォルトの名無しさん mailto:sage [02/05/09 02:25] >>163 昔のバージョンではストリームでI/OやってたんだよHaskellは。 I/Oエラーが扱いにくくってなあ… モナドの方が楽だよ。 166 名前：134 [02/05/09 02:43] >>165 本当ですか？ 何時の頃のモノなんでしょう？ 処理系の名前とバージョンを教えてもらえませんか？ >I/Oエラーが扱いにくくってなあ… >モナドの方が楽だよ。 たしかに、そうですね。 うーん、モナドから逃げてるのかなー？俺は 167 名前：デフォルトの名無しさん mailto:sage [02/05/09 02:45] モナドを意味づける（動作を定義する）のにストリーム使えるしね。 168 名前：デフォルトの名無しさん [02/05/09 02:46] 副作用推進派のかた、もっと高階関数を活用してみては どうでしょう？ 関数も各引数を繋ぐための糊だと考えると 副作用が無いほうが嬉しいのでは？ 169 名前：158 mailto:sage [02/05/09 02:50] >>164 効率は計算機上での実行の際のことです。 ･･････というか効率を考えた動作をガチガチにプログラマが記述する際に 場合によってはあるほうが便利ということですね。 一方、最適化のためのプログラムの解析においては 一般に副作用がないほうがやりやすいのは確かだと思います。 だからこそ代入を消してSSAなんて形式に落としたりもするんでしょうし。 170 名前：158 mailto:sage [02/05/09 02:51] >>168 行列を配列並みの高効率で実装できる方法があるなら是非そう致したいと。 171 名前：158 mailto:sage [02/05/09 02:54] 引数で指されるオブジェクトがコピーのコストが気にならないほど小さいうちは それほど悩ましくないんですが･･････。 172 名前：デフォルトの名無しさん mailto:sage [02/05/09 02:57] >>166 Haskell 1.1まではそういう仕様だった。全ての準拠処理系がそうなって たはず。stream I/Oとcontinuation-based I/Oの両方が使えた。 www.haskell.org/definition/haskell-report-1.1.tar.gz Monadic I/Oがあんまり便利なんで今は全部そっち。 173 名前：デフォルトの名無しさん mailto:sage [02/05/09 03:04] >>170 配列使えばいいじゃん。副作用なしの。 SISALっていう関数型言語がそうやって、スーパーコンでも Fortranに負けない性能出してたよ。 Fortran厨は他の言語が書けなかったので普及しなかったが。 174 名前：デフォルトの名無しさん mailto:sage [02/05/09 08:17] なんかこのスレ人増えたな。 175 名前：158 mailto:sage [02/05/09 09:51] >>173 　www.sys.uea.ac.uk/~jrwg/Sisal/index.html を読んで見てるけど、やたら配列に特化した言語だなぁ。APLを思い出したよ。 サワリの部分を読んでの感想としては、 配列に特化した構文が多すぎるし、拡張性にも疑問が残る。 この言語を実装する上で研究された内容（解析や最適化の技術）は有益そうだが、 それをつかって書けと言われると結構苦痛かも。 CやFortranのソースに混ぜられると言われてもねぇ。 176 名前：158 mailto:sage [02/05/09 10:01] でついでに、「スーパーコンでも」というよりは むしろ「スーパーコンのために」開発されたようだ。 スパコン以外にも移植はされているようだが、 どうもメインの技術ははデータ並列っぽい気配が。 もっと詳しく読んでみないと判らない部分もあるが、 そうなると今時のマシンの記憶階層と マッチするかどうかは些か怪しげ。 177 名前：Super Combinator [02/05/09 11:43] MonadとInfinite listの関係について知りたければ、 "Comprehending Monads", Philip Wadler読め。面白い。 178 名前：デフォルトの名無しさん mailto:sage [02/05/09 13:23] >>176 文句の多いヤツだな。 179 名前：デフォルトの名無しさん mailto:sage [02/05/09 15:07] >>158 は >>173 を「Sisal 使えば?」と読んでそうな感じだが >>173 は「Haskell の副作用無しの配列使え」と言ってるのだろう。たぶん。 180 名前：デフォルトの名無しさん mailto:sage [02/05/09 20:50] >>179 どんな実装してるんでソ。＞「Haskell の副作用無しの配列使え」 私が読んだ何件かの「副作用なし配列」の論文は皆頑張っていたけどヤパ−リ オーバーヘッドが大きくて生の配列ほどには早くない･･････。

---

---

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

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