関数型プログラミング言語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の仕様により、行頭の半角スペースは表示されません。 　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。 655 名前：デフォルトの名無しさん mailto:sage [2008/08/29(金) 14:13:46 ] ReadPはdata宣言じゃなくてnewtype宣言だから、 記述上は包まれた形になってるけど、実装では包みが外れた形になる。 参照: haskell.g.hatena.ne.jp/jmk/20061203/1165141002 Pは直接的にはうまく束ねることができないから、一旦仮想的なReadPで束ねてるって感じ？ 656 名前：デフォルトの名無しさん mailto:sage [2008/08/29(金) 15:53:54 ] >>655 どうもありがとうございます。 実際にはReadPの所はR Get やR Lookなどが渡されることになりますよね。 そのあとすぐにrunで即Rはずしてますし。 ＞Pは直接的にはうまく束ねることができないから これってどういう意味で仰ったんですか？ P を束ねてパーサとして使うことも、実際できる（>>654のget'など）のでわざわざどうしてReadPにするのか、 Pの>>=が左結合的に作用するのが問題らしいんですけどそれが問題になる具体的なケースについて 私にはｻｯﾊﾟﾘ思い付かなかったので先人たる皆様にお聞きしたかった次第です。 657 名前：デフォルトの名無しさん mailto:sage [2008/08/29(金) 17:28:28 ] >>654 ReadP の計算で左結合になってる >>= がある場合でも、 内側の P の >>= をすべて右結合にすることで、 P の >>= の再帰が無くなって効率が良くなる。 9節の第1パラグラフに書いてある通りなんだけど。 左結合を右結合にってのは、>>= の結合則 (m >>= f) >>= g == m >>= (\a -> f a >>= g) の左辺を右辺にするってな話。 例えば、string s >>= f でも string s の中で >>= を使ってるので、左結合になってる。 つまりほとんど全ての場合に当てはまる。 658 名前：デフォルトの名無しさん mailto:sage [2008/08/29(金) 17:29:19 ] 効率が悪くなる事情は、そこにも書いてあるようにリストの ++ と同じ。 リストの ++ は左引数に関して再帰する。 [] ++ ys = ys (x:xs) ++ ys = x : (xs ++ ys) そのため (xs ++ ys) ++ zs は xs に関して二重に再帰することになる。 foldr (++) [] (map show [1..10000]) foldl (++) [] (map show [1..10000]) 実際これらを実行してみると前者はすぐ終わるけど、後者は "1" を10000回結合、 "2" を9999回結合、... "10000" を1回結合、みたいになって遅い。加速してくけど。 遅いだけじゃなく、中間リストを生成するので無駄にメモリを使うことにもなる。 foldl は極端な例だけど、foldr も極端で、いつも無駄が無いようにはいかない。 659 名前：デフォルトの名無しさん mailto:sage [2008/08/29(金) 17:30:18 ] で、回避策。 xs ++ ys は、xs の最後の [] を ys に置き換える。 それを効率よくやるには、最初っから [] なんか使わないで、 1:2:3:[] を \nil -> 1:2:3:nil みたいにしとけばいいじゃんという発想。 つまり [a] を [a] -> [a] に、xs を xs ++ に、++ を (.) にする。 こうしておくと、[] を与えてリストに戻すときには、 (.) が右結合になってなくても ++ は右結合になる。 (((xs ++) . (ys ++)) . (zs ++)) [] = ((xs ++) . (ys ++)) (zs ++ []) = (xs ++) (ys ++ (zs ++ [])) = xs ++ (ys ++ (zs ++ [])) 実際 String の ++ を頻繁に使う class Show あたりでは、 できるだけ type ShowS = String -> String を使うことになってる。 shows :: Show a => a -> ShowS を使ってさっきの foldl (.) id (map shows [1..10000]) [] をやってみると、今度は問題無く速い。 660 名前：デフォルトの名無しさん mailto:sage [2008/08/29(金) 17:31:29 ] で、ReadP。 m >>= f (P の >>=)は、m の最後の return a を f a に置き換える。 それを効率よくやるには、最初っから return なんか使わないで、 Get (\c1 -> Get (\c2 -> return [c1,c2])) を \k -> Get (\c1 -> Get (\c2 -> k [c1,c2])) みたいにしとけばいいじゃんという発想。 つまり P a を forall b. (a -> P b) -> P b に、 m を m >>= に、>>= を \m f k -> m (\a -> f a k) にする。 以下略。 661 名前：デフォルトの名無しさん mailto:sage [2008/08/29(金) 17:32:22 ] で、余談。 foldr c n xs は、xs の : を c に、[] を n に置き換える。 それを効率よくやるには、最初っから : や [] なんか使わないで、 1:2:3:[] を \c n -> 1 `c` 2 `c` 3 `c` n みたいにしとけばいいじゃんという発想。 つまり [a] を forall b. (a -> b -> b) -> b -> b にする。 リストに戻すときは build xs = xs (:) [] を使う。 すると foldr c n (build xs) ==> xs c n と変換できる。 map f xs <==> build (\c n -> foldr (c . f) n xs) 例えばこういう変換を定義すれば、 (map f . map g) xs = map f (map g xs) ==> build (\c n -> foldr (c . f) n (build (\c n -> foldr (c . g) n xs))) ==> build (\c n -> (\c n -> foldr (c . g) n xs) (c . f) n) ==> build (\c n -> foldr (c . f . g) n xs) ==> map (f . g) xs のように map f . map g ==> map (f . g) という変換ができる。 map f . map g 以外にも、他のいろいろなリスト関数の foldr/build を使った形への変換を定義しておけば、いろいろな変換ができる。 foldr/build による融合変換ってやつ。今の GHC もこれを使ってる。 詳しくは GHC User's Guide の 8.13. Rewrite rules あたりを見てくれ。 662 名前：デフォルトの名無しさん mailto:sage [2008/08/29(金) 18:19:15 ] >>657-661 とても分かりやすい解説どうもありがとうございます！ ちょっと解決の糸口がつかめた感じがします、これからじっくり考えてみたいと思います。 とてもご丁寧にありがとうございました。 流石だ。。。 663 名前：デフォルトの名無しさん mailto:sage [2008/08/30(土) 18:34:32 ] Haskellが宣言型言語とか最初に言い出したのは誰なのかしら 664 名前：デフォルトの名無しさん mailto:sage [2008/08/30(土) 18:44:45 ] imperative language ←→ declarative language の対比で ごく自然発生的なものだと思うが？ 665 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 00:07:29 ] 宣言型言語 = what（何をしたいか）を記述 手続き型言語 = how（どうやるか）を記述 クロージャをいかに早めに潰すかに苦心するHaskellは後者ですな 666 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 00:38:36 ] >>665 宣言型言語＝述語論理を記述 と思ったらHaskellも述語論理の仕様記述言語に非常に近い特徴を持っていることに気づく。 667 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 03:38:00 ] >>665 > クロージャをいかに早めに潰すかに苦心 ってどういうこと？ 668 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 09:45:13 ] >>667 関数のインライン展開のようなものじゃないか よく分からんが 関数リテラルなら展開しやすいが高階関数の戻り値のクロージャは展開しにくい気がする だからどう書くか (how) を工夫する 人間が問題を「宣言」するだけでコンパイラが問題を解いてくれる というのは 素朴な解決策は簡単に見つかるのだが最適化が難しい (が機械的にできる) 問題に限定されるはず 669 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 15:47:12 ] 計算資源が有限なため、howが分からないとwhatも記述できないという罠 670 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 15:59:09 ] 本質的には what -> how の書き換えと how -> how の最適化は似たようなもんだからな。 最適化は手続き型でもやってるから、非手続き型の人はwhatの部分を強調してみたりC/C++より速くなると言ってみたり。 LLの人は最適化にあまり拘らないし、テストさえ通ればhowを直接書いてもいいやって感じだけど。 671 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 17:18:22 ] >>667 >>600前後の流れ参照 要するに未評価の式(これはクロージャで実装されてる)を溜め込まないように注意する必要がある 672 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 20:51:42 ] しかし、そんなこと言ってたらprologだって宣言型と言えなくなるんじゃない? 673 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 21:42:38 ] お前らは 人間の性格はA型B型O型AB型の4種類に分けることができる とか思ってそうだよな。 674 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 23:36:24 ] なんでも過不足なく分類できると思い込む愚かさ 血液型と性格をろくな検証なしに簡単に結びつけてしまう短絡さ どっちをさしてるのか紛らわしいので例としては不適 675 名前：デフォルトの名無しさん mailto:sage [2008/09/01(月) 01:06:10 ] >>674 おもしろおかしい 676 名前：デフォルトの名無しさん [2008/09/01(月) 07:57:32 ] www.realworldhaskell.org/blog/2008/08/22/our-writing-is-now-complete/ 書き終わったって。 677 名前：デフォルトの名無しさん mailto:sage [2008/09/01(月) 15:40:49 ] zipで(ry 678 名前：デフォルトの名無しさん mailto:sage [2008/09/02(火) 14:15:50 ] >>666 プ 試しにZあたりの実行系でもつくってみればw 679 名前：デフォルトの名無しさん mailto:sage [2008/09/02(火) 17:56:25 ] >>678 何が言いたいのははっきり言え。 小馬鹿にするだけでは情報価値ゼロだぞ。 680 名前：デフォルトの名無しさん mailto:sage [2008/09/03(水) 08:50:51 ] 述語論理なめんな、ってことじゃね？ せめてホーン論理に限定するとかじゃないと話にならんだろ。 681 名前：デフォルトの名無しさん [2008/09/03(水) 23:53:10 ] 関数とKleisli以外のメジャーなArrowってあるの？っていうかArrowって死滅したの？ 682 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 00:04:13 ] >>676 おお！でも英語疲れる。訳書出版の予定はないの？ 683 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 01:25:52 ] >>681 死滅しそうなのはHaskellだが、新しいHaskellのライブラリはほとんどArrowベースだよ。 684 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 11:41:24 ] このスレって嘘多いよな。 685 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 12:00:02 ] このスレって〜 ってレス多いよな。 686 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 15:00:58 ] そういえば、大学入試のときに大学ランクとタバコの関係に気づかされたなぁ・・・ 東大　誰も吸っていない 京大　誰も吸っていない 同志社大　ちらほら 関西大　校舎内で吸っているやつがいる（！！！） ありえないです、低ランク大・・・ やっぱりランクの低い大学出身のやつは信用できない・・・ 687 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 15:19:00 ] そして増える意味不明なレス 688 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 15:20:04 ] >>684 素人なのでどの変がうそなのか教えてください 689 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 15:45:52 ] ６８６みたいな奴がhaskellを使うとはとても思えんのだが、 何しに来てるのかね？ 690 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 15:50:35 ] >>689 Haskellがどういうものだと思っているんですか？ 691 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 17:36:25 ] >>686は今マルチされてるコピペ、スルー推奨です。 692 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 19:33:03 ] >>690 全角数字を見るといらっとくる人が使う言語 693 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 19:35:16 ] 確かにイラっときた 694 名前：デフォルトの名無しさん mailto:sage [2008/09/04(木) 21:21:38 ] >>６９３ それはカルシウム不足 695 名前：デフォルトの名無しさん [2008/09/06(土) 23:15:53 ] Haskellで良いコード綺麗なコードというのはどんなコードですかね。 出来るだけ変数使わない方がいいとか、何が何でもポイントフリーにするとか、 あるいはそれ以外でも、何でも。 696 名前：デフォルトの名無しさん mailto:sage [2008/09/06(土) 23:55:28 ] >>695 y f = f (y f) 697 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:05:33 ] >>695 haskellでは数学的にきれいなコードが「きれいなコード」と呼ばれます。 698 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:12:32 ] 良いコード: 意味のあるところでControl.*を使う 悪いコード: ポイントフリーのためにControl.ApplicativeやControl.Arrowをimport 699 名前：デフォルトの名無しさん [2008/09/07(日) 00:15:18 ] っていうか、ポイントフリーってなにがいいの？せっかくパターンマッチがあるのに。 >>687 ライブラリはそうだろうけど、普通のアプリを書くときは？ 700 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:33:20 ] 単純な場合には無駄に変数が増えず、シンプルに分かりやすくなるから良い。 複雑な場合には無理をしても分かりにくくなるだけだから悪い。 パターンマッチとは使いどころが違う。 701 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:34:19 ] >>699 圧倒的に短く書けるからだよ。 それにポイントフリーだと関数の入出力の流れみたいなのがまっすぐ表せるから、処理の全貌が見通しやすい 702 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:41:52 ] まっすぐだけど、流れが逆じゃん。 というわけで>>>使うのはやっぱダメ?逆なのに脳味噌合わせるべきなの? 703 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:46:48 ] GUIアプリを書くときはどういうのが綺麗なんだ？ 704 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:59:26 ] >>702 逆なの？ y = f x より x f = y が脳味噌に合ってるの？ 705 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 01:11:04 ] >>704 なんでやねん。 unlines . take 10 . filter (> 10) . map read . lines より、 lines >>> map read >>> filter (> 10) >>> take 10 >>> unlines の方が、少なくとも俺は脳に優しく感じる。 で、こう書くと、map read と filter (> 10) を分けてるのが冗長でダサい気もするが、 (filter (> 10).read)みたいにした方が良いのか、かえってこっちの方がダサいのか、 あるいは、(filter (\x -> 10 > read x)) みたいにラムダにすべきなのか、綺麗の勘所が判らんのです。 706 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 01:12:53 ] >>705 あ、前半がStringに戻してないのはご愛敬と言う事で、よろしく。 707 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 01:32:55 ] >>705 String に戻さないといけないなら filter ((10 <) . read) だろう。ラムダでもいいけど。 まあ、その辺はこだわるとこでもないかと。 > なんでやねん。 f (g x) と (f . g) x の向きは関係あるんですよ。 数学でも向き的事情から x^f という記法を使うこともある。 708 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 02:23:43 ] >>702 左から右だろうが右から左だろうがどっちでも一緒だろ。 俺には違いが分からん。 709 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 02:27:05 ] >>702 こういう反抗したい年頃のやつが言語を汚くしていくんだろうな。 なんでもないものを指差して「使いにくい」などと言ったり、まるでガキ。 710 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 03:31:39 ] 現代日本では横書き文字は左から右だから、 その方が自然に感じるのは当然と思います。 また、bind演算子が(>>=)で左結合である事を考えても Haskellを設計した人もその方が自然と感じたのではないでしょうか？ 慣れの問題かもしれませんが、 そんなにおかしな意見とは思えません。 711 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 07:34:52 ] まあ関数合成の向きが右から左なのは>>707の説明の通りだし、Haskellに限らず数学でも同じルールだからな。数学でも気持ち悪いって云う人は結構居るしまあそんなに変わった意見でもあるまい。 712 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 21:48:37 ] 社内コーディング規約でここにスペースを入れろとかそういうのよりは高尚が感じがするかもしれないけれど 所詮バイクシェッド 乱用すれば読みにくいし、パズルみたいにポイントフリーするのは間違ってる 数学的に綺麗綺麗とか、圏論的に自然とかというけれど、誰でも圏論がわかるわけじゃないし。 しかし、いかにポイントフリーで書くか、という事を考えると確かにおもろいよ 713 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 21:56:43 ] 亀だが >>36 >FPGAとかのHDL記述とかに応用したりしてる人いないの？ Lavaがあるよ。並列性とか関係ないし、回路をそのまま関数で書くだけなんだけど。そしてVerilogより使いやすい、なんてこたーない。HDLよりましだが、副作用を書くのがまわりくどい www.cs.chalmers.se/Cs/Grundutb/Kurser/svh/tools.html 714 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 22:31:52 ] s/HDL/VHDL/ 715 名前：デフォルトの名無しさん mailto:sage [2008/09/08(月) 21:55:12 ] >>713 ArrowっぽいHDL作りたいな 716 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 18:48:21 ] Real World Haskell November 15, 2008 待ち遠しい。 717 名前：デフォルトの名無しさん mailto:sage [2008/09/12(金) 22:50:22 ] 過度の並列化で複雑化するゲーム開発 コスト削減の鍵は純粋関数型言語らしい www.watch.impress.co.jp/game/docs/20080911/epic.htm 718 名前：36 ◆K0BqlCB3.k mailto:sage [2008/09/12(金) 22:54:50 ] >>717 そうだろうね。 俺はずううっと前からそう論文に書いてたけど。 だんだんpi-calculusの人気が出てきたね。 719 名前：デフォルトの名無しさん mailto:sage [2008/09/12(金) 23:58:55 ] >　Sweeney氏は純粋関数型言語のもつ並列処理安全性に着目しており、 >将来的にゲームプログラミングはそういった処理系に移行していくべきだとした。 >Sweeney氏はそのひな形として言語“Haskel”を挙げているが、 >ゲーム開発のメインストリームたり得る言語はまだ登場しておらず、将来に期待しているという。 なんでHaskellは駄目なんだろう。 ライブラリ含めた開発環境の問題か処理系の最適化の問題か それとも言語仕様レベルで本質的に向いていないのか。 720 名前：デフォルトの名無しさん [2008/09/13(土) 00:06:19 ] 前者じゃない？ 721 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 00:09:07 ] こんなことでもないと注目せんのだな 722 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 00:48:51 ] 遅延評価に漬かりまくりで、ダメなのでは？ 遅延評価って言ってみれば、後ろからの逐次でそ？ 無限リスト使えないHaskellってHaskell？ 723 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 07:07:42 ] LazyがいやならSMLやOCAML使えばいいだけ。何が不足よ？ 724 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 08:23:12 ] >>723 前方参照，where構文 725 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 09:32:44 ] >>724 LETで何が不足よ？ 726 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 10:42:16 ] >>717,>>719からのコンテキストを読んでくれよ。 727 名前：デフォルトの名無しさん mailto:sage [2008/09/15(月) 18:14:08 ] 質問です たとえばJavaなどではクラスのインスタンスをオブジェクトと呼びますが、 Haskellの代数的データ型に格納されたデータのことをなんと呼べば良いですか？ 728 名前：デフォルトの名無しさん mailto:sage [2008/09/15(月) 18:21:45 ] >>727 関数 729 名前：デフォルトの名無しさん mailto:sage [2008/09/15(月) 19:00:09 ] >>727 「オブジェクト」に対応する用語は普通は「値」でいいんじゃないか >Haskellの代数的データ型に格納されたデータ これどういう意味？ 型が代数的データ型であるような値のことならそのまま「代数的データ型の値」 代数的データ型の構築子に渡した値のことなら「フィールドの値」くらいか？ data Point = Pt Int Int x = Pt 0 3 -- xはPoint型の値 -- xのフィールドの値は0と3 730 名前：デフォルトの名無しさん mailto:sage [2008/09/15(月) 20:26:27 ] Haskellのプログラミングスタイルのことはなんて呼べばいいですか？ ストリーム指向？ 731 名前：デフォルトの名無しさん mailto:sage [2008/09/15(月) 20:30:20 ] 関数指向 732 名前：デフォルトの名無しさん mailto:sage [2008/09/16(火) 23:55:40 ] Haskell系のShellでオススメってある？ 733 名前：36 ◆K0BqlCB3.k mailto:sage [2008/09/17(水) 00:00:30 ] >>732 シェルって何のこと？ 言語とは関係ないと思うけど。 シェルスクリプトのことを言っているの？ 734 名前：デフォルトの名無しさん mailto:sage [2008/09/17(水) 00:07:44 ] >>733 HSHみたいなやつ 探してみた奴だとどれも開発止まってて… 735 名前：デフォルトの名無しさん mailto:sage [2008/09/17(水) 00:09:07 ] Haskell風構文のシェルっていくつかあるんだな、ググって初めて知ったわ 736 名前：デフォルトの名無しさん mailto:sage [2008/09/17(水) 00:15:11 ] Haskell系の自然言語でオススメってある？ 737 名前：デフォルトの名無しさん mailto:sage [2008/09/17(水) 00:22:13 ] lojbanとか？ 自然言語じゃないけど 738 名前：デフォルトの名無しさん mailto:sage [2008/09/17(水) 15:52:29 ] Yiとか使ってる人いるの？ 739 名前：デフォルトの名無しさん mailto:sage [2008/09/17(水) 17:56:30 ] Yi って 彝 ? 740 名前：デフォルトの名無しさん [2008/09/17(水) 18:20:56 ] ぅぃ？ 741 名前：デフォルトの名無しさん mailto:sage [2008/09/17(水) 18:31:27 ] haskell.org/haskellwiki/Yi 使ったこと無いなぁ。 742 名前：デフォルトの名無しさん mailto:sage [2008/09/19(金) 17:29:49 ] ひょんなことからerlangを勉強し始めたが、構文はともかく、思想としては面白いな。 並行指向プログラミングというのかな？ このパラダイムはオブジェクト指向よりも現実志向のパラダイムのように思う。 Haskellでも並列化がうまくいけばerlangみたいな仕組みを実装できるかもしれない。 # erlangの構文は糞　糞　糞　糞杉 743 名前：デフォルトの名無しさん mailto:sage [2008/09/19(金) 18:18:31 ] ぅぃゅ 744 名前：デフォルトの名無しさん [2008/09/19(金) 20:28:25 ] コンカレントハスケル？ 745 名前：デフォルトの名無しさん [2008/09/19(金) 20:34:40 ] ああ、コンカレントは並行だったか・・・ 746 名前：デフォルトの名無しさん mailto:sage [2008/09/20(土) 11:00:42 ] >>743 私はProlog屋なので、erlangの構文のクソ部分に敏感でない。 お手数かけて恐縮だが、糞の部分を列挙していただけると有難いのだが。 747 名前：a36 ◆K0BqlCB3.k mailto:sage [2008/09/20(土) 12:04:07 ] >>742 たぶん、その思想というのはpi-calculusのことかな。 748 名前：デフォルトの名無しさん mailto:sage [2008/09/20(土) 13:08:03 ] ここのみんなからするとgtk2hsって綺麗なの？ 749 名前：デフォルトの名無しさん mailto:sage [2008/09/20(土) 13:29:19 ] Erlangってpi-calculusベースなのか 750 名前：デフォルトの名無しさん mailto:sage [2008/09/20(土) 13:56:48 ] >>746 743ではないけど、 receive...endとか、カリー化できないとかではないですか? 751 名前：デフォルトの名無しさん mailto:sage [2008/09/20(土) 14:52:33 ] >>723 元記事ではSTMが挙げられてるけど、OCamlだと無くね？ >>749 綺麗って何が？Gtk2Hsを使ったコード？ それならあまり綺麗じゃないんじゃない。 GUIを綺麗に書くためのハイレベルなライブラリは いろいろあるけど、どれも決定打にはなってないような。 752 名前：デフォルトの名無しさん mailto:sage [2008/09/20(土) 15:23:34 ] >>751 >>749 じゃなくて >>748 ? 753 名前：デフォルトの名無しさん mailto:sage [2008/09/20(土) 15:27:39 ] >>752 >>748な俺からでもそれはわかる。 754 名前：デフォルトの名無しさん mailto:sage [2008/09/21(日) 00:46:57 ] gtk2hsと言えば、 gtk_rc_parse_string相当の関数や、 gtk_widget_modify_cursor（これは新しいからか）相当の関数が見付からなくて諦めたことがあります。。 いや私の検索能力が低いだけだと思うんですが、かなり頑張ってもどうしても見つかりませんでした。。。 皆さんgtkやpango、gdkの関数を捜すときってやっぱり根性ですか？ 大抵はキャメルケースにすれば大丈夫ですがそうでない時はかなり困りますよねー。。 755 名前：デフォルトの名無しさん mailto:sage [2008/09/21(日) 12:17:25 ] いや、検索能力の問題じゃなくて、実際に無いんじゃない？ Gtk2Hsのソースgrepしてみて無かったら無いような。

---

---

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

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