関数型プログラミング言語Haskell Part9
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2008/05/17(土) 16:41:29http://www.haskell.org/
日本語サイト
http://www.sampou.org/cgi-bin/haskell.cgi
http://www.shido.info/hs/
過去ログ
関数型プログラミング言語Haskell
Part1 http://pc.2ch.net/tech/kako/996/996131288.html
Part2 http://pc2.2ch.net/test/read.cgi/tech/1013846140/
Part3 http://pc8.2ch.net/test/read.cgi/tech/1076418993/
Part4 http://pc8.2ch.net/test/read.cgi/tech/1140717775/
Part5 http://pc8.2ch.net/test/read.cgi/tech/1149263630/
Part6 http://pc11.2ch.net/test/read.cgi/tech/1162902266/
Part7 http://pc11.2ch.net/test/read.cgi/tech/1174211797/
Part8 http://pc11.2ch.net/test/read.cgi/tech/1193743693/
・2chの仕様により、行頭の半角スペースは表示されません。
コードをインデントしたいときは、代わりに または全角スペースを使うことができます。
0367デフォルトの名無しさん
2008/08/07(木) 20:41:53にある最終章、「A concurrent RESTful web application」が読みたいんだけど、
これは本買わないとダメってこと？
0368デフォルトの名無しさん
2008/08/07(木) 21:15:32そうか、本になるのか…買おうかな＞RealWorldHaskell
0369デフォルトの名無しさん
2008/08/07(木) 23:21:20なんでみんな買うの？
こんなにHaskellって腐ってます
ゴミですって随所に書かれているのにw
0370デフォルトの名無しさん
2008/08/07(木) 23:24:06脳内カウンターが回りまくりですかな
0371デフォルトの名無しさん
2008/08/08(金) 00:09:000372デフォルトの名無しさん
2008/08/08(金) 00:12:48そう書き込んだ人間が一名いるようです。
また、買おうかなと書き込むことと買うことは別です。
プログラマたる者、このくらいの論理性は持って欲しいです。
部分と全体を混同するなんて、継承に毒されすぎです。
0373デフォルトの名無しさん
2008/08/08(金) 02:02:00論理じゃなくて、揚げ足取りっていいませんか？
買おうかなと書き込んだということは、買う意思が比較的強いということでしょう。
0か1かじゃないんですよ。
物事は確率的なのです。
0374デフォルトの名無しさん
2008/08/08(金) 02:42:06> 買おうかなと書き込んだということは、買う意思が比較的強いということでしょう。
著作権者や出版社勤務者が宣伝のために書いたかも知れませんよ
0375デフォルトの名無しさん
2008/08/08(金) 02:42:51そういう可能性もある。
確率の問題。
0376デフォルトの名無しさん
2008/08/08(金) 02:50:39ソース
>>370
君が一人しか見てないだけ
0377デフォルトの名無しさん
2008/08/08(金) 03:20:20>Throughout this book, we're going to show you how Haskell's
alternatives to the features of traditional languages are more
powerful, more flexible, and safer. Haskell is positively crammed
full of cutting edge ideas about how to create great software.
(chap1 power)
と最初のところでかいてるけど、なぜ批判本と?
どこをさしていってるの？
0378デフォルトの名無しさん
2008/08/08(金) 03:22:29オレイリーから関数型言語ぼんが出るのは初めてじゃ内科?
国内ではgauche本があるがね。
0379デフォルトの名無しさん
2008/08/08(金) 03:42:030380デフォルトの名無しさん
2008/08/08(金) 11:58:000381デフォルトの名無しさん
2008/08/08(金) 14:34:11ttp://www.amazon.fr/dp/2841771210/
フランスでは流行ってるんだな
0382デフォルトの名無しさん
2008/08/08(金) 14:42:460383デフォルトの名無しさん
2008/08/08(金) 16:16:02いつの本の話してんだか。
この本の和訳プロジェクトはつぶれたね。
0384デフォルトの名無しさん
2008/08/08(金) 19:15:39全然違う。Rubyは世界的にPythonを急追している。
0385デフォルトの名無しさん
2008/08/08(金) 23:55:14俺も1.9がちゃんとしたモノになるまではrubyは使うべきではないと思う。
0386デフォルトの名無しさん
2008/08/08(金) 23:59:16そもそも本当に10月に発売できるか分からんぞ。
0387デフォルトの名無しさん
2008/08/09(土) 00:21:55年内出れば御の字
0388デフォルトの名無しさん
2008/08/09(土) 00:33:37それがほんとかなぁ。とおもってgoogle trendsでruby,python,perlの検索数を比較させて
みたけど、国によって微妙に違うね。
usaなら、2006ねんごろからperlが凋落しきって、python,rubyとならんで、2006中頃から、
rubyが一歩抜けて、perl,pythonが同等になっていた。
italyは、同じような時期にperlが落ちてきてるけど、pythonがかなり強くって、perlとruby
が同等
japanが、perlの凋落が進んできてるけど、usaやitalyほどではなくて、一番ですね。2番め
がrubyで徐々に増えてる。pythonは完全に横ばい。
chinaはpythonの伸びがかなり強い。そんなにrubyは使われてない。
indiaは日本と傾向が似てるな。
israelはrubyは絶滅ぎみ。
google全体ではrubyが一番強くなってきてるけど、これはusaでのruby人気が支えてる
ような感じだな。europaとchinaではpythonが強く、それ以外の国ではperlが強いかな。
0389デフォルトの名無しさん
2008/08/09(土) 04:23:59世界的にみても、わかって言語を選んでいる人よりも
バズワード追ってるだけの人のほうが多いからね。
0390デフォルトの名無しさん
2008/08/09(土) 06:09:31基本コンパイラだし、インタプリタも軽量とは言い堅いし。。。
0391デフォルトの名無しさん
2008/08/09(土) 06:13:310392デフォルトの名無しさん
2008/08/09(土) 08:06:03GHCばかり取り上げられてHugs涙目
0393デフォルトの名無しさん
2008/08/09(土) 08:07:11そんなあなたをはぐはぐ。w あーっ！ではないよ。
0394デフォルトの名無しさん
2008/08/09(土) 08:22:00理由って何かあるんでしょうか。純粋であることや遅延評価が、静的
型やコンパイル時の最適化を要請するということなんでしょうか？
0395デフォルトの名無しさん
2008/08/09(土) 08:27:55「やっぱりGHCだね」
0396デフォルトの名無しさん
2008/08/09(土) 09:06:49静的なのは、最適化も大きいだろうけど、
むしろ安全性を狙ってるという要素が大きいんだろう。
遅延評価なのはコンパイル時の最適化にプラスなのかなぁ？
これは理論的に停止できる関数は必ず停止できるっていう、
これまたある種の安全性？が主な目的だと思うけど
( if true (answer foo) (nonStop baa) ) みたいな文を考えよう（Haskellの文法忘れたから適当）。
0397デフォルトの名無しさん
2008/08/09(土) 10:14:15効率はどうなんだろう、"動的型付け-正格"の言語よりさらに遅いことは想像が付くが
0398デフォルトの名無しさん
2008/08/09(土) 10:28:23Goferがそうだったから。
で、なんでGoferがそうだったのかというと、Mirandaがそうだったから。
0399デフォルトの名無しさん
2008/08/09(土) 10:37:45遅延評価は最適化にマイナスだよ。少なくともメモリ空間の最適化には全く向かない。
0400デフォルトの名無しさん
2008/08/09(土) 10:44:26今日はやらない
0401396
2008/08/09(土) 10:50:37そうだよね。
コンパイル技術がすげー発達して高速になれば、話は変わるだろうけど。
（まぁ、コンパイル技術が「すげー発達」すれば、どのコンパイル言語でもマシン語と同じスピードが出るんだから、意味ない話）
あと「理論的に停止できる関数は必ず停止できる」は意味不明だとか、
文じゃなくて式だとか、気づいたけど後の祭り、いわゆるアポステオリorz
0402デフォルトの名無しさん
2008/08/09(土) 11:02:51Guarded Horn Clauses
0403デフォルトの名無しさん
2008/08/09(土) 11:31:02評価方式としては、式、文の逐次的解釈が当然になる。
関数型言語は、ラムダ式から出て来たから、
その評価形式をどうするかというのが一つのポイントになる。
遅延評価は最左最外簡約の研究から出て来た。
効率がどうのこうのというより、
新しいプログラミングパラダイムを産み出したので、
(例えば無限リスト、無限木の積極的利用)
研究され続けているんだと思う。
0404デフォルトの名無しさん
2008/08/09(土) 11:32:55GLOBAL HONORED CROWN http://www.noah.co.jp/ghc.php
0405デフォルトの名無しさん
2008/08/09(土) 11:37:31何ができるってわけでもないし
HaskellでWindowsは作れないしLinuxも作れない
Webサーバも作れないしDBも作れない
意味がない
040636 ◆K0BqlCB3.k
2008/08/09(土) 11:44:54http://www.thenewsh.com/~hws/
040736 ◆K0BqlCB3.k
2008/08/09(土) 11:45:520408デフォルトの名無しさん
2008/08/09(土) 11:47:37代入だらけのプログラムをSSAとかいう形式に変換するとか。
0409デフォルトの名無しさん
2008/08/09(土) 11:48:09純粋関数型言語・遅延評価で、
型なし・インタプリタ言語ってあるよ。
変態言語 Lazy K がそれ。
ある意味では Make とかもそうかも。
少なくとも、
純粋関数型言語・遅延評価と、
コンパイル言語かインタプリタ言語か
っていうのはあまり関係ない。
純粋関数型言語・遅延評価は、
シンプルな手続き型よりもインタプリタを書くのが難しい、
っていうのはあるかもしれないけど。
純粋関数型言語であることと静的型であることは、少し関係があるかも。
純粋関数型言語でかつ動的型というのは、概念的にあまり良い食い合わせではないとは思う。
動的型っていうのは、関数の世界では「型無し」ってことになると思うんだけど、
いずれにせよアドホックなエラー処理が必要になって、
純粋関数型的にアドホックなエラー処理というのは少なくとも美しくない。
0410デフォルトの名無しさん
2008/08/09(土) 12:17:29遅延評価でインタプリタ。破壊的関数が作れないというものなら、R言語くらいしか知らない。
0411394
2008/08/09(土) 12:56:14論理的に組み合わせ悪いというよりは、静的型のメリットを選んだ
ということなんでしょうか。
静的型VS動的型というのは、安全VS自由ということだと思うんですが、
Haskellは安全を選んだということなのかな。純粋関数型としては、
副作用に関連する不具合から自由なのが売りだと思うので、更に
静的型によって徹底的に信頼性を上げてるという感じなんでしょうか。
>>409
純粋関数型であること(参照透明であること)と動的型が食い合わせ
悪いというのがちょっと分かりませんでした。動的型は実行時不具合
の問題が付きものと思うのですが、参照透明との関係をよろしければ
少し詳しく教えていただけマスでしょうか。
0412デフォルトの名無しさん
2008/08/09(土) 13:08:180413デフォルトの名無しさん
2008/08/09(土) 13:13:08動的型を使うと、アドホックなエラー処理が必要になるよね？
っていうか、それがないと動的型を使ううまみがないと思うんだけど。
ここでいうアドホックなエラー処理っていうのは、
対象オブジェクトの型をプログラムで認識して、
意図しないオブジェクトが来たときにエラー処理するってことだけど。
このエラー処理にIOを使わないなら、
それは多相型やクラスを使っても同じ結果が得られるよね。
だから、Haskellに動的型を組み込む必要性は、
意図しないオブジェクトが来たときIOを使ったエラー処理をしたいときに限られると思う。
で、純粋関数型言語は参照透明性ゆえにIO処理するの苦手。
まぁ、動的型っていうのはプログラム中で型を認識できないと意味ないよね？
っていう時点で、カリー・ハワード対応との関係で微妙っていう気にするけど。
僕が考えているのは、そんな感じ。
0414デフォルトの名無しさん
2008/08/09(土) 13:17:44Haskellに多いやつらの典型だなｗ
0415デフォルトの名無しさん
2008/08/09(土) 13:18:59動的でマルチパラダイムな言語で書いたのと同じになる。
0417デフォルトの名無しさん
2008/08/09(土) 13:50:48せいぜい生きる力を養ってください
0418デフォルトの名無しさん
2008/08/09(土) 13:54:52implementationの本を読むといいよ
Peyton Jonesのがpdfで読めるはず
0419デフォルトの名無しさん
2008/08/09(土) 14:11:34俺はPJのが好きだな。
静的型付けとグラフ簡約が運命的な出会いであることがわかった。
0420デフォルトの名無しさん
2008/08/09(土) 14:19:55なんか議論が無茶苦茶じゃないか？
例えば「型エラー」を「0除算エラー」に置き換えても論理展開が変わらん
>このエラー処理にIOを使わないなら、
>それは多相型やクラスを使っても同じ結果が得られるよね。
動的型の重要な利点は、型をいちいち書かなくてもいいという利便性だよな
多相型やクラスを使って動的型をシミュレートするのはすごく面倒だから、この利点を享受できない
それから、GHCではerrorやundefinedで発生したエラーをIOモナド上で捕捉できる。念のため
0421デフォルトの名無しさん
2008/08/09(土) 14:26:59あと、動的型のメリットを例外処理だけに限定するのは視野が狭すぎる。
LISPのメリットはアドホックな例外処理か？そうじゃないと思う。
0422デフォルトの名無しさん
2008/08/09(土) 14:39:32納得できないのなら、それで良いです。
僕も、べつにそんなに優れた論拠だと思ってないから。
0423デフォルトの名無しさん
2008/08/09(土) 14:55:35>>416が理解したのが驚愕。
0424デフォルトの名無しさん
2008/08/09(土) 15:20:10すげえ
0425394
2008/08/09(土) 15:22:47それだけであれば、コンパイルで発見する不具合をテスト時に見つけよう
とする、つまり面倒なことを後回しにしてるだけ、ってことになりませんか？
0426デフォルトの名無しさん
2008/08/09(土) 15:23:150427デフォルトの名無しさん
2008/08/09(土) 15:30:45S式なんて最たるもので、静的な型付けは不能あるいはワイルドカード的。
静的か動的かはトレードオフの問題。
0428デフォルトの名無しさん
2008/08/09(土) 15:42:04不具合を見つけるタイミングが遅くなるという対価を払って、記述の利便性および変更の容易さという報酬を得る
ちゃんと取引として成立してるじゃないか
もちろん「型を書かなくて済む」こと以外にも利点はある
特定の静的型付け言語ではそもそも型を付けられないようなコードが許容されるとか
0429デフォルトの名無しさん
2008/08/09(土) 17:38:51lispを使ってる限りの印象だが
都合のよい所だけ型宣言が出来るというのは柔軟性につながるかな。
プログラムの最適の仕方も静的/動的で違いがあると思うよ。
型なんで考えずにアルゴリズムだけ作っちゃえができるからね。
それでも型を意識したプログラミングをすることはあるが。
でも、haskellでもポリモつかえばある程度型無視ラピッドプログラミング
は可能じゃないか?
0430デフォルトの名無しさん
2008/08/09(土) 17:41:420431デフォルトの名無しさん
2008/08/09(土) 17:44:14haskellって参照透明性ってかなりのメリットだと思ってるけど。
0432デフォルトの名無しさん
2008/08/09(土) 17:49:41Hashkellはメリットを殺すデメリットしかないだろ
0433デフォルトの名無しさん
2008/08/09(土) 17:56:37http://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types
0434デフォルトの名無しさん
2008/08/09(土) 17:57:26OCamlはstrictだから。残念。
0435394
2008/08/09(土) 19:55:26コンパイル時に問題が抽出されることと、テストによって抽出されるのでは
質的な違いがあるんじゃないですか？テストは結局は人間がやるものだし、
不具合の可能性を低めるということにしかならないけど、コンパイルでの
不具合検査は対象となるプログラムの論理的正しさを証明していることに
なるかと思います。
容易に変更ができたとして、不具合がどこに潜んでいるのか分かりにくい
というのは非常に問題あると思いますよ。コンパイルで分かるのならば、
これは明白でしかも機械的に全てが晒されますから安心です。
0436デフォルトの名無しさん
2008/08/09(土) 20:20:59そんざいしないしな
0437デフォルトの名無しさん
2008/08/09(土) 20:23:09確かに、バグがどの段階で発見されるかには質的な違いがある
でも、静的な型検査だって全てのバグを検出できる訳じゃないから、
結局、動的検査との安全性の違いは程度問題
その上で、静的な型検査の利点がコストを上回るという判断は当然ありえるし、
そう判断したなら静的型言語を使えばいい
0438デフォルトの名無しさん
2008/08/09(土) 20:28:12静的型チェック馬鹿ですやん
0439394
2008/08/09(土) 20:39:50例えば、参照透明ということについてはどうでしょうか？こちらも、副作用を許容
すれば、プログラム中に登場する変数の中身が何に変異しているかどうかが
分からなくなり、実行してみないと問題が検出できない、ということになります。
参照透明を強要するのも、型を強要するのも、結局その辺がクリアできない
プログラマというのはそれらに関連する不具合を出してしまうんだと思いますが
どうでしょうか。気をつければいい、というのは簡単で規模が小さなシステムでは
言えることで、そうでなければ膨大なテスト工程が必要になってしまうのでは？
0440デフォルトの名無しさん
2008/08/09(土) 20:46:48refとかで破壊的な変数が作れるから嫌とかそういうレベルの話じゃないよね。
それだったらref使わなければいいだけだから。
逆に、Haskellの参照透明で良い所ってどのへんなの？
OCamlのでも、ErlangのでもなくHaskellの参照透明性が良い理由を説明してほしいんだが。
0441394
2008/08/09(土) 21:04:32参照透明でない、ということは値が望んだ通りの値であることを
保証するためにどこまでも神経質にテストをしなければならない、
ってことですよね。
一人で開発するのであればいいですが、多くの人の手によって
間違いがあってはならないシステムの開発をする際、「それは
禁じ手だから止めてね」と口約束するだけってのは非常に怖い
わけです。だからこそ、テストの工程が膨れ上がる。
Haskellに自分が惹かれている大きな理由の一つは、この辺の
頑固さを貫いていることですね。
0442デフォルトの名無しさん
2008/08/09(土) 21:19:02それだけでテストが必要なくなるわけでも、
テストが簡単になるわけでもない。
そうなるのはトイプログラムだけ。
嘘だと思うなら、GHC, Hugsなどのバグトラックをみてみればいい。
0443デフォルトの名無しさん
2008/08/09(土) 21:21:510444437
2008/08/09(土) 21:22:55何が言いたいのか良く分からん
俺は「気をつければいい」なんて一言も言ってないよ
>>428に書いたように、動的か静的かの間でトレードオフが成立すると言っているだけ
>>441
OCamlの変数は変更不可だよ
変更できるのは参照(ref)で、これは変数とは別物
だから、口約束するまでもなく変数の値が変わらないことは保証されてる
0445デフォルトの名無しさん
2008/08/09(土) 21:26:07参照透明性を壊さないと入出力できないのが嫌
044636 ◆K0BqlCB3.k
2008/08/09(土) 21:37:36数学的に無理だから、統計的に証明するわけですよ。
実際に〜〜でした、ってね。
ヒューマンインターフェース系の論文が参考になるんじゃないかな。
あっちは全部そんな感じ。
0447デフォルトの名無しさん
2008/08/09(土) 21:38:56Haskellでもやろうと思えばIORefとかで事実上破壊的な操作が可能になるわけですが、
これについてはどうお考えで？
「HaskellでIORefは使うな」っていうプログラミングルールを設定することは
「OCamlでref使うな」っていうルールを設定することと本質的に違わないと思うんだけど
それについてはどうなんすか。
044836 ◆K0BqlCB3.k
2008/08/09(土) 21:40:14どう見てもアクリル製のガワの中に反射板入れただけやん。
UFOとかエイリアンとか、考古学じゃなくてSFやん。
突っ込みどころ満載な映画でした。
かしこ
0449デフォルトの名無しさん
2008/08/09(土) 22:13:11したいです。どこがいい問題集頂戴
0450デフォルトの名無しさん
2008/08/09(土) 22:23:39do記法を使わずにliftM、liftM2、joinを実装
Continuationモナドを実装
045136 ◆K0BqlCB3.k
2008/08/09(土) 23:30:03また何も考えずにそういうこと言う。
>>449
http://ja.doukaku.org/
045236 ◆K0BqlCB3.k
2008/08/09(土) 23:31:04http://projecteuler.net/
0453デフォルトの名無しさん
2008/08/10(日) 05:05:51モナドとλの練習なら>>450はいい案じゃないか。
いっぱいじゃないけど質的にいい。
0454デフォルトの名無しさん
2008/08/10(日) 05:08:55>>419
PJのって何？本もpdfもPJのでしょ？
0455デフォルトの名無しさん
2008/08/10(日) 08:02:29Implementation of Functional Programming
Implementing Functional Languages,(D. Lesterと共著)
を書いていて両方公開。
http://www.haskell.org/haskellwiki/Books
0456デフォルトの名無しさん
2008/08/10(日) 08:05:37http://www.haskell.org/haskellwiki/Tutorials
0457デフォルトの名無しさん
2008/08/10(日) 13:23:16すまん、>>455のImplementing...のほうを言いたかった。
045836 ◆K0BqlCB3.k
2008/08/10(日) 13:39:12>>449は本当にモナドとラムダの練習のためだけに問題をほしがっているのかどうかってこと。
それに、初心者は何か目に見えて動かせるものを書きたがるものさ。
誰かに見られることを想定して書くのと、「動けばそれでいい」だけで書くのとでは、
やっぱり前者の方がいろいろ調べたりすることで勉強になる。
0459デフォルトの名無しさん
2008/08/10(日) 15:23:20そこ載ってなくね？ｗ
http://research.microsoft.com/~simonpj/Papers/slpj-book-1987/index.htm
http://research.microsoft.com/~simonpj/Papers/pj-lester-book/
>>457
サンクス。目次しか見てないけど、
Implementationがパターンマッチや型など広く扱ってて、
Implementingはコンパイラのコアな部分を主に扱ってる感じ？
静的型付けとグラフ簡約の運命的な出会いというからそうでもない？
まあImplementingのほうを読んでみます。
>>458
そうですね。
0460デフォルトの名無しさん
2008/08/10(日) 16:23:15グラフ簡約と運命的な出会いというと遅延評価じゃないかね。
特にPJ的には。
0462419
2008/08/11(月) 14:44:370463デフォルトの名無しさん
2008/08/11(月) 16:05:22あまり理解できてなかったんじゃない？w
0464デフォルトの名無しさん
2008/08/11(月) 16:13:31かもしれない。
できれば君が読んでポイントだと思ったところを挙げてくれると皆の参考になると思う。
0465デフォルトの名無しさん
2008/08/11(月) 16:20:35例え動的型チェックをやろうとも、そのコードは、
他の普通のコードと一緒でスーパー・コンビネータになって、
グラフ簡約されるだけだから、コンパイル時に型チェックを済ませることが、
スーパー・コンビネータのグラフ簡約上、特に有利だとは思えません。
0466デフォルトの名無しさん
2008/08/11(月) 17:39:55■ このスレッドは過去ログ倉庫に格納されています