関数型プログラミング言語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の仕様により、行頭の半角スペースは表示されません。 　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。 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. って書いてあるペーパーを見付けました、その継続ベースの方法について考えながら考えていこうと思います。 649 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 18:52:43 ] www.cs.chalmers.se/~augustss/AFP/monads.html でしょ 650 名前：デフォルトの名無しさん mailto:sage [2008/08/26(火) 19:00:04 ] >>649 そうです、でもこれだけ読んでもこれで何がしたいのか俺には正直よく分かりませんな。。 例がなくても理論だけ聞けば全て分かるタイプの人なら大丈夫なのかもしれませんが。 651 名前：デフォルトの名無しさん mailto:sage [2008/08/28(木) 06:47:20 ] >>648 P みたいなのを継続ベースともいうけど、 ReadP を使うのは純粋に効率のためで、 そこに書いてあるのとは話が違うような。 652 名前：デフォルトの名無しさん mailto:sage [2008/08/28(木) 11:12:38 ] > 純粋に効率のためで そう単純化されても… 653 名前：デフォルトの名無しさん mailto:sage [2008/08/28(木) 14:48:42 ] いや、単純だし… 654 名前：デフォルトの名無しさん mailto:sage [2008/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で使える。 www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/2006/Papers/parser-claessen.pdf ここにも効率がって書いてあるけどどんな場合なのかさっぱりだ。。 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 ] 単純な場合には無駄に変数が増えず、シンプルに分かりやすくなるから良い。 複雑な場合には無理をしても分かりにくくなるだけだから悪い。 パターンマッチとは使いどころが違う。

---

---

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

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