関数型プログラミング言語Haskell Part17
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2012/01/02(月) 22:19:28.26ttp://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/
0552デフォルトの名無しさん
2012/02/11(土) 12:46:57.36まぁ別にどっちでもいいことだけど
0553デフォルトの名無しさん
2012/02/11(土) 13:56:27.610554デフォルトの名無しさん
2012/02/11(土) 19:24:57.360555デフォルトの名無しさん
2012/02/11(土) 23:32:33.40ghci 上で data や instance なんかの宣言ができるようになってた
これは便利
それはそうと、さっさと実行時に利用コア数を変えられるようにしてほしいものだ
0556デフォルトの名無しさん
2012/02/11(土) 23:50:35.15増やせるだけで減らせないみたいだけど
0557デフォルトの名無しさん
2012/02/11(土) 23:54:08.17current Haskell Platform release includes a recent GHC release as well
as some other tools (such as cabal), and a larger set of libraries
that are known to work together.
と書いてるからさ、５月まで待ったほうがいいんじゃない？ <7.4.1
0558デフォルトの名無しさん
2012/02/11(土) 23:59:10.81Haskell Platformは最近のGHCを含んでいて、おまけに、他のツール（cabalと
かね。）も動くし、よく使われてるライブラリも動くからさ。
だとさ、と意訳しとく。
0559デフォルトの名無しさん
2012/02/12(日) 00:00:24.87普段は最新版使った方が楽しい
0560デフォルトの名無しさん
2012/02/12(日) 00:03:51.270561デフォルトの名無しさん
2012/02/12(日) 00:06:35.18まあ、こなれた人ならそうかもしれない。でも、ここって、いろんな人が
いるから、一応書いといた。こなれた人ならトラブルに出会っても、解決
できるだろうし、それが楽しいもんな。
https://groups.google.com/forum/?fromgroups#!forum/haskell-jp
でも、しんさんがリリースのメールに注意書きがされているけどね。
0562デフォルトの名無しさん
2012/02/12(日) 08:01:47.18haskellのレコード構文って何でこんなきもちわるいの
フィールド一つ書き換えただけの新しいレコードが欲しいだけなのに
0563デフォルトの名無しさん
2012/02/12(日) 08:17:24.52このクランケの症例では
・碌に調べもしない
・煽る事で住人達に答えさせようとしている
点が伺えます
これらは怠慢横柄病患者に共通に見られるのです
0564デフォルトの名無しさん
2012/02/12(日) 08:37:41.32いやまあ、自分で調べなかったわけでもないんだけどな
ほぼ無理なのは分かってる
0565デフォルトの名無しさん
2012/02/12(日) 08:40:12.600566デフォルトの名無しさん
2012/02/12(日) 11:11:24.92どういう書き方ができると良かったの？
0567デフォルトの名無しさん
2012/02/12(日) 11:22:02.57増加だけでもできるようになったのか
リリースノートを斜め読みしてたから見逃してた
0568デフォルトの名無しさん
2012/02/12(日) 11:34:11.27これパフォーマンスどうなるんだろうという不安が出てくる
0569デフォルトの名無しさん
2012/02/12(日) 11:35:43.98神に従え
0570デフォルトの名無しさん
2012/02/12(日) 12:17:15.85SomeRecordとSomeFieldを二回も書きたくないというか
フィールドと同名のgetterを自動生成するような動きを許容したのなら
もっとはっちゃけて欲しかったというか
テンプレート？ テンプレートなぁ・・・
0571デフォルトの名無しさん
2012/02/12(日) 12:29:24.180572デフォルトの名無しさん
2012/02/12(日) 13:23:20.06そうは言っても、「汎用的にするなら」 少なくとも
1. 何のデータ型の（値の）
2. 何のフィールドを
3. どう変えるのかを
この３つのは何らかの形で指定する必要があると思うが
0573572
2012/02/12(日) 13:31:17.15すまん、不満点をちょっと勘違いしてたみたいだ
こういうことか
someRecord { someField = f $ someField someRecord }
{} 前の someRecord の部分が型構築子じゃなく値構築子の場合、
f $ someField someRecord の someRecord 部分は明白だから省略可能
こうなれば、幾分スッキリするな
0574デフォルトの名無しさん
2012/02/12(日) 15:04:59.49オプションで library-profiling を有効にすると、
そのライブラリもプロファイリングの対象にできるよね
これって、プロファイリングしないで普通に使う時は
遅くなったりしない？
0575デフォルトの名無しさん
2012/02/12(日) 15:11:00.59ので遅くならない
0576デフォルトの名無しさん
2012/02/12(日) 15:31:06.20そっか、安心した
ありがと
0577デフォルトの名無しさん
2012/02/12(日) 19:23:37.68（他のパラレル系関数もですが、代表して par を選びました）
par :: Functor col => (forall sf. a -> col sf -> col (b, sf)) -> col (SF b c) -> SF a (col c)
このルーチン関数の sf という型変数には、SF b c 以外入ることは無いと思うのですが、
単純に a -> col (SF a b) -> col (b, SF a b) という型では何がいけなかったのでしょうか
0578デフォルトの名無しさん
2012/02/12(日) 21:52:55.77ソースコードへのリンクが貼られるようにする方法はないのでしょうか？
HackageDB のサイトで見られるドキュメントみたいにしたいです
0579デフォルトの名無しさん
2012/02/13(月) 10:41:10.37スライドとか論文だと確かOpacity(透過性？)のためとか書いてあって、
俺も正確な意味はよくわからなかったんだけど、
SFを書き換えられるような関数を渡せるのを防止してるんじゃないかな。
route a xs = [(a, identity)]
みたいな、コレクションの中身を無視して出所不明のSFにしちゃうような。
0580デフォルトの名無しさん
2012/02/16(木) 05:11:31.94F#の本にはモナドのことが書いていない。
で、ネットでモナドのことを収集すると、ハスケルのがほとんど。
F#での説明もあるが、なんか解りづらい。
で、モナドって何ですか？
関数型プログラミングをやるにはモナドが必須ですか？
どなたか教えてください _o_
0581580
2012/02/16(木) 05:15:46.89習った覚えがありませんし、仮に習っていても記憶にないのだから、習っていないのと同じです。
0582デフォルトの名無しさん
2012/02/16(木) 05:48:37.15使い方としてはモナド則を頭に入れてからListモナドとStateモナドを理解すれば後は大体類推が利く。
F#でどうなのかは知らないが、少なくともHaskellで何か書こうと思ったらモナドは必須。
まあ「モナドとは何か」みたいな話は過去スレ遡ればいくらでも出てくるよ。
0583デフォルトの名無しさん
2012/02/16(木) 08:10:51.47わかりにくいんだよなぁ。。
Haskellのクラスは、C++でいう抽象クラス見たいなもので、
Haskellのモナドがクラスでどう定義されてるか調べていけば、
意味はわからなくても、使い方はわかると思うよ。
モナドの意味は使っている内に、なんとなくわかるようになる、、、と思う。
0584デフォルトの名無しさん
2012/02/16(木) 09:19:10.08象のようで象のようでない
さてはモナドって南京弾簾だろ！
0585デフォルトの名無しさん
2012/02/16(木) 09:37:41.55もっと「もこもこ」みたいな可愛い名前にすれば大流行していた。
とか講演でいってたな。
0586デフォルトの名無しさん
2012/02/16(木) 09:48:34.020587デフォルトの名無しさん
2012/02/16(木) 09:51:36.680588デフォルトの名無しさん
2012/02/16(木) 10:16:54.54そのソースはどこよ？w
0589デフォルトの名無しさん
2012/02/16(木) 13:28:49.11元ネタはこれのはず。
Wearing the hair shirt: a retrospective on Haskell (2003)
Simon Peyton Jones, invited talk at POPL 2003.
http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/
Our biggest mistake
Using the scary term "monad" rather than "warm fuzzy thing"
0590デフォルトの名無しさん
2012/02/16(木) 14:37:03.09Escape from the Ivory Tower: The Haskell Journey, from 1990 to 2011
http://yow.eventer.com/events/1004/talks/1054
簡単だけど32分あたりに "warm fuzzy thing" が出てくる。
各銀行が秘密の Haskell 部隊を雇ってるって話はどこまで本当なんだろう。
0591デフォルトの名無しさん
2012/02/16(木) 15:37:45.12なんでこのなものが要るのか直感的に分からないってこと？
0592デフォルトの名無しさん
2012/02/16(木) 15:56:24.13そして処理が一本道だから
もこもこで一本道
略して もこみち とかどうよ？
0593デフォルトの名無しさん
2012/02/16(木) 16:21:24.02Haskellの型クラスはC++の抽象クラスとは全く違うよ。
オブジェクト指向の考え方は捨てるべき。
0594デフォルトの名無しさん
2012/02/16(木) 18:14:54.420595デフォルトの名無しさん
2012/02/16(木) 18:27:40.48Haskellでは、どのようなパラダイムがこれから出てくるのか
私はそれが楽しみでならないのです
って去年死んだおじいちゃんが死ぬ間際に言ってた
0596デフォルトの名無しさん
2012/02/16(木) 18:49:29.400597デフォルトの名無しさん
2012/02/16(木) 19:05:35.61モサドにしよう
0598デフォルトの名無しさん
2012/02/16(木) 19:24:01.77Haskellは遅延評価という機能を用いて現実世界の手順を隠蔽することに成功し、
宣言的な設計・実装が行えるようになりました。
しかしHaskellは関数型言語からは踏み出さないだろうから、新しいパラダイムは
Ozのようなマルチパラダイム言語に期待すべきだろうと思えてならないのです。
って友達がさっき言ってた。
コンピュータプログラミングの概念・技法・モデル
http://toro.2ch.net/test/read.cgi/tech/1196257692/
0599デフォルトの名無しさん
2012/02/16(木) 19:27:51.750600餃子チョコレート ◆8X2XSCHEME
2012/02/16(木) 20:52:04.09一瞬「終ったランゲージ」と思わせといて実は「終わらん」というダブルミーニングですね!!
0601デフォルトの名無しさん
2012/02/16(木) 22:13:47.28そう？
「Learn You a Haskell for Great Good!」には、JavaのInterfaceみたいなのと
考えたほうがいいって書いてるけど。
全く違うっていうならどう考えればいいか説明してほしいな。
0602デフォルトの名無しさん
2012/02/16(木) 22:27:34.65最初、(>>=)はただ関数に引数にして渡すだけじゃないか、なんで必要なんだとか思ってた。
他のもなんでこんなのが必要か理解できなかったよ。
変な型修飾付けるせいで、型が違うって怒られるし。
でもそうやって好き勝手書けないようにするのが狙いなんだな。
0603デフォルトの名無しさん
2012/02/16(木) 22:46:41.670604デフォルトの名無しさん
2012/02/16(木) 22:56:34.58Haskell の型クラスと Java のインターフェイスにおいて、
考え方の共通点とは何でしょうか
それは、コンパイル時にどう解釈されるかというレベルの共通点でしょうか
それとも、アプリケーションを作る上での指針となるくらいのレベルの共通点でしょうか
0606デフォルトの名無しさん
2012/02/17(金) 03:06:37.400607デフォルトの名無しさん
2012/02/17(金) 04:24:56.800608デフォルトの名無しさん
2012/02/17(金) 04:41:03.84ただし、これだけオブジェクト指向の概念が普及しているのが現実なのだから、
それを配慮した命名が望ましかった(かもしれない)ということ
これをHaskellの傲慢さと見るか、それとも数学的に正しい命名であると見るかは
判断が分かれるところ
0609デフォルトの名無しさん
2012/02/17(金) 04:50:13.16類をモデルにしているのはtype classだけだとか思ってるところが
Haskellerの傲慢さじゃないの？
0610デフォルトの名無しさん
2012/02/17(金) 05:12:11.76smalltalk(80) http://web.cecs.pdx.edu/~harry/musings/SmalltalkOverview.html#The%20Smalltalk%20Object%20Model
これ参考にCからC++とObjCができたのか。
0611デフォルトの名無しさん
2012/02/17(金) 06:49:42.48オブジェクト指向のclassって命名にケチつけてるなら
Haskellerは傲慢だけど、そうじゃないよね？
0612デフォルトの名無しさん
2012/02/17(金) 07:36:36.250613デフォルトの名無しさん
2012/02/17(金) 09:25:13.67ここは読んだか？
http://www4.atwiki.jp/fsharpmaster/m/pages/13.html
0614デフォルトの名無しさん
2012/02/17(金) 09:28:48.05Johan TibellのHaskell Performance Patterns talkのスライドも
このリストに追加の資料になりそう。
0615デフォルトの名無しさん
2012/02/17(金) 11:31:01.99全く同じとまでは言わないけど、
Haskellのtype ≒ Javaのclass
と考えたときに、
Javaのinterfaceがclassにまたがって横断的に制約を作れるというところが、
Haskellの型クラスがデータ型を横断して共通の「クラス」を作れるところ
と似てるって言ってるんじゃないの。
とりあえず最初の入り口から何でも違う違う言ってたら、誰もHaskell始められないよ。
0616デフォルトの名無しさん
2012/02/17(金) 11:43:00.28このスレを見て面白そうなので僕は今日から始めました。
0617デフォルトの名無しさん
2012/02/17(金) 12:42:29.71ということは、それはコンパイル時の解釈の問題ですよね
>>593 は
> オブジェクト指向の考え方は捨てるべき
と言っており、これはアプリケーションを作る指針となる考え方において、
抽象クラスとは違うことを言っているように思えます
もしそうなら、それに対する反論としての >>593 は的外れだと思います
>>583 も、わかればわかるけど、モナドはモナド則そのものは解りにくいと言ってることから、
入門レベル（最初の入り口）は通り過ぎているものと思われます。
> とりあえず最初の入り口から何でも違う違う言ってたら、誰もHaskell始められないよ。
それはそうですが、それとは別問題として、話が噛み合っていないような気がします
0618はちみつ餃子 ◆8X2XSCHEME
2012/02/17(金) 13:03:38.71部分的に機能がかぶるだけで類似性を見出していたのではそれに引き摺られて根本的なパラダイムの理解に進み難い。
0619デフォルトの名無しさん
2012/02/17(金) 13:25:22.45パラダイムみたいな高尚な概念じゃないよ
0620デフォルトの名無しさん
2012/02/17(金) 13:34:40.12一つも無ぇっつーの
0622デフォルトの名無しさん
2012/02/17(金) 14:17:39.16横レスだけど、
・オブジェクト指向のクラスもHaskellの型クラスも
「抽象データ型」の実現という意味では似ている(>>615)
・オブジェクト指向の「インヘリタンス」とHaskellの「アドホック型多相」とは
型システム理論という意味では全く違う(>>593)
ということじゃないのかな？
各用語の意味は、自分で調べてね
0623デフォルトの名無しさん
2012/02/17(金) 14:31:40.54OOPの「継承」は部分型多相では？
0624デフォルトの名無しさん
2012/02/17(金) 14:34:40.69オーバーライトや疑似変数selfなんてのは、部分型多相には存在しない概念/理論
0625デフォルトの名無しさん
2012/02/17(金) 14:46:11.83なるほど。型理論勉強します。
0627デフォルトの名無しさん
2012/02/17(金) 14:58:14.86型クラスにはアドホック型多相という理論的基盤があるから、
それはいわゆる「高尚」と表現してもかまわないんじゃまいかと思う
>>620
OOPの継承というのは直感的かつ曖昧なもので、その足場は非常に不安定
だからオブジェクト指向について１０人に尋ねれば、１０人それぞれが異なった解釈を返す
そんな代物を「高尚」とは、とても呼べないんじゃまいかと思う
0628627
2012/02/17(金) 15:10:40.81X: OOPの継承というのは....
O: OOPというのは....
0629デフォルトの名無しさん
2012/02/17(金) 15:18:03.49概念/理論は存在したり存在しなかったりするんだな・・・
それなら概念/理論を教えるよりも実装を教える方が良い
0630デフォルトの名無しさん
2012/02/17(金) 15:22:36.71・情報隠蔽
・継承
・ポリモーフィズム
でした
0631デフォルトの名無しさん
2012/02/17(金) 15:26:42.340632デフォルトの名無しさん
2012/02/17(金) 15:39:17.02>概念/理論は存在したり存在しなかったりするんだな・・・
え、オーバーライトや継承の概念を含む、いわゆる「継承の型システム」に関する理論は、
いくつか存在しているよ
足りないのは動的なメソッド結合(ダックタイピング)や動的な型付け(メタプログラミング)の理論
そんな完成した静的型付けな型システムの一つを実装したのがObjective-Caml
ただし、(Objective-CがOOとCのハイブリッド言語であるように)
部分型多相と継承は理論的に全く違うから、両者のハイブリッドになっている
結果として、残念ながら「関数型パラダイムにおけるオブジェクト指向」という理想には程遠い
0633632
2012/02/17(金) 15:41:17.07X: オーバーライトや継承の概念を含む、....
X: オーバーライトや疑似変数selfの概念を含む、....
0635632
2012/02/17(金) 16:17:42.90...orz
すぐに分かってくれたようだから、あえて訂正しないw
>>631
MLやHaskellでは、JavaやC++のようなNullPointerExceptionやBusErrorは発生しない
型に関するミスは、コンパイル時にすべて検出できる
それが、理論的背景のある型システムの「凄さ」だと言える
次のテストに出すかもしれないから、よく復讐しておくように
0636デフォルトの名無しさん
2012/02/17(金) 16:40:57.39むしろ、すべてに責任をもつことはできないから責任を限定する理論が必要になる
型に関するミス以外は管轄外だし
プログラマーが勝手に Nothing とか [] を使うのは自己責任
0637デフォルトの名無しさん
2012/02/17(金) 16:47:11.46昔のCOBOLはNULLが扱えなくて0000や9999などの値で成功失敗とか表現していましたし、そういうシステムはかなり多いと聞いています。
つまり、NULL無いんなら0000や9999でいいやと思うような人には型システムなんて意味ないんじゃないでしょうか？
0638デフォルトの名無しさん
2012/02/17(金) 16:56:36.58他パラダイムや他言語を矮小化する一方で、
「無秩序でいい加減な」という意味のアドホック多相を
あたかも高尚なものであるかのように
誇張しているだけだから、傲慢じゃなくて
滑稽だね。
0639デフォルトの名無しさん
2012/02/17(金) 17:06:52.05adv., adj. (特に)このために[の], 特別に[の], この場限りで[の], その場限りで[の].
研究社 新英和大辞典 第６版
0640デフォルトの名無しさん
2012/02/17(金) 17:20:15.570641デフォルトの名無しさん
2012/02/17(金) 17:21:05.170642デフォルトの名無しさん
2012/02/17(金) 18:09:29.51型クラスってのは代数的構造のことではないんでしょうか？
0643デフォルトの名無しさん
2012/02/17(金) 18:48:32.83そんなようなものだけどもうちょっと一般的
C aというインスタンスのメソッドの戻り値の型はa以外になり得る
OrdとかShowとか
0644デフォルトの名無しさん
2012/02/17(金) 18:57:33.81ヌルポは値に起因するバグで、型システムによる安全性の保証外なのはML系でも同じだよ。
MaybeはまんまC#のnullable<T>だし。
Haskellはパターンマッチでパターンを網羅してないとちゃんと警告出してくれたり、
Maybeモナドみたいな明示的にチェックを書かなくても済む仕組みその他諸々のおかげでバグりにくいって話で、
コンパイルで検出出来てるわけじゃないし、発生しないわけでもないよ。
0645デフォルトの名無しさん
2012/02/17(金) 19:12:32.81型クラスもデータ型もメモリ上のビットも代数的構造
0646デフォルトの名無しさん
2012/02/17(金) 19:24:43.410647デフォルトの名無しさん
2012/02/17(金) 19:29:54.49Maybeはぬるぽがっされないような、、、
0648デフォルトの名無しさん
2012/02/17(金) 19:43:26.86そういう文脈で代数的構造と言った場合の「代数的」とはどういうものですか？
0649デフォルトの名無しさん
2012/02/17(金) 20:02:36.22代入可能なこと
定数以外は代数的構造
0650デフォルトの名無しさん
2012/02/17(金) 20:55:05.10トリビアルな例だけど、常にJustな事が期待されてる変数alwaysJust :: Maybe aがあったとして、
1)
case alwaysJust of --これは警告がでるけど
Just x -> x
2)
let (Just x) = alwaysJust in x -- こんなドタコなコードは書かないけど…
3)
-- fooの使用者からは定義かドキュメントを見ない限り、例外が上がってくる可能性がある事は知りようがない
foo :: a -> a
foo v = fromJust $ do -- fromJustってどういうケースで使うんだろか…。
x <- alwaysJust
v' <- Just v
...
return v'
もし、alwaysJustがバグっててNothingだったら、上の例は全部例外あげてくる。
特に3番目みたいな外からは一見安全に見える型の関数でも、ガッされない絶対の保証があるわけでも、検出できるわけでもないよ。
（1番目以外は警告すらでないし）
Maybeからそれると、Preludeの関数でもListのheadとか(!!)とか、Enumのsucc、predとかreadやArrayとか、
プログラマがちゃんと保証しなきゃいけない関数も結構あるし。
0651デフォルトの名無しさん
2012/02/17(金) 21:29:13.08オーバーフローして意図しない挙動をする危険性があるから
プログラマがちゃんと保証（ｒｙ
0652デフォルトの名無しさん
2012/02/17(金) 21:31:32.72あしたRWHを一日かけて読み切ります
何か注意点とかありますか
■ このスレッドは過去ログ倉庫に格納されています