関数型プログラミング言語Haskell Part34 (677ﾚｽ)
上下前次1-新
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
655: 01/22(水)01:14 ID:SDQT/604(1) AAS
3万も出してよもうとは思わない。
目次読むとKleisli tripleの節はあるのにKleisli categoryの節がなかったり、なぜかその後にMoggi's theoryが出てきたりと
少なくとも構成があんまりいい感じはしない。
656: 01/22(水)03:57 ID:ydcqGqD9(1) AAS
まぁ圏論はHaskellやるうえで無駄だしな
657: 01/23(木)21:00 ID:j8NlocC3(1) AAS
しかもHaskell自体やるだけ無駄だしな
658: 02/13(木)07:10 ID:NHs8kkcw(1) AAS
wikiでghc見たら、中の人MSリサーチにいるのな。
最近C#並みに速くなったと思ったら、そういう事か。
納得。
659(1): 02/13(木)13:53 ID:LmH89MFs(1/2) AAS
暗記系の問題が嫌われるのは答えを隠す意味がないからだが
逆に陰謀論が大人気なのは、隠蔽する動機があるからかもしれない
660: 02/13(木)19:59 ID:8vmF21CT(1) AAS
>>659
誤爆か？
次から気をつけな
661: 02/13(木)21:57 ID:FvaixK+o(1) AAS
わざとだろ。
数板に延々スレ違を書き込む基地外がいるが多分そいつと同一。
662: 02/13(木)22:11 ID:LxUFvhMj(1) AAS
ワードサラダくん数学板にもいるんか
まあいそうな板だな
663: 02/13(木)23:39 ID:LmH89MFs(2/2) AAS
有意味な事実と有意味なデマを隔離するのは難しいらしい
だが、真でも偽でもないナンセンスはなぜか瞬時に判断できる
664: 03/19(水)11:03 ID:JUfTLTVZ(1) AAS
IntSetのsizeがO(1)じゃなくO(n)なのはなぜですか、O(1)で実装できそうなもんですが
665: 03/19(水)19:45 ID:4qyoYSYb(1) AAS
unionとかで重複要素数えるのが面倒だから必要になるまで数えない
666: 03/19(水)20:51 ID:S6mpqhEQ(1/2) AAS
私は最強ーーすき
667: 03/19(水)20:52 ID:S6mpqhEQ(2/2) AAS
誤爆ｽﾏｿ。懐メロチャンネルと間違えた
668(2): 10/08(水)08:47 ID:66xUgFQM(1/2) AAS
int* map(int (*f)(const int), const int* array, const int n){
int* p = malloc(sizeof(int) * n);
for(int i = 0; i < n; i++) p[i] = f(array[i]);
return p;
}
ふむ、メモリ管理が必要な言語が（見かけ上）副作用のない関数を作ろうとしたら配列を返す関数の時点で関数を使った後は必ずメモリの開放が必要になるのか。
開放が必要だから、参照を持つためにポインタへの保存が必須なので、関数の連続適用（関数合成）は絶望的。
これじゃ、GCやRustみたいな仕組みが必要になるわけだ。
669: 10/08(水)10:40 ID:qRy2t+J8(1) AAS
Cで副作用はいうてらんないね。マルチスレッド、再入可能にするところまで出来れば上出来
670(1): 10/08(水)13:07 ID:4LSFWHe4(1) AAS
>>668
30点の理解
671(2): 10/08(水)14:05 ID:JTvRYaZp(1) AAS
GC言語はGC使ってる時点で副作用あるやんｗ
メモリ管理他人任せにしてるだけだ
672: 10/08(水)17:42 ID:1ctt2fBW(1) AAS
>>671
−30点
673(1): 10/08(水)18:32 ID:66xUgFQM(2/2) AAS
>>670
100点満点のご高説をどうぞ。
長文になっても良し。
>>671
実は純粋関数型言語の定義は「副作用も含めて参照透明性が破れていない」なのです。（Wiki調べ）
print関数やgetLine関数はどう見ても副作用有るでしょう?
でも、モナドのお陰で参照透明性は破れてないんですよ。
674: 10/08(水)18:44 ID:N7mcxj5n(1) AAS
副作用は隔離スレへ
675: 10/08(水)18:45 ID:HFQA1hQ+(1) AAS
なるほどモナドと書き込めばこのスレで副作用の話もできるのですね
676(1): 10/08(水)23:41 ID:jkiZK6Mq(1) AAS
>>673
ゴールがわからないので100点のご高説は無理だが30点の理由は説明しといてあげる
C言語という特定の言語実装における制約がメモリ管理が必要な言語全般に対しても当てはまると考えてるのが根本的な間違い
>配列を返す関数の時点で関数を使った後は必ずメモリの開放が必要になるのか。
>>668のコードで(明示的な)メモリ解放が必要になるのはヒープに動的にメモリをアロケートしたからであって配列を返すからではない
C言語では配列がfirst classではないので配列をそのまま返すことは不可能
C言語でも構造体ならfirst classなので配列という概念を表現した構造体を作って静的配列を返すようにすれば(明示的な)メモリ開放は不要
C言語にはないがジェネリック等の抽象化機構を備えた言語であれば静的配列を使って任意長の配列に対するmap関数も書ける
>開放が必要だから、参照を持つためにポインタへの保存が必須
動的にアロケートするものは実行時になるまで必要なメモリサイズがわからないから言語に関係なくポインタ的なものでしか表現しようがない
動的にアロケートしたものだからポインタが必須、ヒープに動的にアロケートしたものだから後で(明示的な)開放が必要なのであって、開放が必要だからポインタへの保存が必須という因果関係ではない
677: 10/09(木)02:23 ID:j1OYGPg+(1) AAS
>>676
確かにメモリ管理が必要な手続き型言語全般というのは広げすぎたかもしれない。
静的な配列を関数内で作ってポインタを返す形で作ると関数を抜ける際に配列の寿命が尽きる。
（通常、それを避けるために結果を格納するためのポインタを引数で渡す）
C言語で関数型言語のmap関数みたいな配列を返す関数が作れるか?と考えると動的に作って、使い終わったら解放する形になるのかなと。
ここへの書き込みが長すぎると怒られたので削除したが、構造体で包むという案も考えた。
値渡しだからコピーコストがかさむ。
参照渡しだと生の配列と同じ寿命の問題に突き当たる。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.028s