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

**デフォルトの名無しさん** · 2021/12/17(金) 12:57:26.37

関数型プログラミング言語 Haskell について語るスレです。

Haskell Language(公式サイト)
https://www.haskell.org/
日本Haskellユーザーグループ - Haskell-jp
https://haskell.jp/

前スレ
関数型プログラミング言語Haskell Part33
https://mevius.5ch.net/test/read.cgi/tech/1581326256/

**デフォルトの名無しさん** · 2024/09/07(土) 19:35:13.52

文字化けしちゃいました。文字化けした？は１、２，３だと思ってください

**デフォルトの名無しさん** · 2024/09/08(日) 00:17:59.58

loop s なんちゃらかんちゃら
= do
　let　final_score = long_thunk_score + s
　　　s' = sをなんちゃらかんちゃら
　modify' $ Data.Map.Strict.insert key final_score
　unsafePerformIO ( evaluate $ rnf final_score ) `seq` loop s' なんちゃらかんちゃら

このStateモナドは、final_scoreは状態Mapへ挿入される時はWHNFでしょうが、直後の行で完全に評価されています
この事はマップに挿入されたfinal_scoreへ影響を与えますか?
つまりマップへ挿入済みのサンクとしての値を後からUnsafePerformIOとevaluateとrnfを組み合わせて狙ったタイミングでRNF化できますか？

**デフォルトの名無しさん** · 2024/09/09(月) 11:45:42.71

>>356
黙って動いてるフリをする

**デフォルトの名無しさん** · 2024/09/26(木) 23:16:42.97

この言語まだ息してるのか？

**デフォルトの名無しさん** · 2024/09/27(金) 00:41:23.43

おまいらは圏論はちゃんとマスターしたか？
最近圏論のお勉強流行ってないみたいだが

**デフォルトの名無しさん** · 2024/09/28(土) 08:56:06.97

そもそもHaskellに圏論必要ないよ

**デフォルトの名無しさん** · 2024/09/28(土) 11:20:55.86

背景の理論を理解してないとbrainf*ckと同列のクソパズル言語にしか見えない

**デフォルトの名無しさん** · 2024/09/28(土) 11:30:45.96

米田の何ちゃらの辺りで心が折れて終了

**デフォルトの名無しさん** · 2024/09/28(土) 11:48:20.49

>>363
> brainf*ckと同列のクソパズル言語

話がそれるけどbrainf*ckがパズル言語なのは100%その通りだよ

しかし構文パーサー、インタープリターやトランスレーター、JITエンジンの実践入門として
丁度良いからこれだけ根強い人気なんだぜ

**デフォルトの名無しさん** · 2024/09/28(土) 20:40:40.54

>>361
流行ってないのか…。
個人的にはHaskellよりも圏論の方に関心が移ってるのに…。

んでも、圏論はHaskellでなくても、全てのプログラミング言語の裏側でも動いてるし、それこそ算数の裏側でも動いてる。

モナドが表に出てきてるからHaskellには圏論が必要って思うかもだけど、モナドって言わないで do形式だけ教えて知れっとしてても良いし、「こういう動きの演算子」としてモナドを紹介するだけでも良い。

受験数学とちゃんと向き合う数学みたいなものだけど、変にモナドを理解しようとすると深みにはまる。
（それはそれで楽しいけど、楽しめる人だけだよね…）

**デフォルトの名無しさん** · 2024/09/29(日) 07:33:19.55

ラムダと束縛変数をマスターしなければdo記法もマスターできないのを
すっかり忘れるぐらいポイントフリーが普及してるでしょ

**デフォルトの名無しさん** · 2024/09/29(日) 08:45:10.72

コーダーが数学の学習に使える時間なんて限られている
時間や基礎知識が足らないので、難解な数学を攻略するのはほぼ不可能
大学生時CSや数学の講義で身に付けておくしかない

**デフォルトの名無しさん** · 2024/09/29(日) 09:32:49.44

難解な数学を攻略できるなら
日本ではコーダーにはならないよな

**デフォルトの名無しさん** · 2024/09/29(日) 10:15:01.09

業界入るのに難解数学不要
プログラミングにも不要
数学分からんのでgoogle入るのは無理だけど

**デフォルトの名無しさん** · 2024/09/29(日) 11:01:25.51

人工的なルールに依存するのがクソパズルだが
自然界でなおかつ野生のマウンティング的なルールにも依存しないことが数学の目的のひとつだね

**デフォルトの名無しさん** · 2024/09/29(日) 20:36:16.00

圏論が全てのプログラミング言語の裏で動いてるとか適当なこと書くなよ

**デフォルトの名無しさん** · 2024/09/30(月) 00:30:17.34

>>368
高卒の自分でも理解できるんだから、難しいわけではないんだけど。
何度も出てる通り、必ずしもモナドを理解する必要はないし。

そもそも自分がプログラマーの頃だって、12－13時間働いた後も新しいプログラミング言語や数学勉強してたぞ。
（新しい仕事のために学びたくない言語に時間使う事も）

高卒が圏論みたいな大学数学学ぶには専門用語がそもそも分らんから、用語が分かるまで遡った。
（アーベル圏のアーベルが分からないレベルからのスタート）

自分に投資できないと淘汰されるぞ。

**デフォルトの名無しさん** · 2024/09/30(月) 00:59:39.85

>>372
適当じゃない。
モナドは(主に)逐次処理に現れる構造なので、Haskellのような遅延評価で逐次処理自体を作らないといけない（逐次処理をエミュレートするためのモナド）言語でない限り、意識することすらない。
（だからC言語で言う i = 0; の「；」とか言われる）

**デフォルトの名無しさん** · 2024/09/30(月) 03:08:44.15

>>372
沈黙させる努力をするよりも（全ての）人の話を聞くのをサボる方が良い
努力は時間がかかる
一瞬で報われるものは努力ではない

**デフォルトの名無しさん** · 2024/09/30(月) 12:40:29.07

圏論の極々一部のモナドを主語をデカくして圏論ガーとか言ってる人は何も分かってないんだなと思うけどね
俺みたいに数学かじってた人からすると
圏論を勉強すると「あ、この概念はこの分野のこれのことか」ってわかるけど
そうじゃない人は何のことを言ってるのかわからんと思う
専門家でも自分の担当外の圏なんて知らないのに
圏論という括りで語ろうとする人はそういうのすら理解してない

**デフォルトの名無しさん** · 2024/09/30(月) 13:52:28.73

やっと普通の人が出てきて安心した

**デフォルトの名無しさん** · 2024/09/30(月) 13:59:18.70

>>376
数学者向けの圏論の教科書の応用、具体例は全て数学。
数学知らない人が読んでも分かるわけがない。
応用、具体例、演習をCSの分野から採った教科書が望まれるが、書くのが難しい上に面白くするのも困難。
大体CSすらちゃんと修めてないエンジニアはやはり読めない。
CS自体ベースに位相、代数、グラフ理論と数学使うし。

**デフォルトの名無しさん** · 2024/09/30(月) 14:09:03.81

趣味でやる人に良くいるんだよね。
応用各分野に囚われずに、圏論そのものを学習したい、一般圏論を研究したいって人。
これは数学で言うと、集合論と同じく数学基礎論の分野。

**デフォルトの名無しさん** · 2024/09/30(月) 19:05:45.94

操作的意味論とか表示的意味論でプログラムを数学の話にして、その数学を圏論で整理するって話
だからアーベル圏とか具体的な圏はあんま出てこない。
やるとすれば
デカルト閉圏：ランベックがλ計算のモデルになると発見して関数型プログラミング的に重要
クライスリ圏：Moggiが計算効果をカプセル化したときの根拠の圏
ローベア理論：代数的効果をちゃんと理解するときは必要らしい。操作的意味論と表示的意味論と同じようにモナドの理論と妥当性が成り立つようだ。
ぐらいじゃね。

**デフォルトの名無しさん** · 2024/09/30(月) 21:09:21.28

じゃあラムダ計算（のモデル）だけを考えよう
タプルや代数的データ型は使わない
それでもモナドの具体例を作れるのを知ってるのが専門バカ
知らないのが一般国民だ

**デフォルトの名無しさん** · 2024/09/30(月) 21:29:13.05

一般国民。
λ計算のモデルでモナド作ってなにかいいことあるの？計算効果結局表現できないんじゃ？
拡張してcomputational lambda calculusやるって話？

**デフォルトの名無しさん** · 2024/09/30(月) 21:47:09.45

ないんじゃないか
ただ「具体例を出せば、いいことがある」とは誰も言ってない
というファクトをチェックするのは悪いことではない

**デフォルトの名無しさん** · 2024/09/30(月) 21:53:56.34

いいこと（メリット）があるから具体例が作られると思うんだが。
それは単に具体例の適用が間違ってるって話じゃね？
なんとなく作れるから群構造作ってみましたとかとか目的不在で作ったらそら何がいいかわからんし。
モナドだったら、各計算効果を圏（クライスリ圏）の中に閉じ込めることに成功しました（カプセル化）。
計算効果は強モナドの構造を取っているようです（計算効果の研究のとっかかり）。
みたいないいことあるから流行るんでしょ。

**デフォルトの名無しさん** · 2024/10/01(火) 04:04:03.18

別にそれ圏論を持ち出す必要ないよね
ハイおしまい

**デフォルトの名無しさん** · 2024/10/01(火) 09:39:15.78

>なんとなく作れるから群構造作ってみました
ルービックキューブのことか

**デフォルトの名無しさん** · 2024/10/01(火) 09:46:07.52

数学屋さんもね
研究では圏を使うが
学生に教えるときは
圏を記述に使わず教えたりする

**デフォルトの名無しさん** · 2024/10/01(火) 19:23:20.12

圏論の話題になったから振ったのに。まあいいよ。
圏論根拠で（ソフトウェア工学的にじゃなくて）数学的にカプセル化が実現されてるってすごい
ことだと思うけどね。

>ルービックキューブのことか
ルービックキューブ解くという目的あるんなら構築する意味あるんじゃない。

**デフォルトの名無しさん** · 2024/10/01(火) 19:34:54.43

群持ち出したところで解けないよ

**デフォルトの名無しさん** · 2024/10/01(火) 20:18:43.32

圏論がプログラミングの問題解決に寄与するわけないのにね
ただ当てはめてみたってだけのことを過大評価しすぎ

**デフォルトの名無しさん** · 2024/10/01(火) 20:52:10.03

雪田修一の「圏論入門 Haskellで計算する具体例から」ってどうなん？

**デフォルトの名無しさん** · 2024/10/01(火) 21:10:04.55

板チ
目的と手段を混同したら予選敗退

**デフォルトの名無しさん** · 2024/10/01(火) 21:16:26.45

どうなんって何を知るのに？出たときに立ち読みしただけだけど。

**デフォルトの名無しさん** · 2024/10/01(火) 21:16:56.98

>>391
青本と似てて定義の後に具体例を出すみたいな感じだけど
具体例が数学科の人じゃないとわからない内容ばかりなので
結局個別の分野をやらないと理解できないと思う

**デフォルトの名無しさん** · 2024/10/01(火) 21:38:18.13

圏論をやりたいならまず代数学をやるべき
それだけでだいぶ見通しが違う

**デフォルトの名無しさん** · 2024/10/01(火) 21:42:08.00

>>390
モナドの効用で自分の把握してるのは

・数学やHaskellの様な遅延評価の場合、逐次処理を表現できる
（これは変数を使いまわさない場合は、関数合成で十分だが、変数を使いまわすときはモナドじゃないと使いまわせない）

・副作用のある関数を使っても参照透明性は保たれている

・モナドは入れ物前提の概念なので、空の状態を使って例外処理をまとめることができる

正直、普通のプログラミング言語にも役立ちそうな3つ目は実感はしてないけど、ネットで例外処理よりモナドの方が優秀っぽい記事を読んだ

2番目もマルチスレッドとか最適化には役に立ちそうではある
（マルチスレッドなら正格評価版HaskellのIdris２やRustだと思うが）

**デフォルトの名無しさん** · 2024/10/01(火) 22:05:17.67

圏論全体だと…当たり前のことを構造として研究してるだけなので、圏論というよりはHaskellの型クラスとの合わせ技で関手（Functor）の方がfmap的なのを他の言語にも導入すれば役に立つかも

圏論の関手を一言で言えば（関数も含めた）型変換
（Hakellだと入れ物前提にすることで、関数ごと型変換を実現。本来はもっと柔軟）

自然変換は一言で言えば単位変換とか、大文字小文字の変換

**デフォルトの名無しさん** · 2024/10/01(火) 22:16:21.15

モノイドは条件が結合法則だけなので、ほぼ結合法則そのものがモノイド
（その割には繰り返しとか数え上げに現れる構造）

そしてモナドも構造はそっくりなので、入れ物前提のモノイドとも考えられる
（モナドの再帰はループ処理でスタックを消費しないし、数え上げは逐次処理と考えられる）

**デフォルトの名無しさん** · 2024/10/01(火) 23:08:20.75

バグを無くすこと自体が目的になりがちなのが数学とプログラムなんだよね
真の目的のため、デバッグを二の次にするやつが正しいと言われても・・・
それって証明とかあるんですか

**デフォルトの名無しさん** · 2024/10/01(火) 23:21:35.19

>>397
大文字小文字の変換が自然変換の部分kwsk

>>399
目的と手段を区別したら、手段は二の次だと言うのは予選敗退者のポエム

**デフォルトの名無しさん** · 2024/10/01(火) 23:25:15.70

>>396
> 2番目もマルチスレッドとか最適化には役に立ちそうではある
それもう一人のsimonが取り組んだけどモナドは否定された

**デフォルトの名無しさん** · 2024/10/02(水) 05:35:22.65

やっぱり数学的に表現してみただけってことか
まぁ実際のプログラミングに利益はないわな

**デフォルトの名無しさん** · 2024/10/02(水) 07:50:08.23

>>400
よくよく考えたら特別な事じゃないんだけど、普通のプログラミング言語でも大文字・小文字の変換関数を自作するってなったら、文字をInt型に変換して処理する。

それって文字の圏で直接大文字小文字の変換するを作れない場合、一旦整数の圏を経由する関数を作る。

A(a) → B(a)
↓ ↓
A(A) → B(A)

可換図のA(a) → B(a)の逆射が作れれば、B(a) → B(A)が作れる。
ほら、分かってみれば「なーんだ。そんなことか」でしょ？

**デフォルトの名無しさん** · 2024/10/02(水) 07:53:32.91

この場合、整数同士の足し算に対応する、文字同士の足し算が作れる。
（ただし、整数と文字列で集合の大きさを合わせる必要がある。0－25とか1－26とかで循環する集合）

**デフォルトの名無しさん** · 2024/10/02(水) 07:55:35.67

んで、プログラマーはいちいち集合を合わせないで、エラー処理だったり循環リスト作ったりで対応するわけだぬ。

**デフォルトの名無しさん** · 2024/10/02(水) 08:30:24.33

数学の圏論テキストではカリー化の操作は良く使うが、カリー化の名前を付けて引用することはまず無いね。

**デフォルトの名無しさん** · 2024/10/02(水) 08:47:20.09

>>403
大文字小文字の変換が自然変換になる事を(Haskellの例で)証明して、と言う話

(自然変換が何かは分かっているで、直感的に違うと思ったから訊いた)

**デフォルトの名無しさん** · 2024/10/02(水) 09:21:51.83

大文字の文字列の型から小文字の文字列の型への変換と考えると簡単

**デフォルトの名無しさん** · 2024/10/02(水) 09:24:29.51

リスト関手から集合関手への自然変換も分かりやすい。

**デフォルトの名無しさん** · 2024/10/02(水) 10:25:28.13

すまん嘘を書いた
自然変換では無くリストの圏から集合の圏への関手だった

**デフォルトの名無しさん** · 2024/10/02(水) 10:27:20.94

大文字列、小文字列も同様に間違い

**デフォルトの名無しさん** · 2024/10/02(水) 16:24:48.26

>>402
ただの記号で表現したら「0の逆数」とかいう表現を禁止するのが難しい
ただの記号ではない方がベター

**デフォルトの名無しさん** · 2024/10/02(水) 20:27:37.99

>>407
圏論の自然変換だと文字コード前提じゃないので、[0..25] = ['a'..'z'] = ['A'..'Z']ってする。
んで、大文字と小文字は同じ文字の圏、[0..25]は自然数の圏とする。

lCharToInt c = (length.takeWhile (c /=)) ['a'..'z'] -- 小文字からIntへの変換（関手）
uCharToInt c = (length.takeWhile (c /=)) ['A'..'Z'] -- 大文字からIntへの変換（関手）

toLChar = (['a'..'z']!!) -- Intから小文字への変換（関手）
toUChar = (['A'..'Z']!!) -- Intから大文字への変換（関手）

mytoLower = toLChar.uCharToInt -- 大文字から小文字への変換（自然変換）
mytoUpper = toUChar.lCharToInt -- 小文字から大文字への変換（自然変換）

でも、普通のプログラミング言語のtoLower, toUpperも、Char型を圏とみれば同じ。
可換にするのは面倒くさい上に効率悪いけど、そういう関手を作ろうと思えば作れる。

**デフォルトの名無しさん** · 2024/10/02(水) 20:45:45.19

可換図にすると

　　　Char（小文字）
　　⇗
Int　　⇑toL ⇓toU
　　⇘
　　　Char（大文字）

ここで、小文字→Int, 大文字→Intが作れればtoLower, toUpperを直接作らなくても、関手の合成で作れる。

**デフォルトの名無しさん** · 2024/10/02(水) 20:53:28.38

出番ですよ >>399

**デフォルトの名無しさん** · 2024/10/02(水) 21:03:02.82

圏論の地平線でも書かれていたけど、圏論は直接的に役に立つというより、発想の転換の源泉になるそうな。
（なので、別に圏論分かったから偉いとかない）

**デフォルトの名無しさん** · 2024/10/02(水) 21:18:36.03

数学の研究には有用かも知れないが
プログラミングで
直接役に立つようなことはまず無い

**デフォルトの名無しさん** · 2024/10/02(水) 21:42:50.80

どっ白け

**デフォルトの名無しさん** · 2024/10/02(水) 21:51:30.73

プログラミング言語もどんどん数学に寄せているし、上のカキコみたいにプログラムの記述を
そのまま数学的対象とみなせるように改造していってると思う。本来は別物と考えるべきだと思う。

数学の研究といってもプログラム意味論の研究で、プログラムを数学の世界に写像したら
どう表現できるかということを研究していると言えるんじゃないかと思う。
数学の世界には、式の評価途中に発生する副作用といった概念がないので、現実のプログラムを
そのまま数学の世界に移そうと思ってもできないことの方が多い。
計算効果を圏論的に表現できたというのは、そういうプログラミング言語の数学化の一端みたいな
もんだと思う。

**デフォルトの名無しさん** · 2024/10/02(水) 22:00:14.12

副作用ってどうでもよくね
Haskellとかだとそもそも副作用ないし

**デフォルトの名無しさん** · 2024/10/02(水) 22:12:34.31

現実のプログラムだと式を評価する途中で発生する副作用というのは普通だけれど、
これを表示的意味論、操作的意味論で数学の世界に写そうと思うと途端に難しくなる。
数学で式の途中に文字列をディスプレイに映し出す、みたいな概念はないから。

それを整理して副作用と呼んでも差し支えない概念を提唱してHaskellに実装しているんだよ。
実際、ＩＯモナドの圏論的定式みるとこれが副作用？という表式してる。
全部後回しにしてフラッシュするというアイディアみたい。副作用をプログラムの最終局面で
実行しているから、式の評価途中の参照透明性も壊さない。なるほど、って感じ。

**デフォルトの名無しさん** · 2024/10/02(水) 22:20:07.75

ID:OPLMo7z3 = ID:AFS53MaU 本人か同レベル

複おじってレベル

**デフォルトの名無しさん** · 2024/10/02(水) 22:24:19.37

途端に難しくなるか？
副作用のない計算に変換する手順が教科書に書いてあるはずだが？

**デフォルトの名無しさん** · 2024/10/02(水) 22:29:49.51

>>422
別の人。自分ならプログラムの記述を一回数学の世界に写すし。

>>423
副作用のある数学的関数ってある？
プログラム→数学
に変換するんだぜ。
副作用のない計算に変換する手順が数学の本に書いてあんの？

**デフォルトの名無しさん** · 2024/10/02(水) 22:43:26.42

>>424
別人とのことなので便乗

ID:OPLMo7z3 は ID:AFS53MaU が
> 大文字小文字の変換が自然変換になる事を(Haskellの例で)証明して
と問われて

>>413,414 を出してきたのは数学的証明だと思ってるの？

**デフォルトの名無しさん** · 2024/10/02(水) 22:46:45.28

>>424
或いはもっと直接的に、>>424は「大文字小文字の変換が自然変換」の真偽をどう考えているの？

**デフォルトの名無しさん** · 2024/10/02(水) 22:51:00.95

定義が何もないのに何も言えるわけないじゃん。
数学でこういうものを定義します、これをプログラムのこれこれと対応付けます。
てプロセスないじゃん。

**デフォルトの名無しさん** · 2024/10/02(水) 22:52:03.28

>>424
先に副作用のないプログラムに変換するって言ってるんですけど
Haskellなら最初から副作用がないからそのままでいいけど
プログラミング言語の理論の本ならどれにでも書いてないか？

**デフォルトの名無しさん** · 2024/10/02(水) 22:55:13.15

>>427
了解

>>422の指摘通りだと納得しました

**デフォルトの名無しさん** · 2024/10/02(水) 22:56:24.21

いや。プログラム意味論の本結構探し回ったけど副作用の記述は漠然としてて
扱えないわけじゃないらしいけど、具体的な変換なんて見たことない。
ちょうど伝統的なプログラム意味論で副作用どう扱われているか調べているんだ。
なんて本に書いてありましたか？

**デフォルトの名無しさん** · 2024/10/02(水) 23:02:49.62

どれにでも書いてあるだろ、whileプログラムをラムダ計算に変換する手順とか書いてないなんてことがあるわけがない

**デフォルトの名無しさん** · 2024/10/02(水) 23:06:08.21

なんだ。いや聞きたいのは入出力とかの副作用だよ。

**デフォルトの名無しさん** · 2024/10/02(水) 23:17:44.98

入出力なんて代入に比べたら自明だろ…
そんなのいちいち教科書に書くかよ

**デフォルトの名無しさん** · 2024/10/02(水) 23:26:30.50

書いてないのは自明だからではなくて、研究の方向性がどう転ぶかわからないからだと思う。
表示的意味論も出た当時の文献では副作用について語ってることが多い。
現代的な本になるほどD∞モデルつくってはいおしまいで数学的にきれいなところしかやらない。

**デフォルトの名無しさん** · 2024/10/02(水) 23:36:01.67

プログラムの仕様とその証明を数学で記述する本にあるだろうね。

**デフォルトの名無しさん** · 2024/10/02(水) 23:37:10.87

どこが非自明なのかさっぱりわからん
代入と違って入出力は垂れ流しだし、入出力は代入の特別な場合だろ

**デフォルトの名無しさん** · 2024/10/02(水) 23:46:11.64

>>435
ホーア論理とか公理的意味論か。いやそれはないな。あっても一般に適用できないし。

>>436
関数型プログラミングだとプログラムをλ式に対応させて、プログラムの実行をそのλ式の簡約に
対応させるというのが理想的なモデルとして想定されることが多いと思う。
でもλ式はλ項からλ項への対応でしかないから、λ項を値(value)と呼ぶとすると
value から valueへの数学的関数でしかない。これには入出力とかの副作用を表現する余地がない。

つまり、
入出力があるプログラム→value から valueへの数学的関数
という対応付けをすると、入出力という特徴が数学世界では失われてしまう。
という難問があった、けどモナドで一つ解答が出た。

**デフォルトの名無しさん** · 2024/10/02(水) 23:54:51.93

代入が書けるんだから、入出力なんて自明だろ…
こいつ何いってんだ…

**デフォルトの名無しさん** · 2024/10/03(木) 00:02:36.12

だから、入出力がある数学的関数なんてないだろって言ってんの。
数学的関数で入出力は非自明だと思うんだが。

**デフォルトの名無しさん** · 2024/10/03(木) 00:09:13.65

Haskellでいうと、
純粋関数は、λ式（valueからvalueへの数学的関数）
に対応付けられるけど、
IOモナド使ったプログラムは、その現実のプログラムが持つ特徴を表現できるλ式がないので対応付けられない
って言ってんの。

**デフォルトの名無しさん** · 2024/10/03(木) 00:21:32.37

入出力なんてただの値のリストだろ…

**デフォルトの名無しさん** · 2024/10/03(木) 03:50:19.64

圏論持ち出して愚にもつかないことをグダグダと…
それで何か効率良くなるならいいんだけど，何のメリットもないんだよね

**デフォルトの名無しさん** · 2024/10/03(木) 04:21:38.74

圏論なんかより、遅延評価ならIOがwhnfの先頭に出てきたら実行すればいいって人類が気づいたのが本質なんじゃねーの

**デフォルトの名無しさん** · 2024/10/03(木) 08:29:58.17

最近の人類はseqのメリットを直接的に利用するコツに気づいとるんか
順調に進化しとるな

**デフォルトの名無しさん** · 2024/10/03(木) 14:31:37.97

コンパクトな言語仕様だが表現力は強力
数学をプログラミングに取り入れるメリットってまぁこんなもんでしかないでしょ
一方で静的に性質を決定しようとするやり方は一般的な人間の能力を簡単に超えてしまう

**デフォルトの名無しさん** · 2024/10/03(木) 16:46:40.39

急にポエマーだらけw

**デフォルトの名無しさん** · 2024/10/03(木) 19:56:29.70

入出力があるプログラムをどう数学的に整合する概念に対応させるかについて書いてみる。
こういう説明が通るものなのか興味があるし。

まず、仮想的なシェルスクリプト風の行番号付き手続き型言語を想定して、
その言語で入出力があるプログラムを定義するとする。

000 procedure prog1(int n) {
001　double res
002　（なにか込み入った計算）
....
020　echo "hogehoge"
021　（なにか込み入った計算）
....
050　echo "fugafuga"
051　（なにか込み入った計算）
...
100　return res }

このプログラムは実行 $(prog1) すると、行番号001版から順に評価していって複雑な計算をしつつ途中
hogehoge　　←　行番号０２０の命令を評価
fugafuga　　←　行番号０５０の命令を評価
と表示した上で、返り値 res を返す、という動作をする。

**デフォルトの名無しさん** · 2024/10/03(木) 19:57:08.78

現実のよくあるプログラムとはこういう感じのものだけれども、実行 $(prog1) をしてその結果が返ってくるという現実的に
必要な点だけを考えると、途中の行番号020を評価したとかそういう情報はいらなくて、結局 $(prog1) して
hogehoge
fugafuga
を表示して、複雑な計算の結果 res が返ってくれさえすればいいともいえる。

だったら、数学的に取り扱いがしづらい、式の評価途中で入出力が発生するみたいな部分を取っ払って
000 procedure prog2(int n) {
001　double res
002　（なにか込み入った計算）
....
020　## echo "hogehoge" #コメントアウト
021　（なにか込み入った計算）
....
050　## echo "fugafuga"　#コメントアウト
051　（なにか込み入った計算）
...
100　return ("hogehoge"を表示する予約1、"fugafuga"を表示する予約2、返り値 res) }

というように、返り値の部分に全部まとめるということをするということが考えられる。こうしても、プログラムのユーザー側からすると
実行すると$(prog2)
hogehoge
fugafuga
と表示されて複雑な計算した結果 res が返ってくるということは変わらない。

**デフォルトの名無しさん** · 2024/10/03(木) 19:57:34.71

というわけで、入出力があるプログラムというのは、こういう返り値の部分というか評価の最終段階の部分に「入出力の予約情報と返り値の情報がまとめられたもの」だったんだ、と整理しよう。
ただ、こういう「入出力の予約情報と返り値の情報がまとめられたもの」と長い文で表すのはよろしくないので、何か名前を与えた方がいいということで
computationと呼ぶことにする。

そうすると、Haskellでいえば、
純粋関数は、valueからvalueへの数学的関数
に割り当てることができたけれど、
入出力付きのプログラムについては、valueからcomputationへの対応
に割り当てるということが数学的に正当化できそうだ、ということになるわけだ。

**デフォルトの名無しさん** · 2024/10/03(木) 20:00:39.07

訂正
computationというか、今でいう「入出力の予約情報と返り値の情報がまとめられたもの」を
数学的にうまく正当化するということが達成することができるのであれば、
入出力つきのプログラムを、valueからcomputationへの対応
に割り当てるということが正当化できるはずだ、と考えられる。

**デフォルトの名無しさん** · 2024/10/03(木) 20:23:28.46

何言ってるのか全然わからん
ぶっちゃけ入力は関数の引数にして、出力は返り値にするように変換するだけでいいだろ
読み出し位置のカーソル管理が必要なら代入を使えばできるじゃん

**デフォルトの名無しさん** · 2024/10/03(木) 20:39:38.40

よくわかんないけど、そういう入出力プログラムがあったとする。
そしてそれを引数付きで実行することを考えると
$(prog n)
こうなる。ここで、引数の部分の n はプログラムの記述に属さないといけない。
なぜかというと現実世界の「入力」部分をそのまま引数のところには持ってこれないから。
引数部分を入力にするにしても、別途入力されたものをプログラムの変数に割り当てる概念
みたいなのが必要になるし、それは関数の引数だからということでは説明にならないと思う。
だから、少なくともprogの引数部分はvalueじゃないといけない。

**デフォルトの名無しさん** · 2024/10/03(木) 20:45:47.19

ポエムすぎて意味わからん。値のリストはvalueじゃないと？

**デフォルトの名無しさん** · 2024/10/03(木) 20:59:58.72

値のリスト自体をそのまま持ってくればvalueということになるんだろうけれど、
$(prog n)
の実行結果として出てくるもので、計算効果の説明になるものであって、返り値の型を包含するもの
であればcomputationと判断せざるを得ないとかそういうことしか言えないです。

**デフォルトの名無しさん** · 2024/10/03(木) 21:11:15.46

判断するって何言ってるの？
computationって定義は何なの？
ラムダ項を書き換えていく手続きが計算じゃないの？

**デフォルトの名無しさん** · 2024/10/03(木) 21:22:37.64

valueとcomputationの違いは微妙で$(prog n)の実行結果として出てくるかどうかとか
計算効果が発露しているかというところで見極めるしかない、と理解している。判断する
というのは専門用語としては使ってない。
computationの定義はまた微妙だけれど、$(prog n)の計算効果込みの実行結果みたいな概念。

最後は超個人的見解だけど、「λ項を書き換えていく行為」というのは、どういう方法で表現して
どういう方法で簡約していくか？というところが決まってない。λ計算じゃないけれど、
１＋１＝２
という計算を暗算でやるか、電卓でやるか、そろばんでやるかという違いを出しても計算することに
変わりない。
暗算でやると、脳内物質の分量が変わるし、電卓だと電位が変わる。そして、そろばんでやると
「ぱちぱち」という音が出る。