関数型プログラミング言語Haskell Part34 (667ﾚｽ)
上下前次1-新
459: 2024/10/03(木)22:10 ID:/brOvmjG(1) AAS
おそらくメンタルヘルスに問題がある方なのかな？
自分の頭の中の映像をそのまま言葉にしたような感じを受ける
460(2): 2024/10/04(金)05:46 ID:vLDssEdm(1/9) AAS
>>428
Haskellの副作用については2つの解釈がある。
１．副作用も含めてアクションという単位で値としてみる。
（アクションを受け取って、アクションを返す関数）
２．Haskellは指示書を発行しているだけで、実際に実行するのは数学（Hakell）の外だから、Haskellそのものには副作用が無い。
（（末尾にHaskellに値を返す形の）マシン語を返して、ハードウェアに実行してもらうと考えるアウトソーシング方式）
461(1): 2024/10/04(金)05:52 ID:EogKDI3R(1/3) AAS
>>460
ようするに副作用はないってことじゃん
462(1): 2024/10/04(金)05:57 ID:vLDssEdm(2/9) AAS
>>461
Javaは変数をクラスの外で作れないから、グローバル変数は存在しない。
けど、事実上のグローバル変数は作れてしまう。
ってのと、同じ。
アクションの中に副作用があろうが、マシン語を返していると解釈しようが、事実として副作用はある。
ただ、重要なのは副作用を伴っても参照透明性が保たれているってこと。
463: 2024/10/04(金)06:07 ID:4jD3Hbcp(1) AAS
副作用が隔離できていることが大切
スレの基地外の隔離スレのように
464(1): 2024/10/04(金)06:24 ID:EogKDI3R(2/3) AAS
>>462
それは例えばwhileプログラムから副作用のない言語に変換したあとの形式と同じ状態にすでになってるってことで、計算のルール上はもう副作用はないでしょ
465(1): 2024/10/04(金)07:22 ID:vLDssEdm(3/9) AAS
>>464
そうなんだけど、結局普通のプログラミング言語を使ってる人にしてみれば屁理屈でしかない。
見た目そのままで伝えるなら、純粋関数型言語の定義のまんま、「副作用を伴っても参照透明性が保たれている」でいい。
466(1): 2024/10/04(金)07:38 ID:EogKDI3R(3/3) AAS
>>465
まあそのほうがいいか
上の方にいた彼はなんか脳内にこだわりがあって、普通の型付きラムダ計算以上のことをやってると思ってるフシがあったね
467: 2024/10/04(金)07:48 ID:vLDssEdm(4/9) AAS
>>466
そうそう。
副作用は無い！って、こっちが必死になって弁を述べれば述べるほど、屁理屈感が出てくる。
それよりは副作用を認めて、「副作用を分離」「副作用を伴っても参照透明性が保たれている」って言った方が、納得感がある。
468: 2024/10/04(金)19:23 ID:tixO3LDq(1/22) AAS
とりあえず続きを書いてみる。
Haskellでいうところの
純粋関数は、valueからvalueへの数学的関数
入出力プログラムは、valueから（入出力）computationへの対応
に割り当てることで、数学上にプログラミング行為を写し出せそうだ、というところまで書いた。
ただ、やっぱり（入出力）computationって何？とか、valueと形式的にどう違うの？という疑問は拭い去ることができない。
そこでMoggiは、次のようなアイディアを２つ出して（結構ムリヤリに）疑問を解決した。
ただし、ここで入出力プログラム prog は A型の引数を取って（computationの整理をする前は）B型の返り値を返すとする。
469: 2024/10/04(金)19:23 ID:tixO3LDq(2/22) AAS
Moggiのアイディア１
・返り値の型がBのcomputationは、何か型構築子をIOとすると、その型構築子を適用した型 IO B のvalueに対応する。
※Moggiの原理ともいう。
つまり、上で挙げた入出力プログラム prog の型は、具体的に A → IO B になると言っている。
IO B 型の実装で、入出力の予約だか、値のリストだか指示書だか表現はいろいろあるが、そういう機構を実装すれば、
prog :: A → IO B
は参照透過性を保ったまま入出力を行うプログラムになる。
もっと広がりが出そうなcomputation概念なのに、急に狭窄な感じがするアイディアだけれど、
実装と折り合いをつけるという観点からすると仕方ないともいえる。
なお、代数的効果のPlotkinとPowerが批判しているのはこのMoggiのアイディア１である感じがする（あんまわかってない）。
470: 2024/10/04(金)19:24 ID:tixO3LDq(3/22) AAS
Moggiのアイディア２
・入出力プログラム（に対応する数学的概念）は、圏をなすはずだ。
Moggiのアイディア１の段階でもprog :: A → IO Bは参照透過性を保ったまま入出力を行うプログラムになるはずだが、
入出力プログラム同士の合成が考えられていない。入出力プログラム prog1、prog2と開発したら、できるだけ再利用するというのが
現実のプログラミングだと思う。わざわざprog1とprog2の合成として定義できそうなプログラムを得るために、イチイチいちから
開発するということを理論的に要請されるというのは不合理。
純粋関数は、λ式に割り当てられることになって、当然、圏をなすだろうに、
プログラムに割り当てられるものが圏を成さないというのはおかしい。
でも、入出力プログラムはMoggiのアイディア１から、
prog :: A → IO B
省1
471: 2024/10/04(金)19:29 ID:tixO3LDq(4/22) AAS
Moggiのアイディア１の段階でcomputationの概念というのは解消してしまう。
PlotokinとPowerはそこが不満なんだろうか？
472(1): 2024/10/04(金)20:18 ID:WSIC8Xt5(1/14) AAS
だから、副作用を隠してラムダ計算に変換する手続きは、世界をステートにする変換をした時点で達成されてるわけで、そんなの太古の昔から分かってたことだろ
IO aの定義読んでから出直せよ
473(1): 2024/10/04(金)20:30 ID:SclsbEZF(1) AAS
日を跨ぐつもりならコテハンでも付けてくれんか
追えん
474(1): 2024/10/04(金)20:44 ID:tixO3LDq(5/22) AAS
>>472
だからそれはわかっているって。評価途中では実際の入出力はせず指示書だか値のリストだけ作成して
参照透過性を保証して、参照透過性が要求されなくなったプログラムの最終段階でリストに従って
入出力を実行するような仕組みがあれば、参照透過性を保ったまま入出力はできるという話でしょ。
それを数学的にどう正当化するかという話を書いているんだって。
>>473
水曜日あたりからだからそんな分量ないよ。
475: 2024/10/04(金)20:49 ID:WSIC8Xt5(2/14) AAS
>>474
どこが正当化されてないのか意味不明なんだけど
ていうか正当化って何？
476(1): 2024/10/04(金)20:51 ID:tixO3LDq(6/22) AAS
だから、入出力がある数学的関数なんてないじゃん。
入出力があるプログラムを数学的に表現しようと思っても詰むからどうしようって話。
477: 2024/10/04(金)20:57 ID:6lZW+X9H(1/3) AAS
こんなところで長文書くのはやめてもろて
読む価値があるものならzennとかnoteに書けば？
関数型言語界隈の人たちがクソミソにレビューしてくれるよ
478(2): 2024/10/04(金)20:58 ID:WSIC8Xt5(3/14) AAS
>>476
型付きラムダ計算の時点で数学的に表現されてるだろ…
意味不明すぎる
479(2): 2024/10/04(金)21:00 ID:qBjLuAvO(1/2) AAS
メインの入力とメインの出力は数学にもある
主じゃないやつを副作用といってる
480(1): 2024/10/04(金)21:11 ID:tixO3LDq(7/22) AAS
>>478
なるほどそう考えていたのか。全部λ計算でアセンブルすりゃ数学的に還元できるだろうってわけね。
でもそうだとすると文字列を表示するハードウェアの部分はどう還元するの？
>>479
よくわかんない。具体的に言うとどういうのある？
481: 2024/10/04(金)21:11 ID:tixO3LDq(8/22) AAS
>>478
なるほどそう考えていたのか。全部λ計算でアセンブルすりゃ数学的に還元できるだろうってわけね。
でもそうだとすると文字列を表示するハードウェアの部分はどう還元するの？
>>479
よくわかんない。具体的に言うとどういうのある？
482: 2024/10/04(金)21:18 ID:WSIC8Xt5(4/14) AAS
>>480
アセンブルって何？
後半も何言ってるのかちゃんと分かるように書いて
483: 2024/10/04(金)21:25 ID:WSIC8Xt5(5/14) AAS
そうだよ、こんなとこじゃなくてzennとかに煽った感じのタイトルつけて炎上する記事書いてコメントもらって来いよ
484(3): 2024/10/04(金)21:28 ID:tixO3LDq(9/22) AAS
λ計算を機械語とかアセンブラと見立てて、λ計算ですべて数学世界を組み立てれば、
入出力がある数学的関数も定義できるだろうから、あえて数学的正当性なんて与えようとする
理由がわからない、ということだろうと思った。
プログラムの部分は全てλ計算で組み立てれば完全に同じものが作れると思っているということ
だけれども、じゃあ文字列をディスプレイに表示するというプログラムの構成要素である
ディスプレイはハードウェア部分だけれども、それはλ計算で組み立てるという範疇にはいるんですか？
入らないなら、なにか数学的概念を持ち出してきてそれに対応付けるということをしないといけないんじゃ
ないですか？
という趣旨のことを書いた。
485: 2024/10/04(金)21:33 ID:tixO3LDq(10/22) AAS
これ読んだらわかるけどMoggi論文の読書感想文。いまさらの。
匿名以外でいまさら突っ込んでくるわけないじゃん。
486: 2024/10/04(金)21:33 ID:tixO3LDq(11/22) AAS
これ読んだらわかるけどMoggi論文の読書感想文。いまさらの。
匿名以外でいまさら突っ込んでくるわけないじゃん。
487: 2024/10/04(金)21:34 ID:qBjLuAvO(2/2) AAS
関数の「型」を見ろ
入力が何で出力が何かが宣言されている
488: 2024/10/04(金)21:39 ID:tixO3LDq(12/22) AAS
>>484
ディスプレイに表示するまでの概念はよく考えたら既存の例でもなかったわ。
焦って変なこといったスマン。
ちょっと説明を考える。
上下前次1-新書関写板覧索設栞歴
あと 179 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s