関数型プログラミング言語Haskell Part34 (667ﾚｽ)
上下前次1-新
448: 2024/10/03(木)19:57 ID:B2Xmf+Xl(4/9) AAS
現実のよくあるプログラムとはこういう感じのものだけれども、実行 $(prog1) をしてその結果が返ってくるという現実的に
必要な点だけを考えると、途中の行番号020を評価したとかそういう情報はいらなくて、結局 $(prog1) して
hogehoge
fugafuga
を表示して、複雑な計算の結果 res が返ってくれさえすればいいともいえる。
だったら、数学的に取り扱いがしづらい、式の評価途中で入出力が発生するみたいな部分を取っ払って
000 procedure prog2(int n) {
001 double res
002 （なにか込み入った計算）
....
省12
449: 2024/10/03(木)19:57 ID:B2Xmf+Xl(5/9) AAS
というわけで、入出力があるプログラムというのは、こういう返り値の部分というか評価の最終段階の部分に「入出力の予約情報と返り値の情報がまとめられたもの」だったんだ、と整理しよう。
ただ、こういう「入出力の予約情報と返り値の情報がまとめられたもの」と長い文で表すのはよろしくないので、何か名前を与えた方がいいということで
computationと呼ぶことにする。
そうすると、Haskellでいえば、
純粋関数は、valueからvalueへの数学的関数
に割り当てることができたけれど、
入出力付きのプログラムについては、valueからcomputationへの対応
に割り当てるということが数学的に正当化できそうだ、ということになるわけだ。
450: 2024/10/03(木)20:00 ID:B2Xmf+Xl(6/9) AAS
訂正
computationというか、今でいう「入出力の予約情報と返り値の情報がまとめられたもの」を
数学的にうまく正当化するということが達成することができるのであれば、
入出力つきのプログラムを、valueからcomputationへの対応
に割り当てるということが正当化できるはずだ、と考えられる。
451: 2024/10/03(木)20:23 ID:zyXzLypu(2/6) AAS
何言ってるのか全然わからん
ぶっちゃけ入力は関数の引数にして、出力は返り値にするように変換するだけでいいだろ
読み出し位置のカーソル管理が必要なら代入を使えばできるじゃん
452: 2024/10/03(木)20:39 ID:B2Xmf+Xl(7/9) AAS
よくわかんないけど、そういう入出力プログラムがあったとする。
そしてそれを引数付きで実行することを考えると
$(prog n)
こうなる。ここで、引数の部分の n はプログラムの記述に属さないといけない。
なぜかというと現実世界の「入力」部分をそのまま引数のところには持ってこれないから。
引数部分を入力にするにしても、別途入力されたものをプログラムの変数に割り当てる概念
みたいなのが必要になるし、それは関数の引数だからということでは説明にならないと思う。
だから、少なくともprogの引数部分はvalueじゃないといけない。
453: 2024/10/03(木)20:45 ID:zyXzLypu(3/6) AAS
ポエムすぎて意味わからん。値のリストはvalueじゃないと？
454: 2024/10/03(木)20:59 ID:B2Xmf+Xl(8/9) AAS
値のリスト自体をそのまま持ってくればvalueということになるんだろうけれど、
$(prog n)
の実行結果として出てくるもので、計算効果の説明になるものであって、返り値の型を包含するもの
であればcomputationと判断せざるを得ないとかそういうことしか言えないです。
455: 2024/10/03(木)21:11 ID:zyXzLypu(4/6) AAS
判断するって何言ってるの？
computationって定義は何なの？
ラムダ項を書き換えていく手続きが計算じゃないの？
456: 2024/10/03(木)21:22 ID:B2Xmf+Xl(9/9) AAS
valueとcomputationの違いは微妙で$(prog n)の実行結果として出てくるかどうかとか
計算効果が発露しているかというところで見極めるしかない、と理解している。判断する
というのは専門用語としては使ってない。
computationの定義はまた微妙だけれど、$(prog n)の計算効果込みの実行結果みたいな概念。
最後は超個人的見解だけど、「λ項を書き換えていく行為」というのは、どういう方法で表現して
どういう方法で簡約していくか？というところが決まってない。λ計算じゃないけれど、
１＋１＝２
という計算を暗算でやるか、電卓でやるか、そろばんでやるかという違いを出しても計算することに
変わりない。
暗算でやると、脳内物質の分量が変わるし、電卓だと電位が変わる。そして、そろばんでやると
省1
457: 2024/10/03(木)21:30 ID:zyXzLypu(5/6) AAS
❌決まってない
⭕知らない
間違えるなよ
458: 2024/10/03(木)21:31 ID:zyXzLypu(6/6) AAS
お前の脳内にしかないお花畑に巻き込むのやめてもらっていいですか？
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に書けば？
関数型言語界隈の人たちがクソミソにレビューしてくれるよ
上下前次1-新書関写板覧索設栞歴
あと 190 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.024s