08/08/07 23:21:20
RealWorldHaskellってHaskellの批判本なのに
なんでみんな買うの？
こんなにHaskellって腐ってます
ゴミですって随所に書かれているのにw
370:デフォルトの名無しさん
08/08/07 23:24:06
買おうかなと言ったのが一人いるだけなわけだが
脳内カウンターが回りまくりですかな
371:デフォルトの名無しさん
08/08/08 00:09:00
ん？批判本なんだ？
372:デフォルトの名無しさん
08/08/08 00:12:48
そう思っている人がいるかどうかは定かではないですが、
そう書き込んだ人間が一名いるようです。
また、買おうかなと書き込むことと買うことは別です。
プログラマたる者、このくらいの論理性は持って欲しいです。
部分と全体を混同するなんて、継承に毒されすぎです。
373:デフォルトの名無しさん
08/08/08 02:02:00
>>372
論理じゃなくて、揚げ足取りっていいませんか？
買おうかなと書き込んだということは、買う意思が比較的強いということでしょう。
0か1かじゃないんですよ。
物事は確率的なのです。
374:デフォルトの名無しさん
08/08/08 02:42:06
>>373
> 買おうかなと書き込んだということは、買う意思が比較的強いということでしょう。
著作権者や出版社勤務者が宣伝のために書いたかも知れませんよ
375:デフォルトの名無しさん
08/08/08 02:42:51
>>374
そういう可能性もある。
確率の問題。
376:デフォルトの名無しさん
08/08/08 02:50:39
>>369
ソース
>>370
君が一人しか見てないだけ
377:デフォルトの名無しさん
08/08/08 03:20:20
>369
>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)
と最初のところでかいてるけど、なぜ批判本と?
どこをさしていってるの？
378:デフォルトの名無しさん
08/08/08 03:22:29
なんとなくpractical common lispのhaskell版と言う印象なんだけどな。
オレイリーから関数型言語ぼんが出るのは初めてじゃ内科?
国内ではgauche本があるがね。
379:デフォルトの名無しさん
08/08/08 03:42:03
フランスではocamlの本が出てた
380:デフォルトの名無しさん
08/08/08 11:58:00
washって継続ベースなの？
381:デフォルトの名無しさん
08/08/08 14:34:11
>>379マジだ
URLﾘﾝｸ(www.amazon.fr)
フランスでは流行ってるんだな
382:デフォルトの名無しさん
08/08/08 14:42:46
感覚的には日本のRubyと同じ感じじゃないすかね。
383:デフォルトの名無しさん
08/08/08 16:16:02
>>381
いつの本の話してんだか。
この本の和訳プロジェクトはつぶれたね。
384:デフォルトの名無しさん
08/08/08 19:15:39
>>382
全然違う。Rubyは世界的にPythonを急追している。
385:デフォルトの名無しさん
08/08/08 23:55:14
急追して、、いたけど結局ダメだった、というのが現在のところだよ
俺も1.9がちゃんとしたモノになるまではrubyは使うべきではないと思う。
386:デフォルトの名無しさん
08/08/08 23:59:16
そうか？
そもそも本当に10月に発売できるか分からんぞ。
387:デフォルトの名無しさん
08/08/09 00:21:55
コレすでに3回発売日伸びてる
年内出れば御の字
388:デフォルトの名無しさん
08/08/09 00:33:37
>>385
それがほんとかなぁ。とおもって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が強いかな。
389:デフォルトの名無しさん
08/08/09 04:23:59
>>384
世界的にみても、わかって言語を選んでいる人よりも
バズワード追ってるだけの人のほうが多いからね。
390:デフォルトの名無しさん
08/08/09 06:09:31
Haskellって本当にLLって言っていいのかな。
基本コンパイラだし、インタプリタも軽量とは言い堅いし。。。
391:デフォルトの名無しさん
08/08/09 06:13:31
LLじゃないだろw
392:デフォルトの名無しさん
08/08/09 08:06:03
> 基本コンパイラだし
GHCばかり取り上げられてHugs涙目
393:デフォルトの名無しさん
08/08/09 08:07:11
>>392
そんなあなたをはぐはぐ。w あーっ！ではないよ。
394:デフォルトの名無しさん
08/08/09 08:22:00
初心者なんですが、Haskellが型については静的であることを選択した
理由って何かあるんでしょうか。純粋であることや遅延評価が、静的
型やコンパイル時の最適化を要請するということなんでしょうか？
395:デフォルトの名無しさん
08/08/09 08:27:55
GHCはHaskell解釈系ランキング第一位！
「やっぱりGHCだね」
396:デフォルトの名無しさん
08/08/09 09:06:49
>>394
静的なのは、最適化も大きいだろうけど、
むしろ安全性を狙ってるという要素が大きいんだろう。
遅延評価なのはコンパイル時の最適化にプラスなのかなぁ？
これは理論的に停止できる関数は必ず停止できるっていう、
これまたある種の安全性？が主な目的だと思うけど
( if true (answer foo) (nonStop baa) ) みたいな文を考えよう（Haskellの文法忘れたから適当）。
397:デフォルトの名無しさん
08/08/09 10:14:15
別に"動的型付け-純粋-非正格-インタプリタ型"の関数型言語もあり得るよな
効率はどうなんだろう、"動的型付け-正格"の言語よりさらに遅いことは想像が付くが
398:デフォルトの名無しさん
08/08/09 10:28:23
>>394
Goferがそうだったから。
で、なんでGoferがそうだったのかというと、Mirandaがそうだったから。
399:デフォルトの名無しさん
08/08/09 10:37:45
>>396
遅延評価は最適化にマイナスだよ。少なくともメモリ空間の最適化には全く向かない。
400:デフォルトの名無しさん
08/08/09 10:44:26
遅延評価なんて
今日はやらない
401:396
08/08/09 10:50:37
>>399
そうだよね。
コンパイル技術がすげー発達して高速になれば、話は変わるだろうけど。
（まぁ、コンパイル技術が「すげー発達」すれば、どのコンパイル言語でもマシン語と同じスピードが出るんだから、意味ない話）
あと「理論的に停止できる関数は必ず停止できる」は意味不明だとか、
文じゃなくて式だとか、気づいたけど後の祭り、いわゆるアポステオリorz
402:デフォルトの名無しさん
08/08/09 11:02:51
>>395
Guarded Horn Clauses
403:デフォルトの名無しさん
08/08/09 11:31:02
手続き型言語は、ノイマン型計算機を抽象化することで生まれてきたので、
評価方式としては、式、文の逐次的解釈が当然になる。
関数型言語は、ラムダ式から出て来たから、
その評価形式をどうするかというのが一つのポイントになる。
遅延評価は最左最外簡約の研究から出て来た。
効率がどうのこうのというより、
新しいプログラミングパラダイムを産み出したので、
(例えば無限リスト、無限木の積極的利用)
研究され続けているんだと思う。
404:デフォルトの名無しさん
08/08/09 11:32:55
>>402
GLOBAL HONORED CROWN URLﾘﾝｸ(www.noah.co.jp)
405:デフォルトの名無しさん
08/08/09 11:37:31
関数型とか意味がない言語だと思うけどねぇ
何ができるってわけでもないし
HaskellでWindowsは作れないしLinuxも作れない
Webサーバも作れないしDBも作れない
意味がない
406:36 ◆K0BqlCB3.k
08/08/09 11:44:54
>>405
URLﾘﾝｸ(www.thenewsh.com)
407:36 ◆K0BqlCB3.k
08/08/09 11:45:52
ごめん、今からインディージョーンズ見に行くから急いでるから！
408:デフォルトの名無しさん
08/08/09 11:47:37
まあ普通はモデルを現実に合わせるよな。
代入だらけのプログラムをSSAとかいう形式に変換するとか。
409:デフォルトの名無しさん
08/08/09 11:48:09
>>394
純粋関数型言語・遅延評価で、
型なし・インタプリタ言語ってあるよ。
変態言語 Lazy K がそれ。
ある意味では Make とかもそうかも。
少なくとも、
純粋関数型言語・遅延評価と、
コンパイル言語かインタプリタ言語か
っていうのはあまり関係ない。
純粋関数型言語・遅延評価は、
シンプルな手続き型よりもインタプリタを書くのが難しい、
っていうのはあるかもしれないけど。
純粋関数型言語であることと静的型であることは、少し関係があるかも。
純粋関数型言語でかつ動的型というのは、概念的にあまり良い食い合わせではないとは思う。
動的型っていうのは、関数の世界では「型無し」ってことになると思うんだけど、
いずれにせよアドホックなエラー処理が必要になって、
純粋関数型的にアドホックなエラー処理というのは少なくとも美しくない。
410:デフォルトの名無しさん
08/08/09 12:17:29
>>409
遅延評価でインタプリタ。破壊的関数が作れないというものなら、R言語くらいしか知らない。
411:394
08/08/09 12:56:14
皆さんレスありがとうございます。
論理的に組み合わせ悪いというよりは、静的型のメリットを選んだ
ということなんでしょうか。
静的型VS動的型というのは、安全VS自由ということだと思うんですが、
Haskellは安全を選んだということなのかな。純粋関数型としては、
副作用に関連する不具合から自由なのが売りだと思うので、更に
静的型によって徹底的に信頼性を上げてるという感じなんでしょうか。
>>409
純粋関数型であること(参照透明であること)と動的型が食い合わせ
悪いというのがちょっと分かりませんでした。動的型は実行時不具合
の問題が付きものと思うのですが、参照透明との関係をよろしければ
少し詳しく教えていただけマスでしょうか。
412:デフォルトの名無しさん
08/08/09 13:08:18
そもそも関数型言語に意味が無い
413:デフォルトの名無しさん
08/08/09 13:13:08
>>411
動的型を使うと、アドホックなエラー処理が必要になるよね？
っていうか、それがないと動的型を使ううまみがないと思うんだけど。
ここでいうアドホックなエラー処理っていうのは、
対象オブジェクトの型をプログラムで認識して、
意図しないオブジェクトが来たときにエラー処理するってことだけど。
このエラー処理にIOを使わないなら、
それは多相型やクラスを使っても同じ結果が得られるよね。
だから、Haskellに動的型を組み込む必要性は、
意図しないオブジェクトが来たときIOを使ったエラー処理をしたいときに限られると思う。
で、純粋関数型言語は参照透明性ゆえにIO処理するの苦手。
まぁ、動的型っていうのはプログラム中で型を認識できないと意味ないよね？
っていう時点で、カリー・ハワード対応との関係で微妙っていう気にするけど。
僕が考えているのは、そんな感じ。
414:デフォルトの名無しさん
08/08/09 13:17:44
上っ面を語り合って自己満足か
Haskellに多いやつらの典型だなｗ
415:デフォルトの名無しさん
08/08/09 13:18:59
グリーンスパンの第10法則が発動すると、どんな言語で書こうと
動的でマルチパラダイムな言語で書いたのと同じになる。
416:394
08/08/09 13:33:07
>>413
なるほど、理解しました。ありがとうございます。
417:デフォルトの名無しさん
08/08/09 13:50:48
>>405
せいぜい生きる力を養ってください
418:デフォルトの名無しさん
08/08/09 13:54:52
>>416
implementationの本を読むといいよ
Peyton Jonesのがpdfで読めるはず
419:デフォルトの名無しさん
08/08/09 14:11:34
>>418
俺はPJのが好きだな。
静的型付けとグラフ簡約が運命的な出会いであることがわかった。
420:デフォルトの名無しさん
08/08/09 14:19:55
>>413
なんか議論が無茶苦茶じゃないか？
例えば「型エラー」を「0除算エラー」に置き換えても論理展開が変わらん
>このエラー処理にIOを使わないなら、
>それは多相型やクラスを使っても同じ結果が得られるよね。
動的型の重要な利点は、型をいちいち書かなくてもいいという利便性だよな
多相型やクラスを使って動的型をシミュレートするのはすごく面倒だから、この利点を享受できない
それから、GHCではerrorやundefinedで発生したエラーをIOモナド上で捕捉できる。念のため
421:デフォルトの名無しさん
08/08/09 14:26:59
だな。Haskellの例外処理で不足があることはそうそうないと思う。
あと、動的型のメリットを例外処理だけに限定するのは視野が狭すぎる。
LISPのメリットはアドホックな例外処理か？そうじゃないと思う。
422:デフォルトの名無しさん
08/08/09 14:39:32
>>420-421
納得できないのなら、それで良いです。
僕も、べつにそんなに優れた論拠だと思ってないから。
423:デフォルトの名無しさん
08/08/09 14:55:35
俺も>>413はひどい文章で内容もないと思う。
>>416が理解したのが驚愕。
424:デフォルトの名無しさん
08/08/09 15:20:10
本当だ、マジで何言ってるのかわからん
すげえ
425:394
08/08/09 15:22:47
動的型のメリットは型を単に書かなくて済むことだとは思えないんですが。
それだけであれば、コンパイルで発見する不具合をテスト時に見つけよう
とする、つまり面倒なことを後回しにしてるだけ、ってことになりませんか？
426:デフォルトの名無しさん
08/08/09 15:23:15
別に動けばいい
427:デフォルトの名無しさん
08/08/09 15:30:45
何でも指せるポインタってのはメチャ便利なんですよ。
S式なんて最たるもので、静的な型付けは不能あるいはワイルドカード的。
静的か動的かはトレードオフの問題。
428:デフォルトの名無しさん
08/08/09 15:42:04
>>425
不具合を見つけるタイミングが遅くなるという対価を払って、記述の利便性および変更の容易さという報酬を得る
ちゃんと取引として成立してるじゃないか
もちろん「型を書かなくて済む」こと以外にも利点はある
特定の静的型付け言語ではそもそも型を付けられないようなコードが許容されるとか
429:デフォルトの名無しさん
08/08/09 17:38:51
>>425
lispを使ってる限りの印象だが
都合のよい所だけ型宣言が出来るというのは柔軟性につながるかな。
プログラムの最適の仕方も静的/動的で違いがあると思うよ。
型なんで考えずにアルゴリズムだけ作っちゃえができるからね。
それでも型を意識したプログラミングをすることはあるが。
でも、haskellでもポリモつかえばある程度型無視ラピッドプログラミング
は可能じゃないか?
430:デフォルトの名無しさん
08/08/09 17:41:42
じゃあOCamlでいいじゃん
431:デフォルトの名無しさん
08/08/09 17:44:14
>>430
haskellって参照透明性ってかなりのメリットだと思ってるけど。
432:デフォルトの名無しさん
08/08/09 17:49:41
注意してかけばいいだけの話
Hashkellはメリットを殺すデメリットしかないだろ
433:デフォルトの名無しさん
08/08/09 17:56:37
正直、exists型が標準になれば動的型付けは不要じゃね？
URLﾘﾝｸ(en.wikibooks.org)
434:デフォルトの名無しさん
08/08/09 17:57:26
>>430
OCamlはstrictだから。残念。
435:394
08/08/09 19:55:26
>>428
コンパイル時に問題が抽出されることと、テストによって抽出されるのでは
質的な違いがあるんじゃないですか？テストは結局は人間がやるものだし、
不具合の可能性を低めるということにしかならないけど、コンパイルでの
不具合検査は対象となるプログラムの論理的正しさを証明していることに
なるかと思います。
容易に変更ができたとして、不具合がどこに潜んでいるのか分かりにくい
というのは非常に問題あると思いますよ。コンパイルで分かるのならば、
これは明白でしかも機械的に全てが晒されますから安心です。
436:デフォルトの名無しさん
08/08/09 20:20:59
Rubyは危険だしセキュリティリスクしか
そんざいしないしな
437:デフォルトの名無しさん
08/08/09 20:23:09
>>435
確かに、バグがどの段階で発見されるかには質的な違いがある
でも、静的な型検査だって全てのバグを検出できる訳じゃないから、
結局、動的検査との安全性の違いは程度問題
その上で、静的な型検査の利点がコストを上回るという判断は当然ありえるし、
そう判断したなら静的型言語を使えばいい
438:デフォルトの名無しさん
08/08/09 20:28:12
>>435
静的型チェック馬鹿ですやん
439:394
08/08/09 20:39:50
>>437
例えば、参照透明ということについてはどうでしょうか？こちらも、副作用を許容
すれば、プログラム中に登場する変数の中身が何に変異しているかどうかが
分からなくなり、実行してみないと問題が検出できない、ということになります。
参照透明を強要するのも、型を強要するのも、結局その辺がクリアできない
プログラマというのはそれらに関連する不具合を出してしまうんだと思いますが
どうでしょうか。気をつければいい、というのは簡単で規模が小さなシステムでは
言えることで、そうでなければ膨大なテスト工程が必要になってしまうのでは？
440:デフォルトの名無しさん
08/08/09 20:46:48
OCamlが参照透明じゃないから嫌ってどういう事を言ってるの？
refとかで破壊的な変数が作れるから嫌とかそういうレベルの話じゃないよね。
それだったらref使わなければいいだけだから。
逆に、Haskellの参照透明で良い所ってどのへんなの？
OCamlのでも、ErlangのでもなくHaskellの参照透明性が良い理由を説明してほしいんだが。
441:394
08/08/09 21:04:32
>>440
参照透明でない、ということは値が望んだ通りの値であることを
保証するためにどこまでも神経質にテストをしなければならない、
ってことですよね。
一人で開発するのであればいいですが、多くの人の手によって
間違いがあってはならないシステムの開発をする際、「それは
禁じ手だから止めてね」と口約束するだけってのは非常に怖い
わけです。だからこそ、テストの工程が膨れ上がる。
Haskellに自分が惹かれている大きな理由の一つは、この辺の
頑固さを貫いていることですね。
442:デフォルトの名無しさん
08/08/09 21:19:02
参照の透明性があれば、
それだけでテストが必要なくなるわけでも、
テストが簡単になるわけでもない。
そうなるのはトイプログラムだけ。
嘘だと思うなら、GHC, Hugsなどのバグトラックをみてみればいい。
443:デフォルトの名無しさん
08/08/09 21:21:51
テストが減ることを数学的に証明してみせれ。
444:437
08/08/09 21:22:55
>>439
何が言いたいのか良く分からん
俺は「気をつければいい」なんて一言も言ってないよ
>>428に書いたように、動的か静的かの間でトレードオフが成立すると言っているだけ
>>441
OCamlの変数は変更不可だよ
変更できるのは参照(ref)で、これは変数とは別物
だから、口約束するまでもなく変数の値が変わらないことは保証されてる
445:デフォルトの名無しさん
08/08/09 21:26:07
>>440
参照透明性を壊さないと入出力できないのが嫌
446:36 ◆K0BqlCB3.k
08/08/09 21:37:36
>>443
数学的に無理だから、統計的に証明するわけですよ。
実際に～～でした、ってね。
ヒューマンインターフェース系の論文が参考になるんじゃないかな。
あっちは全部そんな感じ。
447:デフォルトの名無しさん
08/08/09 21:38:56
>>441
Haskellでもやろうと思えばIORefとかで事実上破壊的な操作が可能になるわけですが、
これについてはどうお考えで？
「HaskellでIORefは使うな」っていうプログラミングルールを設定することは
「OCamlでref使うな」っていうルールを設定することと本質的に違わないと思うんだけど
それについてはどうなんすか。
448:36 ◆K0BqlCB3.k
08/08/09 21:40:14
インディージョーンズ、あれは予算が無いからあんなにちゃっちい水晶髑髏なのか？
どう見てもアクリル製のガワの中に反射板入れただけやん。
UFOとかエイリアンとか、考古学じゃなくてSFやん。
突っ込みどころ満載な映画でした。
かしこ
449:デフォルトの名無しさん
08/08/09 22:13:11
monadとラムダの簡単な練習いっぱい
したいです。どこがいい問題集頂戴
450:デフォルトの名無しさん
08/08/09 22:23:39
>>449
do記法を使わずにliftM、liftM2、joinを実装
Continuationモナドを実装
451:36 ◆K0BqlCB3.k
08/08/09 23:30:03
>>450
また何も考えずにそういうこと言う。
>>449
URLﾘﾝｸ(ja.doukaku.org)
452:36 ◆K0BqlCB3.k
08/08/09 23:31:04
英語が読めるなら
URLﾘﾝｸ(projecteuler.net)
453:デフォルトの名無しさん
08/08/10 05:05:51
>>451
モナドとλの練習なら>>450はいい案じゃないか。
いっぱいじゃないけど質的にいい。
454:デフォルトの名無しさん
08/08/10 05:08:55
そんなことが書きたいんじゃなかった。
>>419
PJのって何？本もpdfもPJのでしょ？
455:デフォルトの名無しさん
08/08/10 08:02:29
PJは
Implementation of Functional Programming
Implementing Functional Languages,(D. Lesterと共著)
を書いていて両方公開。
URLﾘﾝｸ(www.haskell.org)
456:デフォルトの名無しさん
08/08/10 08:05:37
>>449
URLﾘﾝｸ(www.haskell.org)
457:デフォルトの名無しさん
08/08/10 13:23:16
>>454
すまん、>>455のImplementing...のほうを言いたかった。
458:36 ◆K0BqlCB3.k
08/08/10 13:39:12
>>453
>>449は本当にモナドとラムダの練習のためだけに問題をほしがっているのかどうかってこと。
それに、初心者は何か目に見えて動かせるものを書きたがるものさ。
誰かに見られることを想定して書くのと、「動けばそれでいい」だけで書くのとでは、
やっぱり前者の方がいろいろ調べたりすることで勉強になる。
459:デフォルトの名無しさん
08/08/10 15:23:20
>>455
そこ載ってなくね？ｗ
URLﾘﾝｸ(research.microsoft.com)
URLﾘﾝｸ(research.microsoft.com)
>>457
サンクス。目次しか見てないけど、
Implementationがパターンマッチや型など広く扱ってて、
Implementingはコンパイラのコアな部分を主に扱ってる感じ？
静的型付けとグラフ簡約の運命的な出会いというからそうでもない？
まあImplementingのほうを読んでみます。
>>458
そうですね。
460:デフォルトの名無しさん
08/08/10 16:23:15
載ってるよー
グラフ簡約と運命的な出会いというと遅延評価じゃないかね。
特にPJ的には。
461:419
08/08/11 14:41:51
>>460
まあグラフ簡約は前提として、それを効率的に実装するには静的型付けがイイんだよ、
と、約20年前に読んだ時に思った。
462:419
08/08/11 14:44:37
20年前じゃなくて15年前だった。かなり記憶が混乱してるな、俺 orz
463:デフォルトの名無しさん
08/08/11 16:05:22
>>461
あまり理解できてなかったんじゃない？w
464:デフォルトの名無しさん
08/08/11 16:13:31
>>463
かもしれない。
できれば君が読んでポイントだと思ったところを挙げてくれると皆の参考になると思う。
465:デフォルトの名無しさん
08/08/11 16:20:35
PJの最初の本だと、
例え動的型チェックをやろうとも、そのコードは、
他の普通のコードと一緒でスーパー・コンビネータになって、
グラフ簡約されるだけだから、コンパイル時に型チェックを済ませることが、
スーパー・コンビネータのグラフ簡約上、特に有利だとは思えません。
466:デフォルトの名無しさん
08/08/11 17:39:55
横から口はさんですまんが、静的型がついていたほうがパターンマッチが速くならね？
467:デフォルトの名無しさん
08/08/13 09:02:33
Haskellの継続ってSchemeとは違いありますか？
468:デフォルトの名無しさん
08/08/13 10:48:15
call/cc のようなものはありません
469:デフォルトの名無しさん
08/08/13 11:17:46
>>468
MonadCont の callCC :: ((a -> m b) -> m a) -> m a のことじゃないの。
>>467
俺も気になる。違いはあるだろうけど、どう違うのか。
470:デフォルトの名無しさん
08/08/13 11:23:16
やっぱりそうですか。継続ベースのアプリ
作るとしたら、ステートモナドに次のアクション
入れておくとかですかね。
471:デフォルトの名無しさん
08/08/13 13:45:50
MonadContだと、型の関係で、無限ループするような式は書けない。
# mfixとか使えば別だけど。
例えば、Schemeで次の式は書けるが、MonadContでは書けない。
(call/cc (lambda (c) c))
(call/cc (lambda (c) (set! foo c)))
つまり、次の式は型が付かない。
callCC (\c -> return c)
callCC (\c -> lift $ put c)
要は、callCCで捉えた継続をそのcallCCの外に出せない。ただし、
callCC (\c -> ... callCC (\c' -> c c') ...)
のように、内部で別のcallCCを使って、それで捉えた継続を外に出すのはOK。
あと、変な例として、
callCC (\c -> return (Right (c . Left)))
はOK。でもやっぱり無限ループはできない。
472:デフォルトの名無しさん
08/08/13 14:58:55
>>471
だとすると、smlのcall/ccを使ったco-routineみたいなことはできないということ？
473:デフォルトの名無しさん
08/08/13 17:43:19
smlのcall/ccを使ったco-routineは知らないけど、co-routine自体はできる。
import Control.Monad.Cont
foo = callCC (\c0 ->
do
c1 <- callCC c0
c2 <- callCC c1
c2 10
undefined)
bar =
(do
c1 <- foo
c2 <- callCC c1
callCC c2)
main = print $ runCont bar id
474:デフォルトの名無しさん
08/08/13 18:18:41
>>471
HaskellでYコンビネータを書くとき型が問題になるけど、
実質的には fix f = let g = f g in g で問題ない。
それと同じように、
loop = callCC (\c -> let g = c g in return g)
とすれば
do { l <- loop; liftIO $ print 0; l }
のように無限ループを書ける。
(これの変数付きループ版が MonadLib にあった。)
(call/cc (lambda (c) c))
がどう使われるのかよく分からないけど、
実質的には同じことになるんじゃないかな?
(call/cc (lambda (c) (set! foo c)))
callCC (\c -> lift $ put c)
は IORef を使うと問題なくできる。
State だと無理だけど、新しく再帰的なデータ型を定義してやれば、
あまり便利では無さそうだけど一応できた。
475:デフォルトの名無しさん
08/08/13 22:46:51
オラ本の執筆遅れてます
著者にプレッシャﾖﾛ
476:36 ◆K0BqlCB3.k
08/08/13 22:51:05
どうせ買わないので暖かい目で見守るだけです。
477:デフォルトの名無しさん
08/08/13 23:21:14
Schemeのcall/ccってその時点の継続を勝手にキャプチャして渡してくれる
んですよね？Haskellではそういうのは無いと思っていいんでしょうか？
478:デフォルトの名無しさん
08/08/14 00:04:58
>>477
モナド無しでということなら無い。
そもそもcall/ccは副作用があるし。
479:デフォルトの名無しさん
08/08/14 13:47:21
>>474ができると言ってるじゃないか
480:デフォルトの名無しさん
08/08/14 17:35:34
あれはモナド有りでの話だよ。
481:デフォルトの名無しさん
08/08/14 18:53:40
ごめん、>>479は>>477へのレスね
482:デフォルトの名無しさん
08/08/14 18:54:49
山本モナド
483:デフォルトの名無しさん
08/08/16 19:35:13
Haskellはボブマリーの言語?
URLﾘﾝｸ(lethain.com)
484:デフォルトの名無しさん
08/08/16 20:24:00
コメント欄も読もうな
485:デフォルトの名無しさん
08/08/16 22:50:09
URLﾘﾝｸ(profile.myspace.com)
こうゆう落ちもある。
486:デフォルトの名無しさん
08/08/17 12:30:17
Xmonad/Config archive - HaskellWiki
URLﾘﾝｸ(haskell.org)
の設定ファイル郡を理解できるぐらいまでHaskellについて知りたいんですが
どこから勉強すればいいんでしょう？
知識はXmonadやGhcをソースからインストールできる程度です
487:デフォルトの名無しさん
08/08/17 13:44:52
>>443 >>446 静的で強い型を持つ言語は、単純な実行時エラーを防ぐので
テストは軽減する。haskellなどはそのことが数学的に証明されているので
プログラマはぬるぽやoutofboundsなどの基本的な間違いにであうことなく、
本質だけを考えることができる。
488:デフォルトの名無しさん
08/08/17 14:23:37
パターンマッチに失敗すること多くない？
たとえば「空でないリスト」型が欲しいとき、ぬるぽ的な実行時エラーを防げるの？
489:デフォルトの名無しさん
08/08/17 14:47:05
ぬるぽは無いけどout_of_bounds発生させまくりですが
依存型のある言語なら防げるかも知れんけど
490:デフォルトの名無しさん
08/08/17 15:31:08
>>487
おまえ初心者スレにいたHaskell信者だろ。
491:デフォルトの名無しさん
08/08/17 18:08:12
はいはい両者リングアウト
492:デフォルトの名無しさん
08/08/17 18:14:59
>>488
それヘボすぎ
493:デフォルトの名無しさん
08/08/17 18:26:58
モナドがIOに使えるのは分かった。けどどうしてそれをIO以外にも使ってるの？ >Haskell
誰か教えて下さい
494:デフォルトの名無しさん
08/08/17 18:36:20
Maybe(笑)を証明するため
495:デフォルトの名無しさん
08/08/17 18:36:41
便利だから
496:デフォルトの名無しさん
08/08/17 18:42:38
どんな時に便利ですか？
497:デフォルトの名無しさん
08/08/17 18:59:33
モナドのすべて
URLﾘﾝｸ(www.sampou.org)
の以下の部分を読むとわかるかも
Maybe というモナド
ひとつの例
リストもモナド
498:497
08/08/17 19:11:05
第 II 部：標準的モナドのカタログ
の各モナドの利用場面や動機を見るのもいいかもしれない
499:デフォルトの名無しさん
08/08/17 19:15:59
一応リストモナドやMaybeモナドが計算に使える、というのは理解しているつもりですが、
便利だからという理由以外にモナドをIO以外に使う理由はあったりしますか？
それだけの理由で使うには扱いが難しくて、プログラムを組む度に頭がオーバーヒートしそうになる
慣れの問題かそれとも理解不足か・・
500:デフォルトの名無しさん
08/08/17 19:25:15
>>489
そこでmaybeもなどですよ。
501:デフォルトの名無しさん
08/08/17 20:06:22
モナドという抽象的な枠組みを考えることで
IO, Maybe, List, etcの計算の合成を統一的に扱えるってのが最大の利点なんではないかと。
単に使うだけなら主に慣れの問題だと思う。
いろんな例を見て慣れていけば少しずつ理解もできていくんではないかと。
502:デフォルトの名無しさん
08/08/17 20:09:49
自分の作ったモナド上でdo式を書くと、世界の法則を書き換えてるような気分になってちょっと面白い
503:デフォルトの名無しさん
08/08/17 20:33:06
>>501
レス有難うです
慣れの他に密度の問題もあるかもしれないと思ったり。
他の言語より1行あたりの密度が濃いものになりやすい気がする。
というか濃縮されすぎてわけが分からなくなりやすい気がする。
504:デフォルトの名無しさん
08/08/17 20:38:12
>>501
計算を統一的に扱うだけであれば、普通の型クラスでいいんですよね？
モナドは値ではなくて型コンストラクタに対するクラスなので、ちょっと違う
と思うんですが。
505:36 ◆K0BqlCB3.k
08/08/17 20:39:51
モナドっていうと仰々しいイメージがあるかもしれないけど、
所詮はただの代数的データ型とそのデータ型に対して一貫性あるAPIのセットに過ぎないよ。
ところで、 データ型とAPIのセット のことをなんて呼べばいいの？
506:デフォルトの名無しさん
08/08/17 20:40:10
Stateモナドとかの(s -> (a,s))みたいな変な定義が気持ち悪い
型クラス(b,s) -> (a,s)に型bを部分適用したって考えれば意味は通るけど……
507:デフォルトの名無しさん
08/08/17 21:08:43
>>505
それが「型クラス」、ではないのでしょうか？MonadやFunctorはちょっと
毛色が違うという認識は勘違いでしょうか？
508:デフォルトの名無しさん
08/08/17 21:17:01
URLﾘﾝｸ(www.hyuki.com)
Ord、Eq、Show などの データ型とそのAPIのセット は「型クラス」
Functor、Monad、MonadPlus などの データ型の構築子とそのAPIのセット は「型構築子クラス」
509:デフォルトの名無しさん
08/08/17 21:31:22
それ単にOrdとかの『類』は*で引数をとらないけど
Functorの『類』は*->*みたいに引数をとる、って違いにしか見えない
分けて考えるのはおかしいと思う
510:デフォルトの名無しさん
08/08/17 21:37:45
>>509
型クラスと型構成子クラスじゃ抽象度が違うよ。
511:デフォルトの名無しさん
08/08/17 21:49:13
俺も>>509みたいに感じるなあ
抽象度が違うのは理解できるが
512:507
08/08/17 21:58:16
抽象度の違う型クラスを持つことで、値の計算遷移とは別レベルの
遷移を持つことが可能だ、という印象を持つんですけどどうなんでしょうか。
普通の計算を行う裏側で別の次元での計算が行われ、且つそれが
結合法則を満たしている、というのがモナドの定義と考えるのは
どうですか？自分は圏論などのこと全く無知なのでHaskellの構文
からの直感的な印象だけなんですけど。
513:デフォルトの名無しさん
08/08/17 21:59:06
じゃあ類が*->*->*（関数(->)とかタプル(,)とか）に対する型クラスとかは
もっと抽象度が違うので別の名前が必要なのか？型構築子構築子クラスとか。
有名な人が書いてるから鵜呑みにしてるだけなんじゃないの？
514:デフォルトの名無しさん
08/08/17 22:31:24
>>512
だいたいあってんじゃね？
見えてる部分で適当に処理を書いたら裏で適当に処理してくれる、
普通のプログラミング言語じゃfor文やif文みたいな処理構造、
あるいはマクロとして提供されるものと同等の処理ができるんだけど、
実態は単に型クラスでしかないので俺定義できるし、高階関数使えるし、表記もシンプルで、いろいろ小細工が利くのが利点。
たとえば、IOみたいにコンストラクタを隠したりすれば脱出不可な構造を作れるってわけ。
結合法則を満たしているってのは、まぁ別に特別なことじゃない。
EqやOrdにも反射律とか推移則とか守らないといけないルールがあるけど、
よっぽどのことがない限り変な実装はしないだろうから、一般のプログラミング言語ではそこまで突っ込まない
でもモナドって実態がよくわかんないから、ルールを明記してる。そんだけでしょう。
515:デフォルトの名無しさん
08/08/17 22:45:32
念のため補足。
＞処理構造(略)同等の処理ができるんだけど
普通の言語では処理構造のものが、モナドが利用されてる例としてはErrorモナドとかContinuationモナドとかがあったね。
＞よっぽどのことがない限り変な実装はしないだろうから、一般のプログラミング言語ではそこまで突っ込まない
浮動小数点の比較と等価性で違う実装がされてるとか、変な実装もあるけど。
個人的にはMonad則は、
値に関して順次実行できる何かで、値に対して何もしない処理もできる何かだ、というルールだと解釈してる。
516:デフォルトの名無しさん
08/08/17 22:50:03
変な実装＝全順序じゃない、と読み替えてくれ。
コンピュータのメモリ節約を考えれば生の浮動小数点型を使うのもまっとうな実装だわｗ
517:デフォルトの名無しさん
08/08/17 23:19:23
ごめん、誤解を招くといやなのでもう一つ補足……
＞値に関して順次実行できる何か
これは実行順序じゃなくて値の計算する方向を言ってるだけだよ。
g.f x がxにfを適用してgを適用するってのと同じことだよ。
実行順序は普通のモナドもIOモナドも方向は決まってないよ。
518:初心者修業中
08/08/17 23:37:55
ん？
実行順序を明確にするのがIOモナドの目的の一つ
と認識していますが。
そういう意味ではないのかな…
519:デフォルトの名無しさん
08/08/17 23:41:24
Haskellをみて日本のhaskellコミュって元気なの？
他の言語に比べて内と外をわけすぎるようなそんな印象をもってる。
なんでだろ？
520:デフォルトの名無しさん
08/08/17 23:58:38
>>518
たとえば、
1:2:3:[]は、
1:2:3:[] → 1:2:[3] → 1:[2, 3] → [1, 2, 3]と簡約されるかもしれないし、
1:2:3:[] → [1, 2:3:[]] → [1, 2, 3:[]] → [1, 2, 3]と簡約されるかもしれない。
でも結果は一緒でしょ？
同じように、
Hello, Worldって出力 >> 一文字入力 >>= 前の文字を出力
みたいなのは、まぁ言ってみれば(不正確だけど)
[Hello,Worldって出力, 一文字入力, 前の文字を出力]みたいな並びにされる(と思われる。実装はカプセル化されていて不明)。
この並びがプログラム終了後にコンパイラにわたって、コンパイラがこれを順番に処理していく。
実はこの並びをプログラム終了後以外に評価する方法があって、それがUnsafePerfomedIOって言う関数。
getContentとかは実はこれを使って実装されている。
Unsafeという名前が示すように、素人にはお勧めできない。(getContent自体は普通に使える。)
521:デフォルトの名無しさん
08/08/18 00:02:55
Maybeの特化にしか見えません
522:36 ◆K0BqlCB3.k
08/08/18 00:25:49
>>519
世界的に全く元気がありません。
ちょこっと変なライブラリを書いたと思えばそれっきり離れていっている人も多数。
523:デフォルトの名無しさん
08/08/18 01:36:55
>>520
後者の簡約は型がおかしいし、1:2:3:[]ではなく、
f x = (unsafePerformIO $ print x) `seq` xで
f 1:f 2:f 3:[]だった場合、前者と後者の簡約順序ではprintの順番が違ってくる。
前者は3,2,1で後者は1,2,3
一方で(>>=)は最左最外簡約でも最右最内簡約でも
左から順にしか値が定まらないようになってる。
putStr "Hello" >>= (\ _ -> getChar) >>= (\ c -> putChar c)
(>>=)の右辺が関数だから左辺の値が定まるまでa >>= bが最終的な値に簡約できないようになっている。
524:デフォルトの名無しさん
08/08/18 03:17:18
>>522
元気無い理由って何でしょうか。他に元気ある言語ってあるのかな。
525:デフォルトの名無しさん
08/08/18 04:14:24
ruby
526:デフォルトの名無しさん
08/08/18 08:38:27
>>520
> 1:2:3:[] → [1, 2:3:[]] → [1, 2, 3:[]] → [1, 2, 3]と簡約されるかもしれない。
型が滅茶苦茶だよ。
> この並びがプログラム終了後にコンパイラにわたって、コンパイラがこれを順番に処理していく。
意味不明。なぜプログラム終了後にコンパイラが出てくる。
ランタイムライブラリとごちゃまぜになているぞ。
527:デフォルトの名無しさん
08/08/18 10:05:00
Haskellにこういう奴が多い気がするのはなぜだ
528:デフォルトの名無しさん
08/08/18 10:21:37
「こういう奴」と書けばどんな奴を指してるのか分かってもらえると思ってるような、
想像力の貧しい奴がこのスレに多いような気がする
529:デフォルトの名無しさん
08/08/18 13:36:03
末尾が「気がする」で終わってるレスは
全部気のせいのような気がする
530:デフォルトの名無しさん
08/08/18 15:08:49
なんという自己言及レス
531:デフォルトの名無しさん
08/08/18 15:12:16
関数型らしくて言いじゃないか
532:デフォルトの名無しさん
08/08/18 15:41:06
>>531
つ座布団1枚
533:デフォルトの名無しさん
08/08/18 21:50:15
* -> * -> * ってどんなとき使うの？
534:デフォルトの名無しさん
08/08/18 22:25:25
アナルトレイン
535:デフォルトの名無しさん
08/08/19 07:45:46
（ ﾟдﾟ）ﾟдﾟ）ﾟдﾟ）
/ つ つ つ
(_(_ ﾉ ノ ノ
し∪ ∪ ∪
536:デフォルトの名無しさん
08/08/19 10:10:53
>>505
> ところで、 データ型とAPIのセット のことをなんて呼べばいいの？
プログラミング言語一般での話なら「抽象データ型」でしょうね。
537:デフォルトの名無しさん
08/08/19 11:50:46
>>533
関数(->)とかタプル(,)とか
538:デフォルトの名無しさん
08/08/20 20:24:46
485でおま。
それでなのです。 >ときどきの雑記帖の中の人
539:デフォルトの名無しさん
08/08/21 14:40:13
Arrow は * -> * -> * のクラス
MonadTrans は (* -> *) -> * -> * のクラス
540:デフォルトの名無しさん
08/08/21 21:20:37
URLﾘﾝｸ(book.realworldhaskell.org)
これの30章が消えてるんだけど・・・。
541:デフォルトの名無しさん
08/08/21 22:05:29
本買えよ
542:デフォルトの名無しさん
08/08/21 23:26:23
30章だけが読みたいんだよ。
ところで、HaskellでPetStoreってあるの？
543:36 ◆K0BqlCB3.k
08/08/21 23:56:58
>>542
横からすみませんが、
Pet Storeをよく知らないのでちょこっと検索したんですが、
これっていったい何が面白いんですか？
544:デフォルトの名無しさん
08/08/22 00:08:29
>>543
面白くは無いんだけど、色んな言語やフレームワークで同じもの作る
ことで比較をするためのものでしょ。同じアプリがこんな感じで作れ
ちゃうぞ、という。
545:デフォルトの名無しさん
08/08/22 11:40:45
Haskellでウェブアプリというとふつう本か
546:36 ◆K0BqlCB3.k
08/08/22 12:37:40
最近では新しい言語はWEBアプリが書きやすくないと人が入ってこないらしく、
ライトウェイト言語がブームみたいだね。
HaskellはライトウェイトではないからWEBアプリ向きとは全然思えないんだけど、
RubyでRubyOnRailsが考えられたみたいにHaskell独自のWEB向きキラーアプリが
出てこないとHaskellの人気はこれからもずっと平行線だと思うよ。
547:デフォルトの名無しさん
08/08/22 12:41:19
>>546
WEBアプリが書きやすいっていうより、APIとかWEBコンテナが標準装備されてないとダメという感じがする。
Javaの功罪は大きい。
548:デフォルトの名無しさん
08/08/22 12:41:59
まだ横ばいならたいしたもんだ
549:デフォルトの名無しさん
08/08/22 12:48:26
>HaskellはライトウェイトではないからWEBアプリ向きとは全然思えないんだけど、
ライトウェイトって何？動的に型を付ければライトウェイト？
それとwebとどういう関係があるの？
550:デフォルトの名無しさん
08/08/22 13:05:36
あまり考えずに気の向くままに書いてもあっさり動くのが
ライトウェイトってことじゃないか？
web案件は短期だったりアジャイルだったりでライトウェイトに
開発できるのが求められてるってのはある
551:デフォルトの名無しさん
08/08/22 13:10:45
WEBアプリの開発者は、JavaかRubyのHowto本から入ってる。
だから、WEBアプリ開発者は、身体のどこかに、プログラミング言語のJavaかRubyに似てない部分に拒否反応を持ってる。
552:デフォルトの名無しさん
08/08/22 13:11:10
ここでHaskellは人間の思考過程に最も近いから
考えが即座にコードにうつせるため開発期間が最短であると主張する人がどこからか登場
↓
553:デフォルトの名無しさん
08/08/22 13:23:23
｜
（ ﾟдﾟ ）↓
（⊃⌒*⌒⊂)
/__ﾉ''''ヽ__）
554:デフォルトの名無しさん
08/08/22 13:27:58
>>550
それならHaskellもライトウェイトで良くね？
555:デフォルトの名無しさん
08/08/22 14:05:36
明示的なコンパイル作業が必要ないってのはLLの必要条件な気がする。
556:デフォルトの名無しさん
08/08/22 14:18:04
LLとかWebアプリとか、
だから普及しないとか、
どうでもよくねえ?
好きな事、楽しい事すればいい。
557:デフォルトの名無しさん
08/08/22 14:22:47
>>555
runghcがあるじゃないか
もうちょっと速ければと思うことはあるけど
558:デフォルトの名無しさん
08/08/22 14:34:05
>>556
そういう立場も理解できるけど、俺は普及してほしい
ライブラリのメンテとか人が足りてないじゃん
559:デフォルトの名無しさん
08/08/22 14:46:33
>>552
Prologには負けるんじゃない。
560:36 ◆K0BqlCB3.k
08/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
08/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:デフォルトの名無しさん
08/08/22 15:03:43
LLでHaskell関係のプレゼンとかしてる人いるみたいだけど？
563:デフォルトの名無しさん
08/08/22 15:07:56
WebアプリとLL（と呼ばれている言語）との間には全く関係はないけど、
Webアプリのかなり大部分は一般的にLLと呼ばれている言語で書かれているだろう。
そういう"LL"はテキスト処理がしやすいからってのがあるだろうな。
まあHaskellがそういう意味で人気にならなくても別にどうでもいいけど。
ここでmondic Parser Combinatorを持つHaskellが
最もテキスト処理に適した言語であると主張する人がどこからか登場。
↓
564:デフォルトの名無しさん
08/08/22 15:38:43
HaskellもLL言語だよ
565:デフォルトの名無しさん
08/08/22 15:45:06
これどうなの？
URLﾘﾝｸ(happs.org)
566:デフォルトの名無しさん
08/08/22 16:09:31
Parser Combinatorがあるからテキスト処理ならHaskell最強だろ。
満足した？
567:デフォルトの名無しさん
08/08/22 17:42:48
haskellは型推論がちゃんと効いてる使い方が出来れば、LL的な生産性は確保できるだろう。
だがな、至高の存在で良いじゃないか。
haskellの性質上webプログラミングは不得意分野に思うんだが、mod haskellなんて生まれる
分けでもないし生まれたところで破壊的操作がほとんどできないし、ファイル操作は基本的に
苦手でしょ。webは動的言語の親玉が一番向いてるけどs式アレルギーな人が多いからLLに
なってるんでしょうね。
だから、無理にwebに擦り寄らずとも良いと思うんだけどね。むしろ、破壊的操作より安全性を
大切にされる金融などのところで目立つ存在になってくれたらいいんじゃないか？
568:36 ◆K0BqlCB3.k
08/08/22 18:09:07
>>567
もし金融などで使われることを想定するなら、
haskellの並列処理に関する部分も早く実装してほしいところですね。
（まだ未完成）
569:デフォルトの名無しさん
08/08/22 18:44:00
某氏のhapps解説はお流れ？
>>567
> 破壊的操作がほとんどできない
なんで？
570:デフォルトの名無しさん
08/08/22 18:58:34
なんでそんなにHaskellの応用分野を限定したがるんだｗ
>>567
コンパイルするならmod_haskellがあっても恩恵は小さいだろ
>破壊的操作がほとんどできないし
Haskellで入出力書いたことあるか？
>ファイル操作は基本的に苦手
これも良く分からん
flock使うのにわざわざライブラリを落としてこないといけないとか、そういうこと？
571:デフォルトの名無しさん
08/08/22 19:43:28
ウイルス対策ソフトのように危機感を煽るのはいいが、
既存のシステムを補強するのではなく全部作り直せというのは、ちょっとね
572:デフォルトの名無しさん
08/08/22 19:54:17
>>570
Prologを事務処理に使うと、住所や氏名情報などで爆発的にアトムが
発生し、Heap領域を埋め尽くして、GCが頻発するという事態となる。
もちろん数百万レコードを越える処理単位の話だが。
Haskellの場合この問題は起きないの?
573:デフォルトの名無しさん
08/08/22 20:37:03
Webアプリが苦手ってことは無いと思うんだけどな。今後Webベースのアプリは
まだ増殖するだろうから、そっちで使いやすいフレームワークやDSLが出ないと
使う人は頭打ちだと俺も思う。
研究者の論文レベルのものも面白いだろうけど、上から下までHaskellベースで
かかれたWebアプリとかで目立つものが出てほしいよ、個人的には。
574:デフォルトの名無しさん
08/08/22 20:53:32
>>572
アトムの爆発ってのはPrologスレで言及されてる現象のことでいい？
そもそもPrologのアトムってのが良く分からんので何が問題なのか理解できん
Lispのシンボルみたいな物と思っていいのかな
それなら相当するものはHaskellにはないよ
575:デフォルトの名無しさん
08/08/22 21:35:41
>>574
Lispのシンボルみたいな物、ですね。
記号をどう処理しているのですか。
576:デフォルトの名無しさん
08/08/22 21:53:05
>>540
30章ってなんの章だったの？
577:デフォルトの名無しさん
08/08/22 22:12:26
>>575
「記号」と言われてもいまいちピンと来ないんだが、何にせよ、
普通の手続き型言語が「記号」を処理するのと大差ない方法で処理してると思う
取り得る種類がコンパイル時に決まっているなら列挙型
そうでないなら整数とか文字列
文字列の比較のコストが問題になるなら自分でシンボルテーブルのようなものを用意する、とか
578:デフォルトの名無しさん
08/08/22 22:34:03
>>576
>>310-314
579:デフォルトの名無しさん
08/08/23 09:45:26
>>572
Prologでも、
1レコード512バイトをsub_atomで30項目に分解したり、更にsplitの
処理をしたりすると確かにアトムが大量発生するだろうが、
Stringとして読み込んで、終始String処理に徹すれば、アルファベットの
数、つまり高々数万のアトムで済むんじゃないの?
Stringすなわちリスト処理になると遅いから嫌なのかな。
580:デフォルトの名無しさん
08/08/23 10:00:27
宣言的言語をリアルタイム処理に使いたくない病にかかってる。
資源が十分にあると理屈では分かっていても、終わったら電源切っても大丈夫な処理じゃないと拒否反応がでる。
581:デフォルトの名無しさん
08/08/23 10:09:14
>>579
処理速度もあるかも知れませんが、アトムだと、
foo([株式会社|R],R).
と書けるところが、Stringだと
foo(List,R) :- append("株式会社",R,List).
と書かなくてはならないということがあります。
appendを高速化する機構が欲しくなりますね。
582:デフォルトの名無しさん
08/08/23 10:35:10
それって代数的データ型を使ってこんな感じで良いんじゃない？
data Atom = Kabushiki | Dummy deriving (Show, Eq)
foo :: [Atom] -> [Atom]
foo (Kabushiki : r) = r
583:デフォルトの名無しさん
08/08/23 11:43:27
Prologでまったり Part3
ｽﾚﾘﾝｸ(tech板)
584:デフォルトの名無しさん
08/08/23 12:43:04
>>581
この話おかしいよ。
foo([株式会社|R],R). の方は、
すでに株式会社というアトムが切り出されていて、リストの構成要素になっている。
一方、
foo(List,R) :- append("株式会社",R,List). のListはString。ここは、
foo(["株式会社"|R],R).
でなきゃ、フェアじゃない。
585:デフォルトの名無しさん
08/08/23 13:58:45
>>572
> Prologを事務処理に使うと、住所や氏名情報などで爆発的にアトムが発生し
第五世代コンピュータプロジェクトの成果を是非参照下さい。
586:36 ◆K0BqlCB3.k
08/08/23 14:16:16
>>585
よく知らないけどソフトウェア科学会会誌7月号に第五の話題が載っていたよ
587:デフォルトの名無しさん
08/08/23 14:21:10
成果って、「prologって役立たずじゃん」という結論を得たこと？
588:36 ◆K0BqlCB3.k
08/08/23 14:28:53
>>587
それは短絡的な人たちの根拠のないうわさ。
第五は基礎研究なので企業の人たちが求めるような成果が出ないのは当たり前のこと。
589:デフォルトの名無しさん
08/08/23 14:31:33
Prologの話は他でやってくれ
んで問題点を整理してまたいらっしゃい
590:36 ◆K0BqlCB3.k
08/08/23 14:33:31
詳しいことは忘れたけど、
述語論理による仕様記述を使った鉄道のプロジェクトが企業側で行われた例があったような。
なんだったっけ？
591:デフォルトの名無しさん
08/08/23 14:45:22
Prologはどうでもいいのだが、Haskellで金融(とくに保険業)のアブリを
開発する場合、何か問題になる点はないのか。
592:デフォルトの名無しさん
08/08/23 14:54:20
>>591
必要なメモリサイズを予測しにくい点とか。full lazyな処理系全般に言えると思うけど。
593:デフォルトの名無しさん
08/08/23 14:57:02
金融系システムにHaskellを使うメリット自体が思いうかばん。
いいじゃん、Javaでつくるのが流行ならJavaで作らせれば。
どうせ枯れたシステムなんだから。
594:デフォルトの名無しさん
08/08/23 15:00:18
>>592
full lazyな処理系って、よくわからない。
595:36 ◆K0BqlCB3.k
08/08/23 15:11:43
どんな言語で書いたとしても、必要なメモリの量は実際に動かしてみないとわからないよ。
596:デフォルトの名無しさん
08/08/23 15:17:46
haskellっていいプロファイラあんの？
597:デフォルトの名無しさん
08/08/23 15:26:42
>>595
COBOLなんかは確定してると思うけど。
598:デフォルトの名無しさん
08/08/23 15:42:16
>>597
してない。
SORTなどに内部的に使う記憶容量が不明。
599:デフォルトの名無しさん
08/08/23 15:43:11
Haskellのようにデフォルトで遅延評価する言語は、
計算をできるかぎり遅延させようとするから、
下手な書き方するとすぐメモリリークする
Haskellのメモリリークは大抵の場合小規模な修正で直るけど、
どこを修正すべきか探すのに慣れとプロファイラが要る
>>596
GHC付属のプロファイラは優秀だと思う
600:36 ◆K0BqlCB3.k
08/08/23 15:47:59
>>596
profオプションをつけてコンパイルしたらランタイムシステムにプロファイラが組み込まれるよ。
詳しくはマニュアルで。
601:デフォルトの名無しさん
08/08/23 16:19:23
>>598
ん？確定はしてなくても最大どれかけかかるかは確定してるでしょ。
グラフ簡約のヒープ消費は予測もつかんぞ。
602:デフォルトの名無しさん
08/08/23 16:27:11
>>601
確定してるのかしてないのかどっちだｗ
603:初心者修業中
08/08/23 16:37:52
Haskellでメモリーリークが起きるのですか?
ガベージコレクションにバグがない限り、
メモリーリークが起きるとは思えないのですが…。
FFIを使った場合の事でしょうか…。
604:デフォルトの名無しさん
08/08/23 17:15:44
>>599 の例としては↓の話かな。
URLﾘﾝｸ(d.hatena.ne.jp)
この場合のメモリーリークは単なるメモリの解放忘れって事ではなくて、
期待した解放タイミングと実際のそれとのギャップの事みたいだね。
605:初心者修業中
08/08/23 17:42:49
これも「メモリーリーク」と呼ぶのでしょうか？
*Main> foldr (+) 0 [0..1000000]
*** Exception: stack overflow
606:デフォルトの名無しさん
08/08/23 18:05:58
プログラマが意図してないで、リファレンスが残るようなコーディングを
しちゃってる、というのをリークに含めることもある。
607:デフォルトの名無しさん
08/08/23 18:34:57
>>605
それは「マヌケ」と呼びます。
608:初心者修業中
08/08/23 18:57:56
stack overflowが発生する時、
簡単にわかる場合は「マヌケ」
ちょっとわかりづらい場合は「メモリーリーク」
と呼ぶという認識でよろしいでしょうか？
609:デフォルトの名無しさん
08/08/23 19:14:20
リークってのは「漏れ」のこと。
GCのある言語だと、>>606しか起こり得ない。
>>605の「溢れ」とは全然違う。
610:デフォルトの名無しさん
08/08/23 19:20:46
>>605
それはスタックオーバフロの例外であって、エラーとは違う。
メモリリークしているわけではないよ。
611:デフォルトの名無しさん
08/08/23 19:22:12
C言語みたいに型があいまいな言語ではメモリリークが起こりうるが、
Haskellみたいに強い静的型付けされている言語にはメモリリークなんてありえないよー
612:デフォルトの名無しさん
08/08/23 19:26:56
スタックオーバーフローとメモリーリークは
現象として全然違うと言う事ですね。
分かります。
613:デフォルトの名無しさん
08/08/23 19:53:14
>599や>604が挙げているような例はC言語で
良く言われる「メモリーリーク」とは違う現象だな。
Haskellの場合、遅延評価がデフォーなので
うかつに再帰を使うと計算の途中結果が膨大な
ものになってヒープ領域が溢れてしまう。
Cの場合はただの確保したメモリの解放し忘れ。
Cでも再帰的なメモリー確保をすれば
Haskellみたいな事も起きうるはずだが。
614:デフォルトの名無しさん
08/08/23 20:06:48
>>611
強い静的型付けとメモリーリークの有無はほとんど関係がありません。
GCの方がずっと関係が深いです。
615:デフォルトの名無しさん
08/08/23 20:09:24
Pascalのnewとfreeだっけ?
あれ考えれば分かるよな。
強い型付けでも簡単にメモリーリークは起きる。
616:デフォルトの名無しさん
08/08/23 20:56:45
foldl でも stack overflow するんだよね。
Data.List.foldl' 使えばいいんだけど。
617:デフォルトの名無しさん
08/08/23 21:35:43
なんで foldl でスタック溢れるの？末尾再帰が最適化されてないの？
618:デフォルトの名無しさん
08/08/23 21:48:31
>>604のリンク先に書いてある
末尾再帰は最適化されるよ
619:初心者修業中
08/08/23 23:53:01
>>617
遅延評価だからと認識しています。
↓参考
URLﾘﾝｸ(haskell.g.hatena.ne.jp)
620:617
08/08/24 00:40:37
>>618-619
なるほど、非常によくわかりました。
（つーか前出のリンク読まずにレスして申し訳ない）
うーむ、しかし末尾再帰が最適化されることの旨みは、
・ローカルスコープの値をスタックに積む必要がなくなることと
・連続するreturnが省略されること
の２点だと思うけど、foldl のように結局は遅延評価のための
computation がスタックに積まれていて、後から順次簡約するなら
「最適化されている」とは言い難い気もするな・・・。
最適化するための然るべき変形は、一応してあるんだろうけど。
まあ seq 使うとか、回避の仕方がないわけじゃないからいいのかな？
621:デフォルトの名無しさん
08/08/24 00:54:46
↓にも関連した話が載ってる。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
622:デフォルトの名無しさん
08/08/24 13:10:00
■■学校を作ろう！■■
VIP発でサイトを作ろうと思うんだ。（詳しくはWikiを見てくれ）
パートスレになるんでパー速（GEP)に移動している。
今スタッフを募集しているから、来てくれないか？
■Wiki
URLﾘﾝｸ(www36.atwiki.jp)
■募集スタッフ
プログラム担当（特にErlang、Perl）
デザイナー（サイト上のアイコン、ロゴなど）
WEBデザイナー（サイトデザイン案に沿って、htmlやCSSを書ける）
他にも宣伝担当なども募集している。
■スレ
URLﾘﾝｸ(ex14.vip2ch.com)
623:デフォルトの名無しさん
08/08/24 16:41:26
「特にErlang」…
実用性でいうとやっぱErlangなのかな…
624:デフォルトの名無しさん
08/08/24 18:20:21
>623
大規模なWebサービスを構築するのに向いていると
考えたから企画者がErlangを採用したんだろうね。
625:デフォルトの名無しさん
08/08/25 09:10:25
大規模な、ってのがクセ者で、
実情は単にDBのテーブルが大きいだけだったりするよな。
そもそもウェブアプリでDB以外どこが肥大化するよ？
626:デフォルトの名無しさん
08/08/25 09:11:28
画面？
627:デフォルトの名無しさん
08/08/25 09:20:29
>>625
複数のwebサービスから情報集めたり、もしくはhttp以外のプロトコルで通信して情報を取得しなきゃいけなかったり、
別プロセスで並列キューに入れて処理しなきゃいけなかったり、システムそのものが大きくなるとこはあると思う。
それともデータサイズの規模に限定した話？
628:デフォルトの名無しさん
08/08/25 09:53:32
>>625
とりあえずErlang + YAWSの事例くらいは、
念頭においてくれないと、話にならないのでは?
629:デフォルトの名無しさん
08/08/25 09:55:11
>>627
> 複数のwebサービスから情報集めたり、
そういうのはAjaxでクライアント側がやるのが流行では？
まあサーバ側がやってもいいですが、HTTPセッションを入れ子にするのは
あまり筋がいい設計とは思えません。
> もしくはhttp以外のプロトコルで通信して情報を取得しなきゃいけなかったり、
まあDB接続なんかもそうですよね。
しかし「大規模になる」ような要因とはあまり考えられないのですが。
> 別プロセスで並列キューに入れて処理しなきゃいけなかったり、
fastcgiとかの話でしょうか？特段、だから大規模になるというものではないと思いますが。
> それともデータサイズの規模に限定した話？
コード自体はほとんどCMS系フレームワークをユーザ定義コンテナを定義する程度で
用が済むことが多いと思います。特に、>>622のような、いかにもCMSっぽいシステムでは。
630:デフォルトの名無しさん
08/08/25 10:00:08
>>629
> コード自体はほとんどCMS系フレームワークをユーザ定義コンテナを定義する程度で
> 用が済むことが多いと思います。特に、>>622のような、いかにもCMSっぽいシステムでは。
よいCMS系フレームワークを、
容易に開発できるかどうかって話をしているんだと思いますよ。
631:デフォルトの名無しさん
08/08/25 10:54:21
>>630
なるほど、わかりました。
格納するコンテンツの量は結局DBのサイズの問題になると思うので、
それ以外の「大規模」の要因というと、
・同時接続数（パフォーマンス)
・登録ユーザー数
ぐらいでしょうか。
それとも単純にコードサイズを指して「大規模」という話なんでしょうかね。
「学校」というドメインが明確になっているので、
一般のCMSフレームワークほど汎用化は要求されないし、
どのような要因でコードサイズが「大規模」化するのか興味があります。
632:デフォルトの名無しさん
08/08/25 12:22:00
>>624
Apacheとか使わずErlangでサーバー構築するんじゃないの?
633:デフォルトの名無しさん
08/08/25 12:26:39
キッチンシンクアプローチか……
634:デフォルトの名無しさん
08/08/25 13:01:50
Erlangをわざわざ使うということは、数百レベルの並列プロセスを
マルチコアで何とかしようと考えていると見て間違いない。
Webだとすれば、WebServer以外考え難い。生徒数千でほぼ
同時にアクセスがあるとか。
635:デフォルトの名無しさん
08/08/25 13:13:15
しかし、>>622 はなんでErlangスレに書いてないんだ？w
636:デフォルトの名無しさん
08/08/25 13:16:41
単に初期メンバーにErlang使いが居ただけなじゃいの？
637:デフォルトの名無しさん
08/08/25 13:16:52
Erlangスレ見たことない方ですねw
638:デフォルトの名無しさん
08/08/25 13:42:02
Erlangはどうでもいいんだけれど、
HaskellでもPerl使いを確保しておいて、単体の機能は専らCPANから取り出させて、
確保されているインターフェイスを介してHaskellで利用するというやり方は
多くなるんじゃないかな。短時間で開発する一手法としてね。
639:デフォルトの名無しさん
08/08/25 13:57:49
ならないね。
640:デフォルトの名無しさん
08/08/25 14:13:29
>>638 落日のPerlを使うかどうか。 規格書の通りに一からすべて開発するのは確かに大変だね。
641:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/08/26 00:29:58
>>629
大規模になる要因なんていくらでもあるじゃん。
今時は単にUIがWebで、バックエンドが複雑化してるものも少なくないしね。
分散業務システムで多種類のプロセスを相手にすりゃ自然と規模は大きくなるかと。
何でもかんでもインターネット上でパブリックに利用可能な整理されたサービスばかりじゃないからね。
学校だって企業並みにシステムが複雑化してるとこもあるから、強ち単純とは言えないんじゃないかと。
まあ何はともあれ、ロジックが複雑になればなるほど、関数型の恩恵は大きくなるわな。
643:デフォルトの名無しさん
08/08/26 01:08:51
といったって、googleも複雑なシステムとか言われてるけど、
googleを支える技術とか読んでもそんなに複雑とは思えないんだよなぁ。
台数は1台だけど自宅で似たようなことやってるもん。
644:デフォルトの名無しさん
08/08/26 08:11:38
>>641
P のような再帰的な型のモナドを、
効率のために継続モナド(ReadP)で包むのは定石。
Haskell への慣れっていうより、
モナドや継続モナドへの慣れの問題な気がする。
P は問題によって様々だけど、
ReadP のとこは Control.Monad.Cont の
一般的な継続モナドと(型を除いて)同じなので、
それを理解しておくと問題に集中できていいかもよ。
645:デフォルトの名無しさん
08/08/26 08:13:32
つ チラシの裏
646:デフォルトの名無しさん
08/08/26 08:21:08
>>642
それはバックエンドで動いている他プロセスが複雑なのであって
ウェブアプリが複雑なわけではないのでは？
647:デフォルトの名無しさん
08/08/26 08:32:48
>>625
機械翻訳とかではなくて?
648:デフォルトの名無しさん
08/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.
って書いてあるペーパーを見付けました、その継続ベースの方法について考えながら考えていこうと思います。
649:デフォルトの名無しさん
08/08/26 18:52:43
URLﾘﾝｸ(www.cs.chalmers.se) でしょ
650:デフォルトの名無しさん
08/08/26 19:00:04
>>649
そうです、でもこれだけ読んでもこれで何がしたいのか俺には正直よく分かりませんな。。
例がなくても理論だけ聞けば全て分かるタイプの人なら大丈夫なのかもしれませんが。
651:デフォルトの名無しさん
08/08/28 06:47:20
>>648
P みたいなのを継続ベースともいうけど、
ReadP を使うのは純粋に効率のためで、
そこに書いてあるのとは話が違うような。
652:デフォルトの名無しさん
08/08/28 11:12:38
> 純粋に効率のためで
そう単純化されても…
653:デフォルトの名無しさん
08/08/28 14:48:42
いや、単純だし…
654:デフォルトの名無しさん
08/08/28 21:41:23
具体的にどういう場合にどうして効率が良くなるんですか？
ReadPだと、PがReadPで包まれてるわけだけど、
get' = Get return
look' = Look return
sat' p = do a <- get' ; if p a then return a else Fail
char' c = sat' (c == )
string' s = do str <- look' ; scan s str
where scan [] _ = return s
scan (x:xs) (y:ys) | x == y = do get' ; scan xs ys
scan _ _ = Fail
みたいにReadPでくるまないバージョンも用意できて、それもrunで使える。
URLﾘﾝｸ(www.cs.chalmers.se)
ここにも効率がって書いてあるけどどんな場合なのかさっぱりだ。。
655:デフォルトの名無しさん
08/08/29 14:13:46
ReadPはdata宣言じゃなくてnewtype宣言だから、
記述上は包まれた形になってるけど、実装では包みが外れた形になる。
参照: URLﾘﾝｸ(haskell.g.hatena.ne.jp)
Pは直接的にはうまく束ねることができないから、一旦仮想的なReadPで束ねてるって感じ？
656:デフォルトの名無しさん
08/08/29 15:53:54
>>655
どうもありがとうございます。
実際にはReadPの所はR Get やR Lookなどが渡されることになりますよね。
そのあとすぐにrunで即Rはずしてますし。
＞Pは直接的にはうまく束ねることができないから
これってどういう意味で仰ったんですか？
P を束ねてパーサとして使うことも、実際できる（>>654のget'など）のでわざわざどうしてReadPにするのか、
Pの>>=が左結合的に作用するのが問題らしいんですけどそれが問題になる具体的なケースについて
私にはｻｯﾊﾟﾘ思い付かなかったので先人たる皆様にお聞きしたかった次第です。
657:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/08/29 18:19:15
>>657-661
とても分かりやすい解説どうもありがとうございます！
ちょっと解決の糸口がつかめた感じがします、これからじっくり考えてみたいと思います。
とてもご丁寧にありがとうございました。
流石だ。。。
663:デフォルトの名無しさん
08/08/30 18:34:32
Haskellが宣言型言語とか最初に言い出したのは誰なのかしら
664:デフォルトの名無しさん
08/08/30 18:44:45
imperative language ←→ declarative language の対比で
ごく自然発生的なものだと思うが？
665:デフォルトの名無しさん
08/08/31 00:07:29
宣言型言語 = what（何をしたいか）を記述
手続き型言語 = how（どうやるか）を記述
クロージャをいかに早めに潰すかに苦心するHaskellは後者ですな
666:デフォルトの名無しさん
08/08/31 00:38:36
>>665
宣言型言語＝述語論理を記述
と思ったらHaskellも述語論理の仕様記述言語に非常に近い特徴を持っていることに気づく。
667:デフォルトの名無しさん
08/08/31 03:38:00
>>665
> クロージャをいかに早めに潰すかに苦心
ってどういうこと？
668:デフォルトの名無しさん
08/08/31 09:45:13
>>667
関数のインライン展開のようなものじゃないか
よく分からんが
関数リテラルなら展開しやすいが高階関数の戻り値のクロージャは展開しにくい気がする
だからどう書くか (how) を工夫する
人間が問題を「宣言」するだけでコンパイラが問題を解いてくれる
というのは
素朴な解決策は簡単に見つかるのだが最適化が難しい (が機械的にできる) 問題に限定されるはず
669:デフォルトの名無しさん
08/08/31 15:47:12
計算資源が有限なため、howが分からないとwhatも記述できないという罠
670:デフォルトの名無しさん
08/08/31 15:59:09
本質的には what -> how の書き換えと how -> how の最適化は似たようなもんだからな。
最適化は手続き型でもやってるから、非手続き型の人はwhatの部分を強調してみたりC/C++より速くなると言ってみたり。
LLの人は最適化にあまり拘らないし、テストさえ通ればhowを直接書いてもいいやって感じだけど。
671:デフォルトの名無しさん
08/08/31 17:18:22
>>667
>>600前後の流れ参照
要するに未評価の式(これはクロージャで実装されてる)を溜め込まないように注意する必要がある
672:デフォルトの名無しさん
08/08/31 20:51:42
しかし、そんなこと言ってたらprologだって宣言型と言えなくなるんじゃない?
673:デフォルトの名無しさん
08/08/31 21:42:38
お前らは
人間の性格はA型B型O型AB型の4種類に分けることができる
とか思ってそうだよな。
674:デフォルトの名無しさん
08/08/31 23:36:24
なんでも過不足なく分類できると思い込む愚かさ
血液型と性格をろくな検証なしに簡単に結びつけてしまう短絡さ
どっちをさしてるのか紛らわしいので例としては不適
675:デフォルトの名無しさん
08/09/01 01:06:10
>>674
おもしろおかしい
676:デフォルトの名無しさん
08/09/01 07:57:32
URLﾘﾝｸ(www.realworldhaskell.org)
書き終わったって。
677:デフォルトの名無しさん
08/09/01 15:40:49
zipで(ry
678:デフォルトの名無しさん
08/09/02 14:15:50
>>666 プ
試しにZあたりの実行系でもつくってみればw
679:デフォルトの名無しさん
08/09/02 17:56:25
>>678
何が言いたいのははっきり言え。
小馬鹿にするだけでは情報価値ゼロだぞ。
680:デフォルトの名無しさん
08/09/03 08:50:51
述語論理なめんな、ってことじゃね？
せめてホーン論理に限定するとかじゃないと話にならんだろ。
681:デフォルトの名無しさん
08/09/03 23:53:10
関数とKleisli以外のメジャーなArrowってあるの？っていうかArrowって死滅したの？
682:デフォルトの名無しさん
08/09/04 00:04:13
>>676
おお！でも英語疲れる。訳書出版の予定はないの？
683:デフォルトの名無しさん
08/09/04 01:25:52
>>681
死滅しそうなのはHaskellだが、新しいHaskellのライブラリはほとんどArrowベースだよ。
684:デフォルトの名無しさん
08/09/04 11:41:24
このスレって嘘多いよな。
685:デフォルトの名無しさん
08/09/04 12:00:02
このスレって～
ってレス多いよな。
686:デフォルトの名無しさん
08/09/04 15:00:58
そういえば、大学入試のときに大学ランクとタバコの関係に気づかされたなぁ・・・
東大 誰も吸っていない
京大 誰も吸っていない
同志社大 ちらほら
関西大 校舎内で吸っているやつがいる（！！！）
ありえないです、低ランク大・・・
やっぱりランクの低い大学出身のやつは信用できない・・・
687:デフォルトの名無しさん
08/09/04 15:19:00
そして増える意味不明なレス
688:デフォルトの名無しさん
08/09/04 15:20:04
>>684
素人なのでどの変がうそなのか教えてください
689:デフォルトの名無しさん
08/09/04 15:45:52
６８６みたいな奴がhaskellを使うとはとても思えんのだが、
何しに来てるのかね？
690:デフォルトの名無しさん
08/09/04 15:50:35
>>689
Haskellがどういうものだと思っているんですか？
691:デフォルトの名無しさん
08/09/04 17:36:25
>>686は今マルチされてるコピペ、スルー推奨です。
692:デフォルトの名無しさん
08/09/04 19:33:03
>>690
全角数字を見るといらっとくる人が使う言語
693:デフォルトの名無しさん
08/09/04 19:35:16
確かにイラっときた
694:デフォルトの名無しさん
08/09/04 21:21:38
>>６９３
それはカルシウム不足
695:デフォルトの名無しさん
08/09/06 23:15:53
Haskellで良いコード綺麗なコードというのはどんなコードですかね。
出来るだけ変数使わない方がいいとか、何が何でもポイントフリーにするとか、
あるいはそれ以外でも、何でも。
696:デフォルトの名無しさん
08/09/06 23:55:28
>>695
y f = f (y f)
697:デフォルトの名無しさん
08/09/07 00:05:33
>>695
haskellでは数学的にきれいなコードが「きれいなコード」と呼ばれます。
698:デフォルトの名無しさん
08/09/07 00:12:32
良いコード:
意味のあるところでControl.*を使う
悪いコード:
ポイントフリーのためにControl.ApplicativeやControl.Arrowをimport
699:デフォルトの名無しさん
08/09/07 00:15:18
っていうか、ポイントフリーってなにがいいの？せっかくパターンマッチがあるのに。
>>687
ライブラリはそうだろうけど、普通のアプリを書くときは？
700:デフォルトの名無しさん
08/09/07 00:33:20
単純な場合には無駄に変数が増えず、シンプルに分かりやすくなるから良い。
複雑な場合には無理をしても分かりにくくなるだけだから悪い。
パターンマッチとは使いどころが違う。
701:デフォルトの名無しさん
08/09/07 00:34:19
>>699
圧倒的に短く書けるからだよ。
それにポイントフリーだと関数の入出力の流れみたいなのがまっすぐ表せるから、処理の全貌が見通しやすい
702:デフォルトの名無しさん
08/09/07 00:41:52
まっすぐだけど、流れが逆じゃん。
というわけで>>>使うのはやっぱダメ?逆なのに脳味噌合わせるべきなの?
703:デフォルトの名無しさん
08/09/07 00:46:48
GUIアプリを書くときはどういうのが綺麗なんだ？
704:デフォルトの名無しさん
08/09/07 00:59:26
>>702
逆なの？ y = f x より x f = y が脳味噌に合ってるの？
705:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/09/07 01:12:53
>>705
あ、前半がStringに戻してないのはご愛敬と言う事で、よろしく。
707:デフォルトの名無しさん
08/09/07 01:32:55
>>705
String に戻さないといけないなら
filter ((10 <) . read) だろう。ラムダでもいいけど。
まあ、その辺はこだわるとこでもないかと。
> なんでやねん。
f (g x) と (f . g) x の向きは関係あるんですよ。
数学でも向き的事情から x^f という記法を使うこともある。
708:デフォルトの名無しさん
08/09/07 02:23:43
>>702
左から右だろうが右から左だろうがどっちでも一緒だろ。
俺には違いが分からん。
709:デフォルトの名無しさん
08/09/07 02:27:05
>>702
こういう反抗したい年頃のやつが言語を汚くしていくんだろうな。
なんでもないものを指差して「使いにくい」などと言ったり、まるでガキ。
710:デフォルトの名無しさん
08/09/07 03:31:39
現代日本では横書き文字は左から右だから、
その方が自然に感じるのは当然と思います。
また、bind演算子が(>>=)で左結合である事を考えても
Haskellを設計した人もその方が自然と感じたのではないでしょうか？
慣れの問題かもしれませんが、
そんなにおかしな意見とは思えません。
711:デフォルトの名無しさん
08/09/07 07:34:52
まあ関数合成の向きが右から左なのは>>707の説明の通りだし、Haskellに限らず数学でも同じルールだからな。数学でも気持ち悪いって云う人は結構居るしまあそんなに変わった意見でもあるまい。
712:デフォルトの名無しさん
08/09/07 21:48:37
社内コーディング規約でここにスペースを入れろとかそういうのよりは高尚が感じがするかもしれないけれど
所詮バイクシェッド
乱用すれば読みにくいし、パズルみたいにポイントフリーするのは間違ってる
数学的に綺麗綺麗とか、圏論的に自然とかというけれど、誰でも圏論がわかるわけじゃないし。
しかし、いかにポイントフリーで書くか、という事を考えると確かにおもろいよ
713:デフォルトの名無しさん
08/09/07 21:56:43
亀だが
>>36
>FPGAとかのHDL記述とかに応用したりしてる人いないの？
Lavaがあるよ。並列性とか関係ないし、回路をそのまま関数で書くだけなんだけど。そしてVerilogより使いやすい、なんてこたーない。HDLよりましだが、副作用を書くのがまわりくどい
URLﾘﾝｸ(www.cs.chalmers.se)
714:デフォルトの名無しさん
08/09/07 22:31:52
s/HDL/VHDL/
715:デフォルトの名無しさん
08/09/08 21:55:12
>>713
ArrowっぽいHDL作りたいな
716:デフォルトの名無しさん
08/09/09 18:48:21
Real World Haskell
November 15, 2008
待ち遠しい。
717:デフォルトの名無しさん
08/09/12 22:50:22
過度の並列化で複雑化するゲーム開発
コスト削減の鍵は純粋関数型言語らしい
URLﾘﾝｸ(www.watch.impress.co.jp)
718:36 ◆K0BqlCB3.k
08/09/12 22:54:50
>>717
そうだろうね。
俺はずううっと前からそう論文に書いてたけど。
だんだんpi-calculusの人気が出てきたね。
719:デフォルトの名無しさん
08/09/12 23:58:55
> Sweeney氏は純粋関数型言語のもつ並列処理安全性に着目しており、
>将来的にゲームプログラミングはそういった処理系に移行していくべきだとした。
>Sweeney氏はそのひな形として言語“Haskel”を挙げているが、
>ゲーム開発のメインストリームたり得る言語はまだ登場しておらず、将来に期待しているという。
なんでHaskellは駄目なんだろう。
ライブラリ含めた開発環境の問題か処理系の最適化の問題か
それとも言語仕様レベルで本質的に向いていないのか。
720:デフォルトの名無しさん
08/09/13 00:06:19
前者じゃない？
721:デフォルトの名無しさん
08/09/13 00:09:07
こんなことでもないと注目せんのだな
722:デフォルトの名無しさん
08/09/13 00:48:51
遅延評価に漬かりまくりで、ダメなのでは？
遅延評価って言ってみれば、後ろからの逐次でそ？
無限リスト使えないHaskellってHaskell？
723:デフォルトの名無しさん
08/09/13 07:07:42
LazyがいやならSMLやOCAML使えばいいだけ。何が不足よ？
724:デフォルトの名無しさん
08/09/13 08:23:12
>>723
前方参照，where構文
725:デフォルトの名無しさん
08/09/13 09:32:44
>>724
LETで何が不足よ？
726:デフォルトの名無しさん
08/09/13 10:42:16
>>717,>>719からのコンテキストを読んでくれよ。
727:デフォルトの名無しさん
08/09/15 18:14:08
質問です
たとえばJavaなどではクラスのインスタンスをオブジェクトと呼びますが、
Haskellの代数的データ型に格納されたデータのことをなんと呼べば良いですか？
728:デフォルトの名無しさん
08/09/15 18:21:45
>>727
関数
729:デフォルトの名無しさん
08/09/15 19:00:09
>>727
「オブジェクト」に対応する用語は普通は「値」でいいんじゃないか
>Haskellの代数的データ型に格納されたデータ
これどういう意味？
型が代数的データ型であるような値のことならそのまま「代数的データ型の値」
代数的データ型の構築子に渡した値のことなら「フィールドの値」くらいか？
data Point = Pt Int Int
x = Pt 0 3
-- xはPoint型の値
-- xのフィールドの値は0と3
730:デフォルトの名無しさん
08/09/15 20:26:27
Haskellのプログラミングスタイルのことはなんて呼べばいいですか？
ストリーム指向？
731:デフォルトの名無しさん
08/09/15 20:30:20
関数指向
732:デフォルトの名無しさん
08/09/16 23:55:40
Haskell系のShellでオススメってある？
733:36 ◆K0BqlCB3.k
08/09/17 00:00:30
>>732
シェルって何のこと？
言語とは関係ないと思うけど。
シェルスクリプトのことを言っているの？
734:デフォルトの名無しさん
08/09/17 00:07:44
>>733
HSHみたいなやつ
探してみた奴だとどれも開発止まってて…
735:デフォルトの名無しさん
08/09/17 00:09:07
Haskell風構文のシェルっていくつかあるんだな、ググって初めて知ったわ
736:デフォルトの名無しさん
08/09/17 00:15:11
Haskell系の自然言語でオススメってある？
737:デフォルトの名無しさん
08/09/17 00:22:13
lojbanとか？
自然言語じゃないけど
738:デフォルトの名無しさん
08/09/17 15:52:29
Yiとか使ってる人いるの？
739:デフォルトの名無しさん
08/09/17 17:56:30
Yi って 彝 ?
740:デフォルトの名無しさん
08/09/17 18:20:56
ぅぃ？
741:デフォルトの名無しさん
08/09/17 18:31:27
URLﾘﾝｸ(haskell.org)
使ったこと無いなぁ。
742:デフォルトの名無しさん
08/09/19 17:29:49
ひょんなことからerlangを勉強し始めたが、構文はともかく、思想としては面白いな。
並行指向プログラミングというのかな？
このパラダイムはオブジェクト指向よりも現実志向のパラダイムのように思う。
Haskellでも並列化がうまくいけばerlangみたいな仕組みを実装できるかもしれない。
# erlangの構文は糞 糞 糞 糞杉
743:デフォルトの名無しさん
08/09/19 18:18:31
ぅぃゅ
744:デフォルトの名無しさん
08/09/19 20:28:25
コンカレントハスケル？
745:デフォルトの名無しさん
08/09/19 20:34:40
ああ、コンカレントは並行だったか・・・
746:デフォルトの名無しさん
08/09/20 11:00:42
>>743
私はProlog屋なので、erlangの構文のクソ部分に敏感でない。
お手数かけて恐縮だが、糞の部分を列挙していただけると有難いのだが。
747:a36 ◆K0BqlCB3.k
08/09/20 12:04:07
>>742
たぶん、その思想というのはpi-calculusのことかな。
748:デフォルトの名無しさん
08/09/20 13:08:03
ここのみんなからするとgtk2hsって綺麗なの？
749:デフォルトの名無しさん
08/09/20 13:29:19
Erlangってpi-calculusベースなのか
750:デフォルトの名無しさん
08/09/20 13:56:48
>>746
743ではないけど、
receive...endとか、カリー化できないとかではないですか?
751:デフォルトの名無しさん
08/09/20 14:52:33
>>723
元記事ではSTMが挙げられてるけど、OCamlだと無くね？
>>749
綺麗って何が？Gtk2Hsを使ったコード？
それならあまり綺麗じゃないんじゃない。
GUIを綺麗に書くためのハイレベルなライブラリは
いろいろあるけど、どれも決定打にはなってないような。
752:デフォルトの名無しさん
08/09/20 15:23:34
>>751 >>749 じゃなくて >>748 ?
753:デフォルトの名無しさん
08/09/20 15:27:39
>>752
>>748な俺からでもそれはわかる。
754:デフォルトの名無しさん
08/09/21 00:46:57
gtk2hsと言えば、
gtk_rc_parse_string相当の関数や、
gtk_widget_modify_cursor（これは新しいからか）相当の関数が見付からなくて諦めたことがあります。。
いや私の検索能力が低いだけだと思うんですが、かなり頑張ってもどうしても見つかりませんでした。。。
皆さんgtkやpango、gdkの関数を捜すときってやっぱり根性ですか？
大抵はキャメルケースにすれば大丈夫ですがそうでない時はかなり困りますよねー。。
755:デフォルトの名無しさん
08/09/21 12:17:25
いや、検索能力の問題じゃなくて、実際に無いんじゃない？
Gtk2Hsのソースgrepしてみて無かったら無いような。
756:デフォルトの名無しさん
08/09/22 08:20:06
webで読んでるけどreal world haskell凄いヴォリュームだな
一週間やってもまだ終わらん
製本版はもう鈍器レベルだな
757:デフォルトの名無しさん
08/09/22 09:55:41
なにか面白いこと書いてあった？
758:a36 ◆K0BqlCB3.k
08/09/22 15:02:13
これでしょ
URLﾘﾝｸ(book.realworldhaskell.org)
759:デフォルトの名無しさん
08/09/22 16:29:27
url知らないって意味じゃなくて、自分では読む気が無いってことだよ。
760:a36 ◆K0BqlCB3.k
08/09/22 16:37:06
ぱっと見た感じでは、名前の通り実際にHaskellで開発する時に「背中に手が届く」本になってる感じ。
たとえばデータベースと通信する方法とか、
GUIを作るときのライブラリとかツールとかの紹介とか、
どちらかというと「Haskell逆引きクイックリファレンス」
みたいな感じだね。
目新しいことは何もないけど、逆引きリファレンスとしてはいろんなライブラリとか紹介されていて便利かな。
761:a36 ◆K0BqlCB3.k
08/09/22 16:39:11
いろいろサンプルコードも載ってるからわかりやすい。
文章の良よりコードの両方の方が多いから英語が苦手な人でもわかると思う。
762:a36 ◆K0BqlCB3.k
08/09/22 16:39:49
良 → 量
コードの両方 → コードの量
763:デフォルトの名無しさん
08/09/24 11:57:39
Parsec.Tokenをロードすると
ERROR file:{Hugs}\packages\parsec\Text\ParserCombinators\Parsec\Token.hs:64 - Syntax error in data type declaration (unexpected `.')
とでて読み込めないのですがどうしたらいいのでしょうか
764:デフォルトの名無しさん
08/09/24 12:09:05
>>763
Hugsを標準モードじゃなくて拡張モードで起動すればいい
hugs -98
765:デフォルトの名無しさん
08/09/24 12:51:18
>>764
無事読み込めました。ありがとうございます
766:デフォルトの名無しさん
08/09/24 15:23:46
do構文で、変数の使用が強制されるのはなんとかならんの？
.とか$とかの気の利いたバージョンない？
767:デフォルトの名無しさん
08/09/24 15:27:56
何を言ってるのかよく分からんが >>= とか？
768:デフォルトの名無しさん
08/09/24 15:36:59
>>=だけですっきりいけるならdo構文使わないでしょ(ってこともないか？少なくとも俺は)。
do構文でモナドを「外す」ためだけに一時変数がやたら必要になるのがイヤって話。
つまるところ>>=になっちまいそうな気もするけど、
便利な演算子なり特殊なカッコなりで、無駄な変数使わずに何とかならんかなぁ、と。