ttp://www.haskell.org/
日本語サイト
ttp://www.sampou.org/cgi-bin/haskell.cgi
ttp://www.shido.info/hs/
過去ログ
関数型プログラミング言語Haskell
Part1 ttp://pc.2ch.net/tech/kako/996/996131288.html
Part2 ttp://pc2.2ch.net/test/read.cgi/tech/1013846140/
Part3 ttp://pc8.2ch.net/test/read.cgi/tech/1076418993/
Part4 ttp://pc8.2ch.net/test/read.cgi/tech/1140717775/
Part5 ttp://pc8.2ch.net/test/read.cgi/tech/1149263630/
Part6 ttp://pc11.2ch.net/test/read.cgi/tech/1162902266/
Part7 ttp://pc11.2ch.net/test/read.cgi/tech/1174211797/
Part8 ttp://pc11.2ch.net/test/read.cgi/tech/1193743693/
Part9 ttp://pc11.2ch.net/test/read.cgi/tech/1211010089/
Part10 ttp://pc12.2ch.net/test/read.cgi/tech/1231861873/
Part11 ttp://pc12.2ch.net/test/read.cgi/tech/1252382593/
Part12 ttp://hibari.2ch.net/test/read.cgi/tech/1272536128/
Part13 ttp://hibari.2ch.net/test/read.cgi/tech/1286706874/
Part14 ttp://hibari.2ch.net/test/read.cgi/tech/1299385928/
Part15 ttp://hibari.2ch.net/test/read.cgi/tech/1310199414/
Part16 ttp://toro.2ch.net/test/read.cgi/tech/1317958045/
・Introduction to Functional Programming Using Haskell (2nd ed.)
ttp://www.amazon.co.jp/exec/obidos/ASIN/0134843460/
・Haskell: The Craft of Functional Programming
ttp://www.amazon.co.jp/exec/obidos/ASIN/0201342758/
・The Fun of Programming
ttp://www.amazon.co.jp/exec/obidos/ASIN/0333992857/
・The Haskell School of Expression: Learning Functional Programming Through Multimedia
ttp://www.amazon.co.jp/exec/obidos/ASIN/0521644089/
・入門Haskell
ttp://www.amazon.co.jp/exec/obidos/ASIN/4839919623/
・ふつうのHaskellプログラミング
ttp://item.rakuten.co.jp/book/4052963/
・Programming in Haskell
ttp://www.amazon.co.jp/exec/obidos/ASIN/0521692695/
・Real World Haskell
ttp://www.amazon.co.jp/exec/obidos/ASIN/0596514980
・関数プログラミングの楽しみ
ttp://www.amazon.co.jp/exec/obidos/ASIN/4274068056
東京にある6つのキー局の内、製作から財務まで一貫して朝鮮人が行ってるテレビ局が1つ
中国共産党から毎年大量の反日工作費が流れているテレビ局が2つ
もろに北朝鮮と繋がっているテレビ局が1つ
年寄はまだまだテレビという外国人に騙され続ける
・GHC Wiki
ttp://hackage.haskell.org/trac/ghc/wiki/TitleIndex
・A History of Haskell
ttp://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/
・関数型関連の用語集
ttp://sky.zero.ad.jp/~zaa54437/programming/concepts/
・本物のプログラマはHaskellを使う
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060915/248215/?ST=ittrend
・Haskell API search Engine
ttp://www.haskell.org/hoogle/
【簡単な使い方】
１．検索バーに関数名を入れて検索
例 map
２．検索バーに型名を入れて検索
例 (a -> b) -> [a] -> [b]
http://book.realworldhaskell.org/read/
Learn You a Haskell for Great Good!
http://learnyouahaskell.com/chapters
あれから新しい本も仲間入りしたし、新版も出たから、追加しとくわ
・Haskell: The Craft of Functional Programming (3rd ed.)
http://www.haskellcraft.com/craft3e/Home.html
http://www.amazon.co.jp/dp/0201882957/
・Learn You a Haskell for Great Good!
http://learnyouahaskell.com/
http://www.amazon.co.jp/dp/1593272839/
>関数型言語って、スパゲティになりやすい。
>宣言的で１つ１つ完結しているから理解しやすいとか馬鹿が言うけど、
>実際には宣言的だからこそスパゲッティコードになる。
モナドの観点からは、これに対してどう答えるんだろか？
脳内では結論決まってんだろ？
先ほども言ったが、スパゲッティというのは実行順序や計算順序が複雑に絡まること
（ここで言う絡まるというのは、解の導出過程を追うとコード上を脈絡無く飛び交ってしまうこと）
完全に宣言的なものには解を導くのに計算順序という概念がない
だから、順序があるのはそれが手続き的な面を少なからず持ってるからだ
（完全に宣言的なもの、HTML や Alloy の記述などはもうプログラムとは呼べないと俺は思う）
Haskellの持つ宣言的な性質は、例えば、参照透過性ゆえに
関数をどこで使用しても同じ結果が得られることに現れている
しかしHaskellだって完全に宣言的ではないから、
計算順序をしっかり意識しないといけないケースがある
ただその場合も、順序を意識して計算を追うのはCやJavaなどよりも楽になるケースが多い
関数をどこで使用しても同じ結果が得られると言うことは、
その結果を知っているなら、それ以上その先深く計算を追う必要が無いからだ
そしてその結果を知る事も比較的容易だ
関数の結果が引数以外の外部環境（変化するクラスのメンバ変数など）に依らないから、
単に計算対象の値に問題の関数を適用して結果を調べればいいだけ（内部計算は知る必要が無い）
実際問題として、Haskellのプログラミングは正直なところ言うほど単純ではないが、
それでもそのようなHaskellの持つ宣言的な性質の部分を大いに活用できるから、
手続き寄りなCやJavaなどよりも理解しやすいと言われるし、俺もそう感じる
手続きの意味を明確にするべくデザインされたものが「スパゲティになる」とか、
意味不明の主張だと思うな。
本当にHaskellでプログラム書いたことある？
Haskellで実用的プログラミングをしたら、計算順序を意識せずにはいられないよ。
lazyゆえにどれだけメモリリークが発生しやすくなっていると思う？
計算順序のチューニングなしにどうやってメモリリークに対処するんだ？
「計算順序とか関係なく、各宣言を独立に扱える」とか綺麗事ってるうちはいいが、
ひとたびリアルタイムなレスポンスを要求されたり、
長時間メモリリークなしに継続的に動作することを要求されたら
どれだけスパゲッティと格闘しなければならないか、理解してるか？
構造化による問題の局所化ができないのだから、スパゲッティーと言っていいな。
>（完全に宣言的なもの、HTML や Alloy の記述などはもうプログラム
とは呼べないと俺は思う）
プログラムと呼ぼうと呼ぶまいと、やることができれば、それが一番
いいんじゃないの？
しかし完全に宣言的ってあり得るか？
もちろん日常的にHaskellでプログラムを書いている
実用的かどうかはそのアプリケーションを利用する環境に依るから何とも言えん
ただ、私（たち）が社内用に作ったアプリケーション、たとえば
意思決定支援システムのようなものは社員達に活用していただいている
ユーザーや外部環境とアルタイムにコミュニケーションするアプリケーションも作ってる
Haskellも計算順序を意識する必要があるケースがあると言ったはず
私はその計算順序がスパゲティになりにくいと言った
少なくとも私（たち）の作るアプリケーションの類では、
遅延性が原因のメモリリークは、C などのより厄介なメモリリークよりも潰しやすい
正確に言えば、アプリケーションの運営に問題にならない程度にまで潰すのは
C などに比べて用意であることの方が圧倒的に多い
申し訳ないが、こればかりは普段皆さんがどれとぼメモリリークを気にしているのか知らない
完全にゼロになる（どういう状態がメモリリークゼロと言えるのかも知らんが）まで、
ひたすら潰し続けるということを私は仕事でやったことがないから
もしかしたら、24時間356日正しく動き続けることが求められるアプリケーションでは、
遅延性が原因のメモリリークはとても厄介な存在かも知れん
逆に貴方はHaskellでどのようなアプリケーションを作った時に、
どのような部分に遅延性が原因のメモリリークが発生し、
それをどれくらい潰そうとして、それとどのように格闘して解決したのか、
ぜひ訊かせていただけないだろうか
すまん
> 私はその計算順序がスパゲティになりにくいと言った
なりにくいとは言ってないな（頭にはあったが、言葉にはしていなかった）
計算順序を追うのがCなどに比べて楽になるケースが多いと言った
>>15 は君のような大馬鹿ではないから、
そういう計算順序を言っているのではないと思うぞ
その計算のどこにメモリリークが発生する余地がある？
>もちろん日常的にHaskellでプログラムを書いている
>意思決定支援システムのようなものは社員達に活用していただいている
うーん。Haskellだろうとそれは大変だろ。
あんた以外がメンテすることはできるの？
私（たち）と書いた
今は私含めて４人でプログラムして同じ４人でメンテしてる
社内ツール専門の部署だ
なるほど。
やろうと思えば１人でもできるのか？
意思決定支援か。こっちも似ていて、機械学習系のシステム。
大規模行列を扱う時にメモリに抱え込む実装になっている。
サーバプロセスとして実装したから、24-365まではいかないが、
数ヶ月は走り続ける必要がある。
大変だったのは、サーバプロセスのメモリリークかな。
行列への書き込みからメモリリークを取るのは簡単な話だが、
サーバプロセスとして継続的に走り続けるから、
障害回復のためのジャーナルへの書き出しとか、
サーバプロセスに付随する色々な処理に非正格な処理が混ざると
メモリリーク祭りになる。
もちろんCで実装するのに比べれば対処は容易だ。
でもそれはGCの恩恵であって、lazyさや参照透明の恩恵とは違う。
GC付きのOOPLのほうが単純に実装できるかもしれない。
証券系でMLが好まれるのは、そのあたりが理由かもしれんと思った。
制作時の話なら、作るアプリケーションの規模と、かけられる時間と、
私の今の知識や経験の量による
メンテの話なら、私（たち）が仕事で作ったツールのソースは、私一人でもできる
４人でメンテしてると言っても、そのつど責任者をゲームで一人決めて（押しつけて）、
その人がメインでメンテ、あとの３人は時々サポートするくらいだから
>>15
それはそうと、「計算順序とか関係なく、各宣言を独立に扱える」
本当にそんなことを言っているHaskellプログラマはちょっと問題がある
俺のことを指摘したのなら勘違いだろ、そもそも俺はそんなことは言ってない
「各宣言を独立に扱える」事を臭わすような発言はしたし
事実そういう利点を常に意識しているが、
それが「計算順序と関係なく」できるとは全く思っていない
計算順序はちゃんと意識しないとデバッグ時に計算が追えない
が、「各宣言を独立に扱える」ことにより、計算を追うデバッグの仕事が
Cなどに比べて楽になる、という意味の発言はした（理由も言った）
デバッグにおいて、「各宣言を独立に扱える」ことの別の利点もある
一連の計算に利用するそれぞれの関数を独立してデバッグできる
その関数の規模が小さいほど、みんなでデバッグしやすい（私たちは4人でデバッグしてる）
あまりよく知らないんだが、実用システムではメモリリークってそんな
に問題なのか？
それと比べると、lazyさや参照透明の恩恵は実感としてどのくらいなんだ？
では私と扱っている分野が違うのだろう
私はそのような走り続けるアプリーションをHaskellで作った経験がゼロなので、
私（たち）のアプリで実感したHaskell利点が、貴方のタイプのアプリでも通用するのか、
全く分からない（いずれ必要になった時には当然検証するが）
申し訳ないが、私は私の経験でしかHaskellの利点や欠点を語れない
そちらの分野は私の勉強不足だ
分野が違うことによる意見の相違のようなので、
私はもうこの辺りでフェードアウトしたい
そこで言う関数の規模とは、一体どういう意味での規模なのか。
俺自身が触ってきたコードから言うと、
筋のいいOOライブラリのメソッドと関数型言語の関数定義は
同じぐらいの粒度だと思う。行数も同程度。もちろんJavaじゃないぞ。
面白い述懐だな。宣言性、計算順序性、独立性、関数規模、デバッグ容易性･･･
「各宣言を独立に扱える」というのは、｢関数間にまたがってまで計算順序を
意識する必要がない｣とようないう意味だね？
その筋のいいOOライブラリが何なのか教えてください
> ｢関数間にまたがってまで計算順序を意識する必要がない｣とようないう意味だね？
こちらこそ、なるほどなと思わせる解釈だが、私の言いたかったことは半分正解
当然ながら計算を追うには複数の関数を跨がないといけない
関数Ａの中で関数Ｂと関数Ｃを使っていたら、
関数Ａの最終的な値が「計算される仕組み＝計算過程」を知るには
関数Ｂも関数Ｃも計算を追わないと絶対にわからない
ただ、関数Ｂや関数Ｃは（関数Ａのlet節やwhere節で宣言されたものでないかぎり）
普通は関数Ａの環境からは独立しているはずだ
もちろん互いの環境とも独立しているはず
であれば、関数Ｂの計算は、関数Ｃの計算とは全く関係ないはずだ
参照透過性ゆえに「自動的に」そうならざるをえない
なので、たとえば関数Ｂのデバッグは関数Ｃとは独立して行える
これが「各宣言を独立に扱える」ということ
関数Ａの計算過程を追うには関数Ｂや関数Ｃを跨ぐ必要があるが、
関数Ｂや関数Ｃの計算過程を追うには関数間をまたぐ必要がない
だから（私が言いたかったことに関しては）半分正解
ちなみに、関数Ｂの戻り値に関数Ｃを適用すればまたがるだろという意見もあろうが、
それでも関数Ｃを計算する仕組みは変わらない
関数Ｃを引数の値によって計算そのものを変える事もできてしまうが、
そこまで行くと筋の悪るすぎるHaskellプログラムだから論外だ
・参照透明性はすばらしい
・遅延評価は糞
ということでよろしいか
> そこで言う関数の規模とは、一体どういう意味での規模なのか。
期待させたのなら申し訳ないが、大した意味は全く無い
言葉が足りなかったな
その関数の規模が小さいほど、みんなで「そろって」デバッグしやすい
というニュアンスで言いたかったんだ
貴方がOOの例で言った関数の規模ときっと同じ意味だ
中でどれほど長い式の計算をしているか、という程度の曖昧な意味だよ
一つの関数内で where 節などでたくさん内部関数を宣言してたりして式が大きいと、
その関数を複数人でデバッグするということは、現実的になかなか難しいからね
いくつかの外部の小関数に分けてあれば、それぞれの小関数をみんなでデバッグできる
もちろん、各小関数が独立しているからこそ、みんなでデバッグができる
基本的に了解なのだが、
>関数Ａの中で関数Ｂと関数Ｃを使っていたら
この場合でも，関数Ａの計算過程は関数Ｂのそれと関数Ｃのそれから
独立だよね？（細かい確認でスマンが）
すまん、いつも言葉が足りなくて誤解を与えてしまうな
「関数Ａの計算過程を知る」の定義によるだろうね
>>37 では、内部で使ってる関数の内容も含めて関数Ａの計算過程と暗に定義していた
だから独立はしてなくて、関数Ｂや関数Ｃも知らないとね、と
内部の関数は含めず、純粋に関数Ａの中での式を知るという定義なら、独立している
きっと >>40 はこちらの意味で受け取ったんだよね
そんな簡単に分けられへん。
というかコインの表と裏。
基礎からやるならまず集合論でいいの？
集合、位相、束、代数、グラフ、論理の初歩をまとめたような本。
列挙したのをちゃんと理解してないと圏論は歯がたたない。
例えば↓が網羅的で練習問題回答がしっかりしてるから独学に向いてる。
http://www.amazon.co.jp/dp/4274130053/
これじゃ初歩的すぎるというのなら推薦図書スレで、
自分の数学能力を話した上で相談したらどうか。
あざっす
立ち読みしてみるわ
おるよ。なにか話してみてくれ。
どの辺りで打ちのめされたのかによるよ
俺は
Conceptual Mathematics: A First Introduction to Categories
http://www.amazon.co.jp/dp/052171916X/
これを読んで、難しかったり、意味が分からなかったり、
納得できなかった部分に出会ったら、その都度他の資料に当たったり、
数学系の掲示板で質問したりしてた
とりあえず古典的な集合の意味が分かって、
単射・全射が分かって、モノイドが分かれば、
圏論の入門書はけっこう読み進められると思う
（圏論の入門書の中でも必要な集合論を必要最小限説明してるし）
抽象的すぎて「飽きる」可能性は大いにあるが
勉強しはじめるには良い分野だと思う
join(T^2 -> Tな自然変換)がモノイドになっているっていう話ですか？
＿＿＿＿＿_
r〃〃〃 f７⌒ろ）
l∥∥∥ || f灯
|∥∥∥ || | |
|儿儿儿._」∟⊥厶
〔＿_o＿＿＿_o_≦ﾄ､
. ｉ / ⌒ ⌒ ヽ ）
!ﾞ （･ )｀ ´（ ･) ｉ/
| （_人__） | ＼
＼ ｀ー' ／ ／ ｰ- ､
. ,ｨ(⊆≧ﾘ≦⊇)〃 / rｸ＼
. ／ |￣r少}¨￣〃 / /′ ヽ
〃 l | l| | l| 〃 / / └ヽ
/ l |l | |ｌ/″ / ! 厂 ＼
く, Y ! l」fﾚﾄ! / | / 1
丿 | | 丿} じ’ / | / |
/ l | ｀¨ / ﾚ′ |
真の思考停
（在位 2009年9月16日～2010年6月8日）
民主朝の初代考停、言行不一致、虚言、脱税、
そして外交において巨大な負の遺産を築いた。
>圏論の入門書はけっこう読み進められると思う
読み進んでもイミフと思われ
[1] (return x) >>= f == f x
[2] m >>= return == m
[3] (m >>= f) >>= g == m >>= (\x -> f x >>= g)
それが「遠回し」と言えるのなら、
遠回しでないもっと簡単な表現に置き換えてみてほしい
そうか。そういう人もいると思うが、通常そういう人は、｢何でも理解しちゃう｣
人が多いんだよね。
>>61
簡単な表現かどうか以前に、まずこれとは別の表現は見つかる？
「なぜ遠回しな言い方をするのか」と訊いている
これは、遠回しではない言い方を知っている上で、
そのような表現ではなく、なぜ敢えて遠回しにするのか、
という意味で訊いているように俺は解釈した
ならば、その遠回しではない言い方に置き換えて表現してみてはくれないだろうか
それとも、俺の解釈が間違っていたか？
ちなみに、俺は少なくともモナド則に関してはこの表現で理解できたから、
別の表現を探す気は起こらない
後はなんちゅうことないことだ。
だけど圏論によい具体例があまりないんだ。
なにかよい例を知っているか？
圏の例は基本的だが，圏の圏の例がより実践的だと思うが。
[1] return <=< x == x
[2] x <=< return == x
[3] (a <=< b) <=< c == a <=< (b <=< c)
[4] (a <=< b) . f = a <=< (b . f)
どっちがシンプルに思えるかは人に依るかも
こりゃますます常人には分からんな。
スマンが間単に読み方を教えてくれんかな？
(<=<)はControl.Monadで定義されてるよ。定義は、
f <=< g = \x -> g x >>= f
遠回しもくそもないだろ。
表現が遠回しだとか、それこそ遠回しに伺っても、期待する返事は来ないぞ
（まぁ、単刀直入に訊いても、期待する返事が来るとは限らんけど）
この人たちは定義というものはなにかを定義していさえすればよいものだと
思っているらしい。
（ ´∀｀）＜ ぬるぽ
それのどこが何に対して遠回しなのかを説明してくれ
そうすれば、君が >>68 の何に対して遠回しと感じているのか分かるかも知れん
father(son(x)) = x
これは、左辺にある x に対する2個の（この順の）変換が右辺と同等である
という事を示していると思う
このような意味を表すのに father(son(x)) = x を持ち出すのが遠回しと感じるのなら、
君ならどう式で表現するのだろうか？
>father(son(x)) = x
>これは、左辺にある x に対する2個の（この順の）変換が右辺と同等である
>という事を示していると思う
うん。だがそれはその式を単にそのまま読んだだけだと思うんだ。
なにが言いたいんだこの式は？何が言えてるんだこの式は？とは思わな
いかい？
まあそういうことなんだが、皆さんイライラしているようだし、この辺
で寝るよ。かまってくれてありがとう。
でも一旦慣れれば問題なくなるし、
この内容を簡潔に表現するにはこの式しかないと思うようになる(f . g = idもあるけど)
モナド則も似たようなもんじゃね
> だがそれはその式を単にそのまま読んだだけだと思うんだ。
> なにが言いたいんだこの式は？
全く逆だ
「x に対して2個の変換 son と father をこの順で適用したものは x と同等である」
という、たまたま今は日本語で表された 「意味」 が何よりも先に先にある
（この意味を人に伝えるには何かの言語で表す以外ないから、たまたま日本語で表した）
この意味を数式という言語で表せば father(son(x)) = x となる
この意味を英語という言語で表せば・・・
この意味をヒンドゥー語という言語で表せば・・・お任せする
モナド則も意味が先にあって、それをHaskellの式で表す方法のひとつとして >>59 がある
他にも >>68 の様に表す方法もあるし、もしその意味を日本語で表すなら・・・
ということだ
っていうのが一番簡潔で直接的なモナド則の書き方
>>= は \f->\g->join (fmap g f)によって定義できる二次的なもの
[2] join . return == id == join . fmap return
計算論 計算可能性とラムダ計算
買ってみようと思う。
他におすすめある？
Amazon.com 本店（米）の中古はもっと酷い 916.21 ドル
でも、Amazon.co.uk なら中古が 20 ポンドで売ってる（国際便もあるみたい）
MITの学生さんだって。みな頑張れ
どうせ大学の図書館探したら転がってるだろうから、みることは可能だろうよ。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・ 次のスレ
5: C/C++の宿題片付けます 155代目 (666)
6: C言語なら俺に聞け（入門編）Part 95 (702)
7: Rubyについて Part46 (323)
8: Excel VBA 質問スレ Part22 (968)
