関数型プログラミング言語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の仕様により、行頭の半角スペースは表示されません。 　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。 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 ] 単純な場合には無駄に変数が増えず、シンプルに分かりやすくなるから良い。 複雑な場合には無理をしても分かりにくくなるだけだから悪い。 パターンマッチとは使いどころが違う。 701 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:34:19 ] >>699 圧倒的に短く書けるからだよ。 それにポイントフリーだと関数の入出力の流れみたいなのがまっすぐ表せるから、処理の全貌が見通しやすい 702 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:41:52 ] まっすぐだけど、流れが逆じゃん。 というわけで>>>使うのはやっぱダメ?逆なのに脳味噌合わせるべきなの? 703 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:46:48 ] GUIアプリを書くときはどういうのが綺麗なんだ？ 704 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 00:59:26 ] >>702 逆なの？ y = f x より x f = y が脳味噌に合ってるの？ 705 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 01:11:04 ] >>704 なんでやねん。 unlines . take 10 . filter (> 10) . map read . lines より、 lines >>> map read >>> filter (> 10) >>> take 10 >>> unlines の方が、少なくとも俺は脳に優しく感じる。 で、こう書くと、map read と filter (> 10) を分けてるのが冗長でダサい気もするが、 (filter (> 10).read)みたいにした方が良いのか、かえってこっちの方がダサいのか、 あるいは、(filter (\x -> 10 > read x)) みたいにラムダにすべきなのか、綺麗の勘所が判らんのです。 706 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 01:12:53 ] >>705 あ、前半がStringに戻してないのはご愛敬と言う事で、よろしく。 707 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 01:32:55 ] >>705 String に戻さないといけないなら filter ((10 <) . read) だろう。ラムダでもいいけど。 まあ、その辺はこだわるとこでもないかと。 > なんでやねん。 f (g x) と (f . g) x の向きは関係あるんですよ。 数学でも向き的事情から x^f という記法を使うこともある。 708 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 02:23:43 ] >>702 左から右だろうが右から左だろうがどっちでも一緒だろ。 俺には違いが分からん。 709 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 02:27:05 ] >>702 こういう反抗したい年頃のやつが言語を汚くしていくんだろうな。 なんでもないものを指差して「使いにくい」などと言ったり、まるでガキ。 710 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 03:31:39 ] 現代日本では横書き文字は左から右だから、 その方が自然に感じるのは当然と思います。 また、bind演算子が(>>=)で左結合である事を考えても Haskellを設計した人もその方が自然と感じたのではないでしょうか？ 慣れの問題かもしれませんが、 そんなにおかしな意見とは思えません。 711 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 07:34:52 ] まあ関数合成の向きが右から左なのは>>707の説明の通りだし、Haskellに限らず数学でも同じルールだからな。数学でも気持ち悪いって云う人は結構居るしまあそんなに変わった意見でもあるまい。 712 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 21:48:37 ] 社内コーディング規約でここにスペースを入れろとかそういうのよりは高尚が感じがするかもしれないけれど 所詮バイクシェッド 乱用すれば読みにくいし、パズルみたいにポイントフリーするのは間違ってる 数学的に綺麗綺麗とか、圏論的に自然とかというけれど、誰でも圏論がわかるわけじゃないし。 しかし、いかにポイントフリーで書くか、という事を考えると確かにおもろいよ 713 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 21:56:43 ] 亀だが >>36 >FPGAとかのHDL記述とかに応用したりしてる人いないの？ Lavaがあるよ。並列性とか関係ないし、回路をそのまま関数で書くだけなんだけど。そしてVerilogより使いやすい、なんてこたーない。HDLよりましだが、副作用を書くのがまわりくどい www.cs.chalmers.se/Cs/Grundutb/Kurser/svh/tools.html 714 名前：デフォルトの名無しさん mailto:sage [2008/09/07(日) 22:31:52 ] s/HDL/VHDL/ 715 名前：デフォルトの名無しさん mailto:sage [2008/09/08(月) 21:55:12 ] >>713 ArrowっぽいHDL作りたいな 716 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 18:48:21 ] Real World Haskell November 15, 2008 待ち遠しい。 717 名前：デフォルトの名無しさん mailto:sage [2008/09/12(金) 22:50:22 ] 過度の並列化で複雑化するゲーム開発 コスト削減の鍵は純粋関数型言語らしい www.watch.impress.co.jp/game/docs/20080911/epic.htm 718 名前：36 ◆K0BqlCB3.k mailto:sage [2008/09/12(金) 22:54:50 ] >>717 そうだろうね。 俺はずううっと前からそう論文に書いてたけど。 だんだんpi-calculusの人気が出てきたね。 719 名前：デフォルトの名無しさん mailto:sage [2008/09/12(金) 23:58:55 ] >　Sweeney氏は純粋関数型言語のもつ並列処理安全性に着目しており、 >将来的にゲームプログラミングはそういった処理系に移行していくべきだとした。 >Sweeney氏はそのひな形として言語“Haskel”を挙げているが、 >ゲーム開発のメインストリームたり得る言語はまだ登場しておらず、将来に期待しているという。 なんでHaskellは駄目なんだろう。 ライブラリ含めた開発環境の問題か処理系の最適化の問題か それとも言語仕様レベルで本質的に向いていないのか。 720 名前：デフォルトの名無しさん [2008/09/13(土) 00:06:19 ] 前者じゃない？ 721 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 00:09:07 ] こんなことでもないと注目せんのだな 722 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 00:48:51 ] 遅延評価に漬かりまくりで、ダメなのでは？ 遅延評価って言ってみれば、後ろからの逐次でそ？ 無限リスト使えないHaskellってHaskell？ 723 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 07:07:42 ] LazyがいやならSMLやOCAML使えばいいだけ。何が不足よ？

---

---

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

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