関数型プログラミング言語Haskell Part15
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2011/07/09(土) 17:16:54.84ttp://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/
0002デフォルトの名無しさん
2011/07/09(土) 17:18:53.89・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
0003デフォルトの名無しさん
2011/07/09(土) 17:19:45.18・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
0004デフォルトの名無しさん
2011/07/09(土) 17:21:15.57ttp://www.haskell.org/hoogle/
【簡単な使い方】
１．検索バーに関数名を入れて検索
例 map
２．検索バーに型名を入れて検索
例 (a -> b) -> [a] -> [b]
0005デフォルトの名無しさん
2011/07/09(土) 20:10:41.280006デフォルトの名無しさん
2011/07/09(土) 22:15:29.240007デフォルトの名無しさん
2011/07/10(日) 06:36:49.99Learn you a haskell for great good!
http://www.amazon.co.jp/dp/1593272839
http://learnyouahaskell.com/
0008デフォルトの名無しさん
2011/07/10(日) 06:37:49.14Learn you a haskell for great good!
http://www.amazon.co.jp/dp/1593272839
http://learnyouahaskell.com/
craft3e
http://www.amazon.co.jp/dp/0201882957
0009デフォルトの名無しさん
2011/07/10(日) 13:55:51.130010デフォルトの名無しさん
2011/07/11(月) 12:03:06.910011デフォルトの名無しさん
2011/07/11(月) 12:07:37.830012デフォルトの名無しさん
2011/07/11(月) 12:34:45.520013デフォルトの名無しさん
2011/07/11(月) 12:44:09.690014デフォルトの名無しさん
2011/07/12(火) 04:33:58.900015デフォルトの名無しさん
2011/07/12(火) 04:35:45.36参照透過性は新しい言語でも取り込まれています。
しかし非正格評価は処理量予測が難しいという問題があり、
今後も限られた範囲でしか使われないでしょう。
Haskellは非正格評価を標準としている以上、
広く普及する事はありえないのではないでしょうか？
●参考資料
各関数型言語の求人率
http://www.indeed.com/jobtrends?q=Lisp,SML,Haskell,Scala,Clojure&l=
俺は Haskell の sieve についてとんでもない思い違いをしていたようだ...
http://d.hatena.ne.jp/camlspotter/20100128/1264678903
経験15年のOCaml ユーザーが Haskell を仕事で半年使ってみた
http://d.hatena.ne.jp/camlspotter/20101212/1292165692
(前略)OCaml 暦十何年だったか忘れたけど仕事で Haskell を一年使ってみた
http://d.hatena.ne.jp/camlspotter/20110509/1304933919
0016デフォルトの名無しさん
2011/07/12(火) 07:06:42.36ていうかMLスレはなかったんだっけ？
0017デフォルトの名無しさん
2011/07/12(火) 07:18:25.090018デフォルトの名無しさん
2011/07/12(火) 07:35:52.440019デフォルトの名無しさん
2011/07/12(火) 08:16:32.790020デフォルトの名無しさん
2011/07/12(火) 08:24:21.420021デフォルトの名無しさん
2011/07/12(火) 08:56:49.490022デフォルトの名無しさん
2011/07/12(火) 13:25:55.09参考資料の人の結論は、
- Haskell は OCaml 並に普通に業務で使える言語
- Haskell マニアが嬉しそうに紹介している機能は実はほとんど使う必要が無い。
せいぜい Monad transformer位で仕事は出来る
- Haskell には良いところもあるし、悪いところもある。手放しで神格化するのが一番問題
なので、そういう文脈で引用するのは作為的なのでは？
速度重視のコードを遅延評価で書くのは大変でも、どの言語でもそういうノウハウはあるわけで。
遅延の利点ばかりに目をやらないで、そういうノウハウも蓄積しましょうよ、って話だったよね、それ。
>>16
MLスレはあるけど、>>15のはそういうOCaml賛美とかじゃない。普通に読む価値がある文章だと思う。
0023デフォルトの名無しさん
2011/07/12(火) 19:51:25.34求人率に Prolog を加えると面白いんじゃなかったっけ。
0024デフォルトの名無しさん
2011/07/12(火) 21:45:28.38売り物のコードにHaskellのソースコード入れてから業務に使えると言ってほしい
0025デフォルトの名無しさん
2011/07/12(火) 22:07:18.40○ OCaml 並に業務で使える
0026デフォルトの名無しさん
2011/07/12(火) 22:23:08.86OCaml を業務に使ってる人がいなければ、「OCaml 並に業務で使える」という命題も「OCaml 並に業務で使えない」という命題も真になる
0027デフォルトの名無しさん
2011/07/12(火) 22:47:42.18そもそもコードを出荷しない会社なんじゃね？
チームのメイン言語がHaskellなら、業務に使える使えないを語って当然だろ
0028デフォルトの名無しさん
2011/07/12(火) 23:07:55.670029デフォルトの名無しさん
2011/07/12(火) 23:09:39.56そもそもチームすらないかも知れん
普通はExcelでデータ入力してて、暇になったときに上司にばれないようにHaskellのスクリプトで定期的に2chのログを収集してる程度でも、業務に使えるということに変わりはない
0030デフォルトの名無しさん
2011/07/12(火) 23:12:57.90業務＝直接金になること という認識だから売買の対象にならなければ業務じゃない
売買の対象という意味じゃなければ、PCで遊んでるのも業務だからいちいち「業務で」と断る必要はない
0031デフォルトの名無しさん
2011/07/12(火) 23:22:44.890032デフォルトの名無しさん
2011/07/13(水) 01:37:06.53主に金融系でHaskellとかOCaml、F#とかの関数型言語は割と人気があって、
採用事例が多いそうな。Tsuru Capitalとか、かつてのリーマン・ブラザーズとか。
OCamlならJane Streetとか。もちろんチームで。
使っているのは、金融商品を取り扱うための言語フレームワークを作ったり、
統計的分析を元にした取引銘柄自動売買とかだってさ。
てか、リンク先読まずに想像でどうこう言うってのもどうなのよ。
0033デフォルトの名無しさん
2011/07/13(水) 02:16:09.560034デフォルトの名無しさん
2011/07/13(水) 02:48:32.29ttp://d.hatena.ne.jp/camlspotter/20100330/1269927047
ttp://www.nri.co.jp/opinion/it_solution/2005/pdf/IT20050307.pdf
上のは元々の引用されてた人の話。下のは野村総研の人が書いた文章で、
LexiFi社のMLFiっていうDSLの紹介をしてる。こういう手法の先駆けなんだと。
コンビネータでお手軽金融商品定義！ とか、受け良さそうじゃん。
0035デフォルトの名無しさん
2011/07/13(水) 06:13:04.720036デフォルトの名無しさん
2011/07/13(水) 06:28:08.720037デフォルトの名無しさん
2011/07/13(水) 07:00:02.300038デフォルトの名無しさん
2011/07/13(水) 16:14:19.76俺の嫌いな物は食べ物じゃない
0039デフォルトの名無しさん
2011/07/13(水) 21:15:43.17国債買ってて遊んでても給料がもらえて暇だから
0040デフォルトの名無しさん
2011/07/15(金) 21:43:17.40みたいなこと誰か言ってくれたら俺もhaskellもうちょっと頑張れる気がする
0041デフォルトの名無しさん
2011/07/15(金) 21:53:58.85他人と同じことやってたら食っていけないからじゃないか？
金融系ちゅうかそれ証券系だよな
銀行生損保あたりは>>39だろ
0042デフォルトの名無しさん
2011/07/15(金) 23:28:33.06という話を鵜呑みにして、会社でHaskellを導入したら、haskell使ってWEBのバックエンドシステム作るプログラマをメンテ・教育するコストで会社が潰れると思う
0043デフォルトの名無しさん
2011/07/16(土) 03:55:45.49と言ってみたい
0044デフォルトの名無しさん
2011/07/16(土) 08:03:58.180045デフォルトの名無しさん
2011/07/16(土) 08:47:35.10根拠は無い
0046デフォルトの名無しさん
2011/07/16(土) 10:03:43.83@tanakh さんのツイートとか見てるとそんな印象だな。要するにあるレベル以上になると
使える人が急激に減るみたい。んなことはＣ＋＋でもなんでも一般的には言えることだけど
Haskellの場合には減り方が激しいんだろうということ。
ただ、@tanakhさんは最近の、ＩＣＦＣだっけか、ラムダ計算のカードゲームの話ではチーム
組んで良い成績をあげてるので、Haskell実力者どうしのチームが機能しないという話しでは
ないだろう。参戦記を読んだ限りでは、モナドを単位にしたモジュール化でうまく作業分担
していたようだ。
0047デフォルトの名無しさん
2011/07/16(土) 10:13:52.60非現実的な事この上無し
0048デフォルトの名無しさん
2011/07/16(土) 10:48:04.52上級者÷一般レベル の値が一番小さいのがアセンブラ
004946
2011/07/16(土) 11:53:05.28モナドを単位とした振り分けでチーム開発は可能であることの例証だし、世の中でもそこそこ
行われているんじゃないか、という話がしたかった。競技プログラミングを例にしたのは成果や
過程があるていどオープンになっていて引き合いに出しやすかったからだけど、実際に金融
やらなんやら我々の目に触れにくい（または触れることがない）分野でこういったモナドを単位とした
分担開発は行われているんじゃないか。
0050デフォルトの名無しさん
2011/07/16(土) 12:02:36.120051デフォルトの名無しさん
2011/07/16(土) 12:27:19.53我々の目に触れない理由を考えよう
0052デフォルトの名無しさん
2011/07/16(土) 14:11:16.18どうすれば速くなるか解説しているページがあったのでリンクします。
性能を追求する時は、文字列がリストだから文字列操作が簡潔という話は
Haskellの優雅さを示すための神話として切り捨てる必要があるのですね。
Haskellの神話
http://d.hatena.ne.jp/kazu-yamamoto/20100624/1277348961
>この記事では、神話になっている例を3つ取り上げ、
>効率のよい実装と合わせて紹介する。
Haskellライブラリ入門 (2011年版)
http://d.hatena.ne.jp/kazu-yamamoto/20110525/1306298046
>リストはとても柔軟ですが、リストで表現されている文字列は、
>メモリーをたくさん消費しますし、なにより遅いのです。
>実用的なプログラムを書くためには、
>必要に応じて適切なデータ構造を使う必要があります。
0053デフォルトの名無しさん
2011/07/16(土) 14:51:33.13スケーラブルHaskell開発
だな
0054デフォルトの名無しさん
2011/07/16(土) 14:53:42.080055デフォルトの名無しさん
2011/07/16(土) 17:27:04.120056デフォルトの名無しさん
2011/07/16(土) 18:18:41.53http://www.kotha.net/hperf/
このテーマを掘り下げた本なら喜んで買います。
0057デフォルトの名無しさん
2011/07/16(土) 18:29:56.210058デフォルトの名無しさん
2011/07/16(土) 19:04:32.78先生できました
0059デフォルトの名無しさん
2011/07/16(土) 19:19:41.17Common Lispでも高速化させようと思ったら、ある程度
泥臭い記述が増えてくるよ。一部がマクロでかぶせられるとは言ってもね。
高速化って結構泥臭いもんだから同じだなと思った。
ととあるりすぱぁ（あたまもぱぁ）からの感想です。
0060デフォルトの名無しさん
2011/07/16(土) 19:29:12.67リストで文字列を扱うときのメモリ消費はガチ。特に64ビット環境。
そりゃあ、バイト列使おうとかいう話にもなるよね。
0061デフォルトの名無しさん
2011/07/16(土) 23:22:45.90リスト操作に慣れる、という意味での教育効果もあると思うし。
最近のPerlインタプリタとかjavascriptインタプリタとかの、文字列の内部的にどういう構造になっているんだろう？
文字配列のリスト？
0062デフォルトの名無しさん
2011/07/17(日) 04:55:38.66Educationモジュールに追いやっちゃえよ
0063デフォルトの名無しさん
2011/07/17(日) 15:58:17.74文字列以外の場所でもリストってやばいのか
0064デフォルトの名無しさん
2011/07/17(日) 17:14:03.02えー？
むしろ64bitが普及したらメモリ食うとか気にしなくなるだろうから、全部リストで済ませたいけどなぁ
最適化よりも楽にプログラミング出来る方が有難い
最適化したけりゃcの関数呼び出せば良いんだし
元々プログラマが最適化するのには関数型言語は向かないんだしさ
適材適所で手続き型言語を呼び出せば良い
そんなのより並列リストと普通のリストを統合したりして、基本的な文法で並列化出来るようにして欲しいぜよ
0065デフォルトの名無しさん
2011/07/17(日) 17:24:42.83参照透過性に関係する問題だという漠然としたイメージはあるのですが、
どういったものか全く分かりません
0066デフォルトの名無しさん
2011/07/17(日) 17:37:32.82単純に量じゃなくてGCにCPU時間使うのが問題だと思ってる
0067デフォルトの名無しさん
2011/07/17(日) 18:29:06.62同意。その通りだと思う。GCに引っかかると途端に遅くなる。
数十バイトとか数キロバイトなら倍メモリ消費しても全然問題にならないけど、
数百メガバイトとかになってくると、倍とか普通にきつい。
リスト廃止しろとかは笑えないけど。楽で良いじゃんリスト。
0068デフォルトの名無しさん
2011/07/17(日) 19:41:40.96まだまだ使っている人はもちろんいるんだろうけど。
0069デフォルトの名無しさん
2011/07/17(日) 20:02:02.36Text.Printf.printf 関数は今でも普通に使ってる
これ使わないと、数値から文字列を作るのがえらく面倒になる
特に桁を揃えたりゼロで埋めたい時
とてもシンプルに書けるから重宝してる
ただ、コンパイル時に型エラーを検出できないのが不満だ
他に総合的にもっと使いやすいライブラリがあるのなら教えてほしい
0070デフォルトの名無しさん
2011/07/17(日) 20:05:22.85Text.Printfを置き換えられる程のものはなかったような
0071デフォルトの名無しさん
2011/07/17(日) 21:31:15.49あ、オレが言っていたのは、C言語のprintf関数のこと。
Doubleとかの浮動小数点数の桁をそろえて出力するHaskellの便利なライブラリは知らない。
オレは、表示してみて科学記法がならんで「ウザっ」て思うときは、表示するときだけmap (floor.(*10^3))とかしてしのいだり。
そういうことしてしのげないときは、科学記法で我慢している。
0.000000123と0.0000000234みたいな表記をされても、どうせどちらが大きいのかさえ一瞬では分からないので、科学記法のほうがいくぶんマシ。
0072デフォルトの名無しさん
2011/07/17(日) 21:37:59.870073デフォルトの名無しさん
2011/07/19(火) 15:42:11.91Javaのそれと比べたら冗談みたいなレベルらしいじゃないか
0074デフォルトの名無しさん
2011/07/19(火) 15:51:55.370075デフォルトの名無しさん
2011/07/19(火) 16:39:11.18アンドロイドに搭載された辺りで訴えちゃうよ？
0076デフォルトの名無しさん
2011/07/19(火) 19:00:59.66「らしい」なんて不確かなことで要求するな
0077デフォルトの名無しさん
2011/07/20(水) 01:34:16.17改良されてきたJVMが優れているという話にしかならん
0078デフォルトの名無しさん
2011/07/20(水) 09:59:10.36http://hackage.haskell.org/trac/ghc/wiki/Commentary/Contracts
0079デフォルトの名無しさん
2011/07/22(金) 04:52:21.32大体上手く行っています。問題は、”☆”みたいな文字をいくつかのテキストに
付加するための定数として
star = "☆"
などとしておいて cs ++ star みたいな事をやると star の部分が文字化けしてしまうことです。
GHC.IO.Encoding.UTF8 を使ったら良さそうなのですがghci で import して :t utf8 しても
意味が理解できなくてどうやって utf8 という関数を使うのかが理解できません。
最初は
star = utf8 "☆"
と書いてみたんですがダメみたいです。（なにか根本的に誤解してるみたいです）。
プログラム内で utf8 文字列定数を定義するにはどうすれば良いのでしょうか？
（もちろんプログラム自体も UTF8 bom 付きで保存して ghc に食わせています。）
0080デフォルトの名無しさん
2011/07/22(金) 05:05:50.80あ．．． System.IO.UTF8 ってのを入れたらなんとかなるかも知れないですね。
cabal ってのが意味わかりませんがやってみます。
0081デフォルトの名無しさん
2011/07/22(金) 05:17:31.10cabal ってのが良く分からなかったけど、HackageDBに
接続してくれるパッケージ管理システムなんですかね？
とにかく ttp://hackage.haskell.org/package/utf8-string-0.3.3
で取ってきたものを解凍して cabal install utf8-string.cabal したら
．．．
import System.IO.UTF8 as U8
main = do args <- getArgs
cs <- U8.getContents
let option = head args
U8.putStr $ f option cs
みたいにして上手くいったみたいです。お騒がせしました。
#入力テキストをUTF8にしないといけないのだけが面倒ですね．．．
0082デフォルトの名無しさん
2011/07/22(金) 07:06:56.89↓ ↓
Microsoft Research
MSR Asia Fellowishipの受賞者
東京大学の韓帥さん（佐藤洋一研究室、博士課程3年生）
http://bit.ly/k2ICwU
東京大学のAdiyan Mujibiyaさん
http://bit.ly/h2PtfR
筑波大学の金石煥さん
http://bit.ly/f2jg4e
大阪大学の 白川真澄さん
http://bit.ly/iEydzU
東京大学工学部の 折居直樹さん。
私の知る限り学部生で日本からインターンに来た
ケースは折居さんが初めてです。
http://bit.ly/mgHTTT
シリコンバレー
http://research.microsoft.com/en-us/labs/siliconvalley/default.aspx
北京
http://research.microsoft.com/en-us/labs/asia/default.aspx
0083デフォルトの名無しさん
2011/07/22(金) 20:25:14.090084デフォルトの名無しさん
2011/07/22(金) 21:27:37.45ま、誰誰を指すかは大体検討はついてるけどね
0085デフォルトの名無しさん
2011/07/22(金) 21:40:19.82Monoid クラスの mempty 関数と mappend 関数
これらって、意味的に何か違いはあるんですか？
たとえば、ある型が既に Monad クラスのインスタンスであって、
なおかつ identity と associativity の両性質を持っていた場合、
その型は Monoid クラスのインスタンスにも、
MonadPlus クラスのインスタンスにも成れますよね
どちらのクラスのインスタンスにするか、
あるいは両方のインスタンスにするか、
判断する基準みたいなものは一般的に何かあるのですか？
単に好きな関数名が有る方を選んどけ、という程度でしょうか
0086デフォルトの名無しさん
2011/07/22(金) 22:06:15.940087デフォルトの名無しさん
2011/07/22(金) 22:56:17.80どちらかのインスタンスにする必要があるの？
そういう疑問がわくということは、べつにどちらのインスタンスにする差し迫った必要もなさそうだけど。
もしそうなら、どちらのインスタンスにする必要もないでしょ。
あと、mzeroは>>=に対して定義されているんだから、Monadに対してしか意味をなさないけど、
mzeroとmplusしか使わないなら、memptyとmappendと交換しても何もおかしくないとは思う。
0088デフォルトの名無しさん
2011/07/22(金) 23:19:10.32> どちらかのインスタンスにする必要があるの？
Monoid クラスのインスタンスにする必要がある時
MonadPlus クラスのインスタンスにする必要がある時
というのは、例えばどんな場合なのでしょうか
0089デフォルトの名無しさん
2011/07/23(土) 02:17:43.58> Monoid クラスのインスタンスにする必要がある時
mconcatとか、Data.Foldable.foldとか、引数(の一部)がMonoidクラスのインスタンスである必要がある関数を使いたいとき。
> MonadPlus クラスのインスタンスにする必要がある時
同様に、引数がMonadPlusクラスのインスタンスである必要がある関数を使いたいとき。
突き詰めれば、これだけの話だと思う。
0090デフォルトの名無しさん
2011/07/23(土) 08:04:58.17とりあえず、インスタンスにする型がMonadでもある時にguardを使うかどうか考えてみて
言い換えれば計算の途中に特定の条件で計算を打ち切るようなことを期待する場合ね
そんなのあきらかにねーよってんならMonoidでいいと思うよ
0091デフォルトの名無しさん
2011/07/23(土) 14:37:42.92みるとclojureの母親だな。haskellって
0092デフォルトの名無しさん
2011/07/23(土) 15:31:55.30>>90
なるほど、ということは、機能としての違いでしかないというわけですね
そういった機能以外には、特に区別する意味は無い？
例えば Monad クラスしかなく Monoid クラスがまだ存在していなくて、
Data.Foldable.fold 関数らも Monoid クラスではなく
MonadPlus クラスのインスタンスを要求しているような世界において、
機能的にはそれで十分だと思うのですが、
Monoid クラスをライブラリに加えてくれという要求は出てこないのでしょうか
0093デフォルトの名無しさん
2011/07/23(土) 16:25:14.83> Data.Foldable.fold 関数らも Monoid クラスではなく
> MonadPlus クラスのインスタンスを要求しているような世界において、
> 機能的にはそれで十分だと思うのですが、
> Monoid クラスをライブラリに加えてくれという要求は出てこないのでしょうか
なんでそうなる。
すべてのデータ型が既にMonadならそういうことにもなるかもしてないけど、
現実にそうではないこの世界のHaskellにおいては、
MonadのインスタンスにできないがMonoidにできるデータ型はいくらでも考えられるでしょ。
そのとき、Monoidクラスは意味がある。
-- いや、正直、実際のプログラミングでMonoidクラスが有用だと感じたことはないが…
-- そういう意味では理論的関心が先行した感の強いクラスだとは思う
0094デフォルトの名無しさん
2011/07/23(土) 16:42:02.66> なんでそうなる。
だって、そういう（たとえ話の）世界では
identity と associativity の両性質があることで果たせる機能が
MonadPlus クラスのおかげで既に実現されているわけだから、
「機能という点において」は Monoid クラスが作られる必要性がないわけでしょ
でもそんな世界にあっても、もし Monoid クラスが必要だという要求が出てきたら、
それはそういう機能以外にも、Monoid という性質に意味があるということじゃないかな
あるいは、>>89 や >>90 以外にも Monoid ならではの機能があるとか
と、思考実験してみました
Monoid クラスにどんな意味（隠れた機能）があるのかまでは、まだ考えられてないけど
> いや、正直、実際のプログラミングでMonoidクラスが有用だと感じたことはないが…
同感です
0095デフォルトの名無しさん
2011/07/23(土) 16:47:14.80アンカーミスりました
本当は >>93 です
お詫びに面白そうな本を紹介します
A Framework for Programming Interactive Graphics in a Functional Programming Language
0096デフォルトの名無しさん
2011/07/23(土) 16:54:06.90いや、型クラスに関しては「機能が弱い」からこそ役に立つ場合がある
たとえばFunctorでできることは全てMonadでもできるけど、だからといってFunctorが不要な訳ではない
なぜならFunctorのインスタンスにはなれてもMonadのインスタンスになれない型が存在するから
MonoidとMonadPlusについても同様で、たとえばByteStringはMonoidインスタンスになれるけど、
MonadPlusインスタンスにはなれない
実際のプログラミングでも便利だと思うけどな、Monoidクラス
特に、mappend相当の関数名をいちいち考えたり覚えたりしなくて済むという点において
0097デフォルトの名無しさん
2011/07/23(土) 16:55:59.830098デフォルトの名無しさん
2011/07/23(土) 17:04:35.240099デフォルトの名無しさん
2011/07/23(土) 17:06:59.01を標準ライブラリに入れるって提案があったはずだけどどうなったんだろう
0100デフォルトの名無しさん
2011/07/23(土) 17:26:18.86> いや、型クラスに関しては「機能が弱い」からこそ役に立つ場合がある
「機能が弱い」のではなくて、「機能が重複している」のは何で？
と言いたかった
私には Momoid クラスの機能と MonadPlus の機能が
（今のところ）重複しているように見えます
何というか、Monad の性質 ＋ Monoid の性質 ＝ MonadPlus の性質
という感じがするのです
だから本質的に MonadPlus クラスは必要なく (MonadPlus m) => ... は
(Monad m, Momoid m) => ... とライブラリの設計を変えても、
機能的には何も問題なく働くのではないかと思うのですが、どうでしょう？
（まだ何となくそう考えているだけで、詳しく検証はしていません）
（ただ、機能は重複しても意味が違うのであれば、
２つのクラスはそれぞれ区別すべきだとも思います）
0101デフォルトの名無しさん
2011/07/23(土) 17:40:07.15計算機に載せた場合、機能として同じなのかもしれんが、
モノイドは集合の構造だけれど、モナドは圏の構造だから
もととなる土台がぜんぜん違う。
■ このスレッドは過去ログ倉庫に格納されています