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

**デフォルトの名無しさん** · 2025/10/09(木) 02:23:13.64

>>676
確かにメモリ管理が必要な手続き型言語全般というのは広げすぎたかもしれない。
静的な配列を関数内で作ってポインタを返す形で作ると関数を抜ける際に配列の寿命が尽きる。
（通常、それを避けるために結果を格納するためのポインタを引数で渡す）

C言語で関数型言語のmap関数みたいな配列を返す関数が作れるか?と考えると動的に作って、使い終わったら解放する形になるのかなと。
ここへの書き込みが長すぎると怒られたので削除したが、構造体で包むという案も考えた。
値渡しだからコピーコストがかさむ。
参照渡しだと生の配列と同じ寿命の問題に突き当たる。

**デフォルトの名無しさん** · 2025/10/09(木) 10:26:59.37

>>677
>値渡しだからコピーコストがかさむ。
コンパイラの最適化で不必要なコピーは消える
C言語でもそういうことは当たり前にやってる

**デフォルトの名無しさん** · 2025/10/09(木) 11:59:08.62

仕様化されてるっけ
コンパイラの実装次第だと怪しい

**デフォルトの名無しさん** · 2025/10/09(木) 17:36:59.11

Cに何を求めてんだよｗ

**デフォルトの名無しさん** · 2025/10/09(木) 17:53:09.88

OS開発ですね。メモリも割り込みも何でも見えてしまい、扱わないといけません

**デフォルトの名無しさん** · 2025/10/09(木) 18:19:20.69

>>678
にゃんと！？
それを押してもいざ実装してみたら
構造体で配列を包む場合、あらかじめ配列の長さを決めないといけなかった。

struct {
　　　　int array[1024];
　　　　int size;
}typedef Array;

この1024とかも余分な分は最適化で無くなるっていうなら10万位要素があっても大丈夫なように1GB位（見かけ上）確保したいが、そうでないなら大体の場合、無駄な領域を確保してることになる。

**デフォルトの名無しさん** · 2025/10/09(木) 18:28:04.54

>>678
ん、まてよ？
最適化で不要なコピーは消えるって言っても、関数プログラミングのmap関数と同じ動きなら、参照元の値は変わったらダメなので参照渡しされたら困るんだが、どんな最適化でコピー（値渡し）で無く、かつ参照渡しでもない状態ってどんな状態?

**デフォルトの名無しさん** · 2025/10/09(木) 19:31:35.47

Haskellは遅延評価だからmapが配列を返してると言えるかあやしい

一般的な関数型言語だと末尾再帰で不必要になる値を再利用（上書き）する
あと値が変更されない（immutable）なら参照渡しで共有しても問題ないし
共有するためにimmutableにすると言っても過言ではない

**デフォルトの名無しさん** · 2025/10/09(木) 19:50:16.02

>>684
うん、遅延評価だから基本参照を返してるはず。バード本参照
（なので>>668を書いてみたわけで）

immutableなら

a = [1..4]
b = map (+1) [1..4]
print a
print b

とうコードで

output:
[0,1,2,3,4]
[1,2,3,4,5]

になるはず。
Cで参照を共有すると

[1,2,3,4,5]
[1,2,3,4,5]

という困った表示になってしまう。
というかHaskellでも生のリスト[0..4]とmap (+1) [0..4]は参照を共有してない。
共有してるのは[0..4]だけ。
（むしろ共有してないからこそ「富豪プログラミング」とか言われる）

**デフォルトの名無しさん** · 2025/10/09(木) 20:01:16.79

言ってみればHaskellは新しい参照をどんどん生み出して、不要になった参照はガンガンGCする。
Cはそういうプログラミングには（当たり前だが）向かないし、当たり前にCの方が効率は良い。
人間が書くコードはHaskellみたく数学に近いほど短くなる。
どっちが良いとかじゃなく、何を優先するかという話。
（なのだなぁと、Cでmap関数もどきを書いて再確認した）

**デフォルトの名無しさん** · 2025/10/09(木) 20:33:26.39

ループ書こうぜ

**デフォルトの名無しさん** · 2025/10/09(木) 21:58:50.95

>>682
「ジェネリック等の抽象化機構を備えた言語であれば～」のところ全然理解してなかったのな

>>683
言語の仕様上は値渡しだけど実際にわざわざコピーして渡す必要がない状況ならコンパイラが最適化してコピーしないマシンコード(コピーして渡すのと同じ結果になるマシンコード)を生成するという話
異なるレイヤーを混同してることに気づいてくれ

あとHaskellのリストは配列じゃないよ

**デフォルトの名無しさん** · 2025/10/10(金) 05:32:34.82

Haskellを勉強したけど何に使えばいいのか分からない
関数型プログラミングで難しい割に、速度が出ないことがわかっているやっぱり速度は正義だろ

**デフォルトの名無しさん** · 2025/10/10(金) 07:17:31.85

>>688
ジェネリックはそのうちC++なりJavaなりで試すけど、まだ試してもいないので…。

最適化の方はもうちょい具体的に教えて欲しいかも。
x = 2 * 100を x = 200にするみたいなのは知ってるけど、あんま詳しくない。

**デフォルトの名無しさん** · 2025/10/10(金) 07:21:42.77

>>689
今のHaskellは（中の人がMSに勤め始めてから）C#並みに速くなってるけど、GUIライブラリとか軒並み遅い時代に開発が止まってる…。
しいて言えばYesod使ってWebアプリかな？
Mac（Appleシリコン）版があるからiOSアプリのロジック部分とかも行けそう。

**デフォルトの名無しさん** · 2025/10/10(金) 20:26:02.07

【移民】　は努力もせずに日本の豊かさを手に入れる
https://medaka.5ch.net/test/read.cgi/kankon/1759822097/l50

**デフォルトの名無しさん** · 2025/10/11(土) 22:42:46.58

22 template <typename T>
23 vector<T> map(function<T(T)> f, const vector<T> arr){
24 vector<T> temp;
25 for(auto i : arr) temp.push_back(f(i));
26 return temp;
27 }

**デフォルトの名無しさん** · 2025/10/11(土) 22:43:04.64

C＋＋で書いてみた。
今回は値渡しにしたけど、本当に最適化でコピーにならないようにできるのかな…。
そもそもどうやってそれを確認するんだろう?
本当なら参照渡しがほぼ要らなくなるけど。
そして、例によって参照渡しだと>>668やコードこそ書いてないがCで一般的な>>677のカッコ内に書いた（通常、それを避けるために結果を格納するためのポインタを引数で渡す）になる。

コードにするとこう。
（Haskellerなのでmapにしたけど、C++だとmapって連想配列なのね。失敗した…）

void map(vector<int>* input, vector<int>* output);

配列と比べて長さを引数に渡さないで良くなるのと、realocしなくても長さを変更できる点が進化しているが。