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

1 名前：潜伏していた1 mailto:sage [02/02/16 16:55] 何とか生き残れました。 前スレ pc.2ch.net/test/read.cgi/tech/996131288/l50 関連 >>2 以降 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の方がそういう意味でも適度に関数型な気がする。 純粋関数型を言うならば、遅延ストリームでゴリゴリ書くのが基本に なってるような言語であるべきかなと思ってみたりする。 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 評価順序に依存してるから

---

---

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

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