トップページ⇒tech
1001コメント325KB

関数型プログラミング言語Haskell Part12

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/04/29(木) 19:15:28
haskell.org
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/
・2chの仕様により、行頭の半角スペースは表示されません。
　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。
0446デフォルトの名無しさん2010/06/10(木) 16:41:43
>>445
それは頭悪そう
0447デフォルトの名無しさん2010/06/10(木) 16:46:22
HaskellではCで考えられないようなプログラムを書くことができる
0448デフォルトの名無しさん2010/06/10(木) 16:51:54
時間の単位が距離の単位になるくらい超越的なんだろう
0449デフォルトの名無しさん2010/06/10(木) 17:08:50
>>448
近代物理学の自然単位系では、時間と距離とを区別しない
約30万km ＝ 1秒
1光年　＝　1年
0450デフォルトの名無しさん2010/06/10(木) 22:35:56
haskellのAKB48はCのモーニング娘。に相当する。
0451デフォルトの名無しさん2010/06/10(木) 23:33:56
Haskellが地球ならCは火星でLispは宇宙そのものだ。
0452デフォルトの名無しさん2010/06/10(木) 23:54:19
テラフォーミング言語C
0453デフォルトの名無しさん2010/06/11(金) 00:32:38
Haskellの関数はCのポインタに相当する。

Cの利点:
* ポインタを使って、関数を関数の引数にできる
* 関数ポインタに自由に四則演算をすることができる
* 型キャストが容易。関数型をlong型にすることもできる

Haskellの欠点:
* ポインタがないので、関数を特別なファーストクラスオブジェクトにしなくてはならない
* 関数に自由に四則演算をすることはできない
* 型キャストはない
0454デフォルトの名無しさん2010/06/11(金) 00:36:12
それ欠点なのかw
0455デフォルトの名無しさん2010/06/11(金) 00:44:27
>>453
おい、初心者の就職活動みたいな事すんなよ
0456デフォルトの名無しさん2010/06/11(金) 12:43:34
関数に演算できるだろ。
0457デフォルトの名無しさん2010/06/11(金) 12:46:56
Haskell の関数に四則演算はできんと思ってたんだが、できるのか？
0458デフォルトの名無しさん2010/06/11(金) 12:52:37
Cでもできないはずだが、どうだろうか？掛け算や割り算って何だ？
0459デフォルトの名無しさん2010/06/11(金) 13:04:37
関数ポインタにはできないね
0460デフォルトの名無しさん2010/06/11(金) 14:25:17
和 f +++ f
積 f *** f

差と商はどう定義しよう
0461デフォルトの名無しさん2010/06/11(金) 15:23:21
積 f***g = \x-> Just x >>= f >>= g
和 f+++g = \x-> Nothing `mplus` f x `mplus` g x
0462デフォルトの名無しさん2010/06/11(金) 15:55:16
additive inverseを関数に対して定義する…だと？
0463デフォルトの名無しさん2010/06/11(金) 16:00:51
>>461
というか、MonadPlusが「和」を定義するクラスなんだが
0464デフォルトの名無しさん2010/06/11(金) 16:07:56
>>462
fが成功かつgが失敗のときf-gが成功
0465デフォルトの名無しさん2010/06/11(金) 18:49:39
Arrow とか ArrowChoice を持ってくるのが無難なのかな
0466デフォルトの名無しさん2010/06/11(金) 18:56:15
ArrowでModuleを作るのかー頑張れとしか良いようがないな
色々と制約を追加してModuleを構成できるArrowってのを考えるのが楽か
Arrowそのものが抽象だから具体例を考えなくてもいいし
0467デフォルトの名無しさん2010/06/11(金) 19:14:51
Haskellなんだから積と和はやはり直積・直和にもとづいて定義したい。

* :: (S1 -> T1) -> (S2 -> T2) -> (S1,S2) -> (T1,T2)
(f * g) (x1,x2) = (f x1, g x2)

+ :: (S1 -> T) -> (S2 -> T) -> (S -> T)
where data S = Inl S1 | Inr S2
(f + g) x = case x of { Inl y -> f y; Inr y -> g y }

和がHaskellの構文でうまく書けないけど
0468デフォルトの名無しさん2010/06/11(金) 19:20:01
ていうか関数ポインタの演算ってそんなものじゃないし
0469デフォルトの名無しさん2010/06/11(金) 19:30:34
どんなの？
0470デフォルトの名無しさん2010/06/11(金) 19:50:14
>>467
それは命題論理に対応するっていう話で、代数系じゃないでしょ
0471デフォルトの名無しさん2010/06/11(金) 20:14:04
Prologは述語論理でHaskellは命題論理なの？
0472デフォルトの名無しさん2010/06/11(金) 20:19:25
>>471
Haskellはそもそも論理型じゃないし
0473デフォルトの名無しさん2010/06/11(金) 20:33:31
>>470
CCC+直和が代数系でない？
0474デフォルトの名無しさん2010/06/11(金) 20:33:38
forallがあるから述語論理だろ
でtype of typeができないから二階じゃない
0475デフォルトの名無しさん2010/06/11(金) 20:50:44
なんかよくわからんけど、
RankNTypes拡張を有効にしたら
高階論理なんじゃないの？
0476デフォルトの名無しさん2010/06/11(金) 21:43:14
Curry-Howard 対応様が見てる
0477デフォルトの名無しさん2010/06/11(金) 22:14:43
二値じゃないから論理じゃないだろ
0478デフォルトの名無しさん2010/06/11(金) 22:21:30
関数プログラミングの楽しみっていう本、どこの本屋に行ってもないんですが
7年前の本なんですよね？
絶版したんでしょうか？
0479デフォルトの名無しさん2010/06/12(土) 00:15:57
ttp://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06805-8

近日発売中？
0480デフォルトの名無しさん2010/06/12(土) 00:45:08
>>477
お前の中では論理っていうと二値論理のことなのか？
0481デフォルトの名無しさん2010/06/12(土) 01:14:02
>>479
この本ずっと待ってんだけど６月下旬らしいね
0482デフォルトの名無しさん2010/06/12(土) 10:09:42
>>442
大学を思想的に侵略して関数型言語以外はクズという主義を学生に叩き込もうぜ
0483デフォルトの名無しさん2010/06/12(土) 10:27:19
その前に関数型言語の定義をめぐって内ゲバしないと
0484デフォルトの名無しさん2010/06/12(土) 12:21:48
Lispは関数型言語かどうかで死闘をくりひろげるわけですね
0485デフォルトの名無しさん2010/06/12(土) 12:24:41
世間一般ではともかく、今時大学で Lisp を関数型扱いしてたら相当の時代遅れだろう
0486デフォルトの名無しさん2010/06/12(土) 12:32:16
関数型言語の歴史を知っている人間ならLISPが関数型言語だというのは明らか
0487デフォルトの名無しさん2010/06/12(土) 13:42:09
マルチパラダイムとお呼び！
0488デフォルトの名無しさん2010/06/12(土) 14:03:07
yes, sir!
0489デフォルトの名無しさん2010/06/12(土) 16:11:17
lispって型にはまらない言語なんだから、
枠にはめて考えること自体合わないんだと思うよ。
今じゃマルチパラダイムになってるからね。

型にハメる系統と対照的だといえるよ。
0490デフォルトの名無しさん2010/06/12(土) 16:26:08
ラムダ計算の筆記用として考え出されたのがLISP
関数型言語はラムダ計算の応用だからLISPは関数型言語
0491デフォルトの名無しさん2010/06/12(土) 16:34:34
> ラムダ計算の筆記用として考え出されたのがLISP

嘘ですね

> 関数型言語はラムダ計算の応用だからLISPは関数型言語

前件が意味不明です
0492デフォルトの名無しさん2010/06/12(土) 17:58:43
LISPは関数型言語ではない
LISPマシン専用言語だ
0493デフォルトの名無しさん2010/06/12(土) 18:33:42
>>491
あなたがウソですね
0494デフォルトの名無しさん2010/06/12(土) 20:19:19
関数型言語の元祖はlispだが、現代の関数型言語とは似て非なるものだ。
自転車や自動車、それに八つ橋などの例をみても、元祖が子孫と違うのは珍しくない。
関数型言語でも同様のパターンがあると考えるのはごく自然な発想だ。
0495デフォルトの名無しさん2010/06/12(土) 20:23:06
>>489
>型にハメる系統と対照的だといえるよ。
Haskellのことを言っているのであれば、これは少々不適切な表現だ。
Haskellはデータを既存の型にはめるだけではない。
プログラマが型を積極的に定義することを許しているのだから、型を使う言語と言ってほしい。
0496デフォルトの名無しさん2010/06/12(土) 20:25:29
Lispを関数型言語ではないというのは、黎明期の巨大携帯電話をmobileでないというようなもの。
0497デフォルトの名無しさん2010/06/12(土) 20:27:34
型から自由であろうと企てた結果、unsafeになって拡張できなくなってしまうのは残念なこと。
初心者にありがちな失敗コースです。
0498デフォルトの名無しさん2010/06/12(土) 20:32:39
チャーチルの戦車も、現代人には奇抜に見えるが戦車です。
http://obiekt.hp.infoseek.co.jp/t72/genesis1.html
0499デフォルトの名無しさん2010/06/12(土) 20:39:46
Lisp は純粋関数型じゃないって事で
Lisp はパラダイム非依存のパラダイス言語です
0500デフォルトの名無しさん2010/06/12(土) 20:42:25
数学も、もともと測量学だったものが長い歴史を経て純粋な神学になったんだから、歴史はより速く繰り返されるものです。
0501デフォルトの名無しさん2010/06/12(土) 20:48:41
>>499
というか、lispのパラダイムにはsyntactic abstraction(構文抽象）という名前があるんだよ
0502デフォルトの名無しさん2010/06/12(土) 20:55:54
言われてみれば測量学とラムダ算法って似たようなもんだな
具体的なものから抽象的な概念に進歩していくのか
0503デフォルトの名無しさん2010/06/12(土) 21:06:51
構文抽象は S 式と繋がりが強過ぎてパラダイムって感じはしないな
0504デフォルトの名無しさん2010/06/12(土) 21:18:08
関数型言語の始祖はC言語の関数へのポインタ
0505デフォルトの名無しさん2010/06/12(土) 21:20:01
Cの可変個の引数(printf)とコールバック
0506デフォルトの名無しさん2010/06/12(土) 21:24:41
真祖はstack winding
0507物理っぽく言ってみた2010/06/12(土) 21:31:18
古典的関数型言語（関数型言語の古典論）＝
現代関数型言語（より良い理解のために）＝
0508J. M.2010/06/12(土) 21:46:05
どうしよう。
「ただ、リストの再帰処理が書ける言語が欲しかっただけ」
といい出せない雰囲気…
0509デフォルトの名無しさん2010/06/12(土) 21:56:27
ジョン万次郎か
0510デフォルトの名無しさん2010/06/13(日) 02:39:41
Haskellは数値計算やシミュレーションには向かないのでは？
と書いてあるのをどこかで見た気がします。
これは本当でしょうか？
0511デフォルトの名無しさん2010/06/13(日) 02:46:34
そのようなことはありますん。書いた人に聞くか、どこに書いてあったかを示して下さい。
0512デフォルトの名無しさん2010/06/13(日) 06:29:39
>>510
まあ、Haskellに詳しくない人は、シミュレーションをどうやってモデリングすべきか見当もつかないかもしれないね
0513デフォルトの名無しさん2010/06/13(日) 07:27:25
haskellで速いプログラムを書くコツとかわからないもんね。

副作用がないってのがメモリは食うし遅いという印象があるのかも
0514デフォルトの名無しさん2010/06/13(日) 07:46:20
>>510
きれいなやり方が見当たらないときは、きたないやり方も許されます
詳しい人はそれを知っているので、数値計算もシミュレーションもこわくない
0515デフォルトの名無しさん2010/06/13(日) 09:11:15
C++みたいだな
0516デフォルトの名無しさん2010/06/13(日) 10:01:07
>>510
SoftwareDesignでnobsunが書いた記事でしょ。
Haskellはクソ遅いからシミュレーションみたいなパワーがいる処理には向いてないよｗ
0517デフォルトの名無しさん2010/06/13(日) 13:26:57
布教屋さんがそう言ってるのか、
0518デフォルトの名無しさん2010/06/13(日) 13:47:06
>>517
nobsunが言っているのは、我々が感じているのと同様に
reactiveなプログラミングをするのが非常に煩雑になってしまうというところ。
シミュレーションは物によるけど、決まったタイミングで処理をするもの、
例えばアニメーションとかは書きにくいね。
現在YampaなどFRPライブラリが作られてはおり、
reactiveなプログラミングを支援しようという動きはあるが、
あまりわかりやすくプログラミングできるとはとても言い難い。

そしてさらに誰がいおうと、HaskellはCと比べて明らかに遅い。
0519デフォルトの名無しさん2010/06/13(日) 14:01:16
まぁ、これからに期待だね
0520デフォルトの名無しさん2010/06/13(日) 14:08:09
しかし、関数型言語でも並行処理を利用すればオブジェクト指向設計（より強力な設計が可能）
を置き換える事が可能だと思う。
だからオブジェクト指向で有利なreactiveなプログラミングも関数型言語で簡単にできるようになると思う。
0521デフォルトの名無しさん2010/06/13(日) 16:22:15
線形型をもつATSはCに匹敵するパフォーマンスを出せるが
記述量もCと同等以上かつ大抵の人には読めない…
やっぱC++でHaskellっぽく書くというところで妥協するしかないのか
0522デフォルトの名無しさん2010/06/13(日) 17:46:29
CやC++なんて、言って見たらマシン語そのままみたいなもんだからね。それ超えようってなら、
勝手にアルゴリズムを推論して書き換えちゃうくらいじゃないとどうにもならないんじゃないの。
0523デフォルトの名無しさん2010/06/13(日) 18:00:22
>>522
何言ってるんだ？
0524デフォルトの名無しさん2010/06/13(日) 18:02:54
C++って「高級アセンブラに継ぎ接ぎだけど型レベル言語くっつけました＾＾」みたいなものだろ。
0525デフォルトの名無しさん2010/06/13(日) 18:07:46
継ぎ接ぎといえどTemplate Haskellよりまとも
0526デフォルトの名無しさん2010/06/13(日) 18:20:49
>>522
いや、CPUアーキテクチャの違いを吸収してくれるのは大きい。
小さなパフォーマンスコストでポータブルなコードを書けるんだからな。
0527デフォルトの名無しさん2010/06/13(日) 18:40:10
アーキテクチャまで掘って話すことは今の話の文脈では脱線だと思うが。
0528デフォルトの名無しさん2010/06/13(日) 19:07:06
アーキテクチャの話はしてないだろ。
高級言語がアーキテクチャの違いを吸収してくれると言っているんだから。
0529デフォルトの名無しさん2010/06/13(日) 19:24:02
でもね。ダイナミックプログラミングとか
必要な計算ならhaskellは得意だと思うんだけど。
0530デフォルトの名無しさん2010/06/13(日) 20:55:39
つか、Cと勝負しなくていいだろ。
Javaに勝てれば十分。
0531デフォルトの名無しさん2010/06/13(日) 21:04:33
HaskellはJavaよりスペース的には有利なはずだが。
しかし遅延評価だからスペースリークが怖いな
0532デフォルトの名無しさん2010/06/13(日) 21:45:35
スペースリークって、やっぱコンパイラによって違ってくるの？
たとえばスペースリークが出ないようにソースを調整したのに、
べつのコンパイラでコンパイルしたら出ちゃったとか。

それとも、共通したテクニックで防げるものなの？
0533デフォルトの名無しさん2010/06/13(日) 22:04:45
そりゃコンパイラによって違ってくるでしょ。
馬鹿な例だけど例えば必ずリークするコンパイラ作ってそれでコンパイルすればリークするし。
0534デフォルトの名無しさん2010/06/13(日) 22:06:29
>>532
程度の差はあるだろうが、基本的な考え方は同じでいけるはず。
Haskell でのスペースリークってのは要は遅延させた仕事がたまっていっぱいいっぱいってことだから。
それがないように注意深く調整すればいいって話。
0535デフォルトの名無しさん2010/06/13(日) 22:06:40
>>532
call by need簡約だけ想定してスペースリークを潰せば実用上問題ない
0536デフォルトの名無しさん2010/06/13(日) 22:36:10
メニーコアCPUな時代になって、すごく賢く自動的に並列化されるようになれば、
「Haskellで書くより速いプログラムをCで書くなんて非現実的な苦行」と言われるようになるかもしれない。
というか、なってほしい。
0537デフォルトの名無しさん2010/06/13(日) 22:41:55
Haskellが教えてくれたこと

純粋関数型言語だから自動並列化が簡単になるわけではない
0538デフォルトの名無しさん2010/06/13(日) 22:48:02
FRP の実装方法のひとつで、Fruit ライブラリなんかが使ってたと思うけど、
単調増加的に刻一刻と変化する「現在時刻」の列を無限リストで表現する方法があるよね。
[t0, t1, t2, t3, .....] みたいな。

ああいう無限リストで表現された現在時刻をつかってアニメーションなんかさせる場合、
リストの既に消費した部分（先頭の方）はちゃんと GC で回収されるものなの？

そのようなリストの要素は一度参照されればもう二度と参照されないことは
プログラムソースの全体をちゃんと見れば分かることだけど、
そういう事をコンパイラに期待しても良いものなのか、ちょっと心配になる。
0539デフォルトの名無しさん2010/06/13(日) 22:54:12
あ、Fruit じゃなくて Fran か
0540デフォルトの名無しさん2010/06/13(日) 23:06:00
無限リストの頭を次々に読み捨てていくような処理なら、間違いなく回収してくれるよ
0541デフォルトの名無しさん2010/06/13(日) 23:10:01
そうなのか、安心した。

けっこう賢いんだな
0542デフォルトの名無しさん2010/06/13(日) 23:17:07
特にコンパイラが賢いことをしてる訳じゃなくて、実行時に普通のGCが走査してるだけだけどね
0543デフォルトの名無しさん2010/06/14(月) 00:11:45
最後にts' - (head ts)で処理時間を返すとかしてなければおk
0544デフォルトの名無しさん2010/06/14(月) 00:13:58
>>532
どのコンパイラでも、中間コードを生成するオプションを使ってコードを追えば、明らかにヤバい部分は回避できる
0545デフォルトの名無しさん2010/06/14(月) 00:26:55
>>543
なんで？

この ts' ってのはたぶん最後に取得した時刻の事だよね。
head ts は捨てられないけど、それ以降から ts' までは要らないから、
GC で回収されるんじゃないの？

つまり ts = [t0, t1, t2, t3, ... tn-1, tn] で処理が完了したなら、
tn - head ts としても t1 や t2 などは明らかに要らないよね（参照されないから）。
それでも回収できないの？
■ このスレッドは過去ログ倉庫に格納されています