関数型プログラミング言語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の仕様により、行頭の半角スペースは表示されません。 　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。 548 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 12:41:59 ] まだ横ばいならたいしたもんだ 549 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 12:48:26 ] >HaskellはライトウェイトではないからWEBアプリ向きとは全然思えないんだけど、 ライトウェイトって何？動的に型を付ければライトウェイト？ それとwebとどういう関係があるの？ 550 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 13:05:36 ] あまり考えずに気の向くままに書いてもあっさり動くのが ライトウェイトってことじゃないか？ web案件は短期だったりアジャイルだったりでライトウェイトに 開発できるのが求められてるってのはある 551 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 13:10:45 ] WEBアプリの開発者は、JavaかRubyのHowto本から入ってる。 だから、WEBアプリ開発者は、身体のどこかに、プログラミング言語のJavaかRubyに似てない部分に拒否反応を持ってる。 552 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 13:11:10 ] ここでHaskellは人間の思考過程に最も近いから 考えが即座にコードにうつせるため開発期間が最短であると主張する人がどこからか登場 　　　　　　　　　　　　　　　　　　　　↓ 553 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 13:23:23 ] 　　　　　　　　　　　　　　　　　　　　｜ 　　　　　　　　　　　　 　 　（ ﾟдﾟ　）↓ 　　　　　　　　　　　　　　　　 （⊃⌒*⌒⊂) 　　　　　　　　　　　　　　　 　　/__ﾉ''''ヽ__） 554 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 13:27:58 ] >>550 それならHaskellもライトウェイトで良くね？ 555 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 14:05:36 ] 明示的なコンパイル作業が必要ないってのはLLの必要条件な気がする。 556 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 14:18:04 ] LLとかWebアプリとか、 だから普及しないとか、 どうでもよくねえ? 好きな事、楽しい事すればいい。 557 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 14:22:47 ] >>555 runghcがあるじゃないか もうちょっと速ければと思うことはあるけど 558 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 14:34:05 ] >>556 そういう立場も理解できるけど、俺は普及してほしい ライブラリのメンテとか人が足りてないじゃん 559 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 14:46:33 ] >>552 Prologには負けるんじゃない。 560 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/22(金) 14:47:15 ] runghcはオーバーヘッドもかなり大きいみたいだね。 $ cat hello.hs main = putStrLn "hello" $ time runghc6 hello.hs hello real 0m0.835s user 0m0.780s sys 0m0.052s $ cat hello.rb print "hello\n" $ time ruby hello.rb hello real 0m0.015s user 0m0.012s sys 0m0.000s 561 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/22(金) 14:48:14 ] $ cat hello.pl print "hello\n" $ time perl hello.pl hello real 0m0.007s user 0m0.004s sys 0m0.000s $ cat hello.py print "hello" $ time python hello.py hello real 0m0.035s user 0m0.020s sys 0m0.016s 562 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 15:03:43 ] LLでHaskell関係のプレゼンとかしてる人いるみたいだけど？ 563 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 15:07:56 ] WebアプリとLL（と呼ばれている言語）との間には全く関係はないけど、 Webアプリのかなり大部分は一般的にLLと呼ばれている言語で書かれているだろう。 そういう"LL"はテキスト処理がしやすいからってのがあるだろうな。 まあHaskellがそういう意味で人気にならなくても別にどうでもいいけど。 ここでmondic Parser Combinatorを持つHaskellが 最もテキスト処理に適した言語であると主張する人がどこからか登場。 　　　　　　　　　　　　　　　　　　　　↓ 564 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 15:38:43 ] HaskellもLL言語だよ 565 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 15:45:06 ] これどうなの？ ttp://happs.org/ 566 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 16:09:31 ] Parser Combinatorがあるからテキスト処理ならHaskell最強だろ。 満足した？ 567 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 17:42:48 ] haskellは型推論がちゃんと効いてる使い方が出来れば、LL的な生産性は確保できるだろう。 だがな、至高の存在で良いじゃないか。 haskellの性質上webプログラミングは不得意分野に思うんだが、mod haskellなんて生まれる 分けでもないし生まれたところで破壊的操作がほとんどできないし、ファイル操作は基本的に 苦手でしょ。webは動的言語の親玉が一番向いてるけどs式アレルギーな人が多いからLLに なってるんでしょうね。 だから、無理にwebに擦り寄らずとも良いと思うんだけどね。むしろ、破壊的操作より安全性を 大切にされる金融などのところで目立つ存在になってくれたらいいんじゃないか？ 568 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/22(金) 18:09:07 ] >>567 もし金融などで使われることを想定するなら、 haskellの並列処理に関する部分も早く実装してほしいところですね。 （まだ未完成） 569 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 18:44:00 ] 某氏のhapps解説はお流れ？ >>567 > 破壊的操作がほとんどできない なんで？ 570 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 18:58:34 ] なんでそんなにHaskellの応用分野を限定したがるんだｗ >>567 コンパイルするならmod_haskellがあっても恩恵は小さいだろ >破壊的操作がほとんどできないし Haskellで入出力書いたことあるか？ >ファイル操作は基本的に苦手 これも良く分からん flock使うのにわざわざライブラリを落としてこないといけないとか、そういうこと？ 571 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 19:43:28 ] ウイルス対策ソフトのように危機感を煽るのはいいが、 既存のシステムを補強するのではなく全部作り直せというのは、ちょっとね 572 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 19:54:17 ] >>570 Prologを事務処理に使うと、住所や氏名情報などで爆発的にアトムが 発生し、Heap領域を埋め尽くして、GCが頻発するという事態となる。 もちろん数百万レコードを越える処理単位の話だが。 Haskellの場合この問題は起きないの? 573 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 20:37:03 ] Webアプリが苦手ってことは無いと思うんだけどな。今後Webベースのアプリは まだ増殖するだろうから、そっちで使いやすいフレームワークやDSLが出ないと 使う人は頭打ちだと俺も思う。 研究者の論文レベルのものも面白いだろうけど、上から下までHaskellベースで かかれたWebアプリとかで目立つものが出てほしいよ、個人的には。 574 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 20:53:32 ] >>572 アトムの爆発ってのはPrologスレで言及されてる現象のことでいい？ そもそもPrologのアトムってのが良く分からんので何が問題なのか理解できん Lispのシンボルみたいな物と思っていいのかな それなら相当するものはHaskellにはないよ 575 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 21:35:41 ] >>574 Lispのシンボルみたいな物、ですね。 記号をどう処理しているのですか。 576 名前：デフォルトの名無しさん [2008/08/22(金) 21:53:05 ] >>540 30章ってなんの章だったの？ 577 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 22:12:26 ] >>575 「記号」と言われてもいまいちピンと来ないんだが、何にせよ、 普通の手続き型言語が「記号」を処理するのと大差ない方法で処理してると思う 取り得る種類がコンパイル時に決まっているなら列挙型 そうでないなら整数とか文字列 文字列の比較のコストが問題になるなら自分でシンボルテーブルのようなものを用意する、とか 578 名前：デフォルトの名無しさん mailto:sage [2008/08/22(金) 22:34:03 ] >>576 >>310-314 579 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 09:45:26 ] >>572 Prologでも、 1レコード512バイトをsub_atomで30項目に分解したり、更にsplitの 処理をしたりすると確かにアトムが大量発生するだろうが、 Stringとして読み込んで、終始String処理に徹すれば、アルファベットの 数、つまり高々数万のアトムで済むんじゃないの? Stringすなわちリスト処理になると遅いから嫌なのかな。 580 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 10:00:27 ] 宣言的言語をリアルタイム処理に使いたくない病にかかってる。 資源が十分にあると理屈では分かっていても、終わったら電源切っても大丈夫な処理じゃないと拒否反応がでる。 581 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 10:09:14 ] >>579 処理速度もあるかも知れませんが、アトムだと、 foo([株式会社|R],R). と書けるところが、Stringだと foo(List,R) :- append("株式会社",R,List). と書かなくてはならないということがあります。 appendを高速化する機構が欲しくなりますね。 582 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 10:35:10 ] それって代数的データ型を使ってこんな感じで良いんじゃない？ data Atom = Kabushiki | Dummy deriving (Show, Eq) foo :: [Atom] -> [Atom] foo (Kabushiki : r) = r 583 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 11:43:27 ] Prologでまったり Part3 pc11.2ch.net/test/read.cgi/tech/1193354806/ 584 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 12:43:04 ] >>581 この話おかしいよ。 foo([株式会社|R],R). の方は、 すでに株式会社というアトムが切り出されていて、リストの構成要素になっている。 一方、 foo(List,R) :- append("株式会社",R,List). のListはString。ここは、 foo(["株式会社"|R],R). でなきゃ、フェアじゃない。 585 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 13:58:45 ] >>572 > Prologを事務処理に使うと、住所や氏名情報などで爆発的にアトムが発生し 第五世代コンピュータプロジェクトの成果を是非参照下さい。 586 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/23(土) 14:16:16 ] >>585 よく知らないけどソフトウェア科学会会誌7月号に第五の話題が載っていたよ 587 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 14:21:10 ] 成果って、「prologって役立たずじゃん」という結論を得たこと？ 588 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/23(土) 14:28:53 ] >>587 それは短絡的な人たちの根拠のないうわさ。 第五は基礎研究なので企業の人たちが求めるような成果が出ないのは当たり前のこと。 589 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 14:31:33 ] Prologの話は他でやってくれ んで問題点を整理してまたいらっしゃい 590 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/23(土) 14:33:31 ] 詳しいことは忘れたけど、 述語論理による仕様記述を使った鉄道のプロジェクトが企業側で行われた例があったような。 なんだったっけ？ 591 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 14:45:22 ] Prologはどうでもいいのだが、Haskellで金融(とくに保険業)のアブリを 開発する場合、何か問題になる点はないのか。 592 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 14:54:20 ] >>591 必要なメモリサイズを予測しにくい点とか。full lazyな処理系全般に言えると思うけど。 593 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 14:57:02 ] 金融系システムにHaskellを使うメリット自体が思いうかばん。 いいじゃん、Javaでつくるのが流行ならJavaで作らせれば。 どうせ枯れたシステムなんだから。 594 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 15:00:18 ] >>592 full lazyな処理系って、よくわからない。 595 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/23(土) 15:11:43 ] どんな言語で書いたとしても、必要なメモリの量は実際に動かしてみないとわからないよ。 596 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 15:17:46 ] haskellっていいプロファイラあんの？ 597 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 15:26:42 ] >>595 COBOLなんかは確定してると思うけど。 598 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 15:42:16 ] >>597 してない。 SORTなどに内部的に使う記憶容量が不明。 599 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 15:43:11 ] Haskellのようにデフォルトで遅延評価する言語は、 計算をできるかぎり遅延させようとするから、 下手な書き方するとすぐメモリリークする Haskellのメモリリークは大抵の場合小規模な修正で直るけど、 どこを修正すべきか探すのに慣れとプロファイラが要る >>596 GHC付属のプロファイラは優秀だと思う 600 名前：36 ◆K0BqlCB3.k mailto:sage [2008/08/23(土) 15:47:59 ] >>596 profオプションをつけてコンパイルしたらランタイムシステムにプロファイラが組み込まれるよ。 詳しくはマニュアルで。 601 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 16:19:23 ] >>598 ん？確定はしてなくても最大どれかけかかるかは確定してるでしょ。 グラフ簡約のヒープ消費は予測もつかんぞ。 602 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 16:27:11 ] >>601 確定してるのかしてないのかどっちだｗ 603 名前：初心者修業中 mailto:sage [2008/08/23(土) 16:37:52 ] Haskellでメモリーリークが起きるのですか? ガベージコレクションにバグがない限り、 メモリーリークが起きるとは思えないのですが…。 FFIを使った場合の事でしょうか…。 604 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 17:15:44 ] >>599 の例としては↓の話かな。 d.hatena.ne.jp/desumasu/20060909/1157800884 この場合のメモリーリークは単なるメモリの解放忘れって事ではなくて、 期待した解放タイミングと実際のそれとのギャップの事みたいだね。 605 名前：初心者修業中 mailto:sage [2008/08/23(土) 17:42:49 ] これも「メモリーリーク」と呼ぶのでしょうか？ *Main> foldr (+) 0 [0..1000000] *** Exception: stack overflow 606 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 18:05:58 ] プログラマが意図してないで、リファレンスが残るようなコーディングを しちゃってる、というのをリークに含めることもある。 607 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 18:34:57 ] >>605 それは「マヌケ」と呼びます。 608 名前：初心者修業中 mailto:sage [2008/08/23(土) 18:57:56 ] stack overflowが発生する時、 簡単にわかる場合は「マヌケ」 ちょっとわかりづらい場合は「メモリーリーク」 と呼ぶという認識でよろしいでしょうか？ 609 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 19:14:20 ] リークってのは「漏れ」のこと。 GCのある言語だと、>>606しか起こり得ない。 >>605の「溢れ」とは全然違う。 610 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 19:20:46 ] >>605 それはスタックオーバフロの例外であって、エラーとは違う。 メモリリークしているわけではないよ。 611 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 19:22:12 ] C言語みたいに型があいまいな言語ではメモリリークが起こりうるが、 Haskellみたいに強い静的型付けされている言語にはメモリリークなんてありえないよー 612 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 19:26:56 ] スタックオーバーフローとメモリーリークは 現象として全然違うと言う事ですね。 分かります。 613 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 19:53:14 ] >599や>604が挙げているような例はC言語で 良く言われる「メモリーリーク」とは違う現象だな。 Haskellの場合、遅延評価がデフォーなので うかつに再帰を使うと計算の途中結果が膨大な ものになってヒープ領域が溢れてしまう。 Cの場合はただの確保したメモリの解放し忘れ。 Cでも再帰的なメモリー確保をすれば Haskellみたいな事も起きうるはずだが。 614 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 20:06:48 ] >>611 強い静的型付けとメモリーリークの有無はほとんど関係がありません。 GCの方がずっと関係が深いです。 615 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 20:09:24 ] Pascalのnewとfreeだっけ? あれ考えれば分かるよな。 強い型付けでも簡単にメモリーリークは起きる。 616 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 20:56:45 ] foldl でも stack overflow するんだよね。 Data.List.foldl' 使えばいいんだけど。 617 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 21:35:43 ] なんで foldl でスタック溢れるの？末尾再帰が最適化されてないの？ 618 名前：デフォルトの名無しさん mailto:sage [2008/08/23(土) 21:48:31 ] >>604のリンク先に書いてある 末尾再帰は最適化されるよ 619 名前：初心者修業中 mailto:sage [2008/08/23(土) 23:53:01 ] >>617 遅延評価だからと認識しています。 ↓参考 haskell.g.hatena.ne.jp/jmk/20060710/1152516465 620 名前：617 mailto:sage [2008/08/24(日) 00:40:37 ] >>618-619 なるほど、非常によくわかりました。 （つーか前出のリンク読まずにレスして申し訳ない） うーむ、しかし末尾再帰が最適化されることの旨みは、 ・ローカルスコープの値をスタックに積む必要がなくなることと ・連続するreturnが省略されること の２点だと思うけど、foldl のように結局は遅延評価のための computation がスタックに積まれていて、後から順次簡約するなら 「最適化されている」とは言い難い気もするな・・・。 最適化するための然るべき変形は、一応してあるんだろうけど。 まあ seq 使うとか、回避の仕方がないわけじゃないからいいのかな？ 621 名前：デフォルトの名無しさん mailto:sage [2008/08/24(日) 00:54:46 ] ↓にも関連した話が載ってる。 itpro.nikkeibp.co.jp/article/COLUMN/20070403/267180/?P=2 622 名前：デフォルトの名無しさん mailto:sage [2008/08/24(日) 13:10:00 ] ■■学校を作ろう！■■ VIP発でサイトを作ろうと思うんだ。（詳しくはWikiを見てくれ） パートスレになるんでパー速（GEP)に移動している。 今スタッフを募集しているから、来てくれないか？ ■Wiki www36.atwiki.jp/vipvipschool/ ■募集スタッフ プログラム担当（特にErlang、Perl） デザイナー（サイト上のアイコン、ロゴなど） WEBデザイナー（サイトデザイン案に沿って、htmlやCSSを書ける） 他にも宣伝担当なども募集している。 ■スレ ex14.vip2ch.com/test/read.cgi/news4gep/1219068297/ 623 名前：デフォルトの名無しさん mailto:sage [2008/08/24(日) 16:41:26 ] 「特にErlang」… 実用性でいうとやっぱErlangなのかな… 624 名前：デフォルトの名無しさん mailto:sage [2008/08/24(日) 18:20:21 ] >623 大規模なWebサービスを構築するのに向いていると 考えたから企画者がErlangを採用したんだろうね。 625 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 09:10:25 ] 大規模な、ってのがクセ者で、 実情は単にDBのテーブルが大きいだけだったりするよな。 そもそもウェブアプリでDB以外どこが肥大化するよ？ 626 名前：デフォルトの名無しさん [2008/08/25(月) 09:11:28 ] 画面？ 627 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 09:20:29 ] >>625 複数のwebサービスから情報集めたり、もしくはhttp以外のプロトコルで通信して情報を取得しなきゃいけなかったり、 別プロセスで並列キューに入れて処理しなきゃいけなかったり、システムそのものが大きくなるとこはあると思う。 それともデータサイズの規模に限定した話？ 628 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 09:53:32 ] >>625 とりあえずErlang + YAWSの事例くらいは、 念頭においてくれないと、話にならないのでは? 629 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 09:55:11 ] >>627 > 複数のwebサービスから情報集めたり、 そういうのはAjaxでクライアント側がやるのが流行では？ まあサーバ側がやってもいいですが、HTTPセッションを入れ子にするのは あまり筋がいい設計とは思えません。 > もしくはhttp以外のプロトコルで通信して情報を取得しなきゃいけなかったり、 まあDB接続なんかもそうですよね。 しかし「大規模になる」ような要因とはあまり考えられないのですが。 > 別プロセスで並列キューに入れて処理しなきゃいけなかったり、 fastcgiとかの話でしょうか？特段、だから大規模になるというものではないと思いますが。 > それともデータサイズの規模に限定した話？ コード自体はほとんどCMS系フレームワークをユーザ定義コンテナを定義する程度で 用が済むことが多いと思います。特に、>>622のような、いかにもCMSっぽいシステムでは。 630 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 10:00:08 ] >>629 > コード自体はほとんどCMS系フレームワークをユーザ定義コンテナを定義する程度で > 用が済むことが多いと思います。特に、>>622のような、いかにもCMSっぽいシステムでは。 よいCMS系フレームワークを、 容易に開発できるかどうかって話をしているんだと思いますよ。 631 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 10:54:21 ] >>630 なるほど、わかりました。 格納するコンテンツの量は結局DBのサイズの問題になると思うので、 それ以外の「大規模」の要因というと、 ・同時接続数（パフォーマンス) ・登録ユーザー数 ぐらいでしょうか。 それとも単純にコードサイズを指して「大規模」という話なんでしょうかね。 「学校」というドメインが明確になっているので、 一般のCMSフレームワークほど汎用化は要求されないし、 どのような要因でコードサイズが「大規模」化するのか興味があります。 632 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 12:22:00 ] >>624 Apacheとか使わずErlangでサーバー構築するんじゃないの? 633 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 12:26:39 ] キッチンシンクアプローチか…… 634 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 13:01:50 ] Erlangをわざわざ使うということは、数百レベルの並列プロセスを マルチコアで何とかしようと考えていると見て間違いない。 Webだとすれば、WebServer以外考え難い。生徒数千でほぼ 同時にアクセスがあるとか。 635 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 13:13:15 ] しかし、>>622 はなんでErlangスレに書いてないんだ？w 636 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 13:16:41 ] 単に初期メンバーにErlang使いが居ただけなじゃいの？ 637 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 13:16:52 ] Erlangスレ見たことない方ですねw 638 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 13:42:02 ] Erlangはどうでもいいんだけれど、 HaskellでもPerl使いを確保しておいて、単体の機能は専らCPANから取り出させて、 確保されているインターフェイスを介してHaskellで利用するというやり方は 多くなるんじゃないかな。短時間で開発する一手法としてね。 639 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 13:57:49 ] ならないね。 640 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 14:13:29 ] >>638 落日のPerlを使うかどうか。 規格書の通りに一からすべて開発するのは確かに大変だね。 641 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 00:21:14 ] Text/ParserCombinators/ReadP.hsとKoen Claessen氏のペーパーを読んで思ったんですが、 Haskellに慣れてくるとこの実装が直感的に見えてくるんですか？ Haskellのパーサコンビネータ関連のペーパーを読んでいない状態でReadPを読んで、 data P a = Get (Char -> P a)　　 　　　　　　略 　　　　　　| Result a (P a) 　　　　　　略　　　　　　　　　　　　　　　　　　なのを「え、一番直感的じゃん」 とか、 newtype ReadP a = R (forall b . (a -> P b) -> P b) で instance Monad ReadP where 　　return x　　 = R (\k -> k x)　　　　　　　　　　　　　　　　　　　 ← これとか 　　fail _ 　　 　　= R (\_ -> Fail) 　　R m >>= f 　= R （\k -> m (\a -> let R m' = f a in m' k)）　　← これとか とか get = R Get ってなるを、「ああ、自明だなすげえ直感的」みたいに理解できるようになる物なんですかね。。難しすぎる。。。 642 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 00:29:58 ] >>629 大規模になる要因なんていくらでもあるじゃん。 今時は単にUIがWebで、バックエンドが複雑化してるものも少なくないしね。 分散業務システムで多種類のプロセスを相手にすりゃ自然と規模は大きくなるかと。 何でもかんでもインターネット上でパブリックに利用可能な整理されたサービスばかりじゃないからね。 学校だって企業並みにシステムが複雑化してるとこもあるから、強ち単純とは言えないんじゃないかと。 まあ何はともあれ、ロジックが複雑になればなるほど、関数型の恩恵は大きくなるわな。 643 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 01:08:51 ] といったって、googleも複雑なシステムとか言われてるけど、 googleを支える技術とか読んでもそんなに複雑とは思えないんだよなぁ。 台数は1台だけど自宅で似たようなことやってるもん。 644 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 08:11:38 ] >>641 P のような再帰的な型のモナドを、 効率のために継続モナド(ReadP)で包むのは定石。 Haskell への慣れっていうより、 モナドや継続モナドへの慣れの問題な気がする。 P は問題によって様々だけど、 ReadP のとこは Control.Monad.Cont の 一般的な継続モナドと(型を除いて)同じなので、 それを理解しておくと問題に集中できていいかもよ。 645 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 08:13:32 ] つ チラシの裏 646 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 08:21:08 ] >>642 それはバックエンドで動いている他プロセスが複雑なのであって ウェブアプリが複雑なわけではないのでは？ 647 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 08:32:48 ] >>625 機械翻訳とかではなくて? 648 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 18:38:57 ] >>644 どうもレスありがとうございました。 ＞P のような再帰的な型のモナドを、 ＞効率のために継続モナド(ReadP)で包むのは定石。 これは初めて聞きました。どうもありがとうございます。 確かに If we want to build monads on top of a continuation based programming paradigm, such as stream processors or continuation based I/O in Haskell, we need to build a monad around the continuation based operations. って書いてあるペーパーを見付けました、その継続ベースの方法について考えながら考えていこうと思います。

---

---

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

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