[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part33 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
772(1): 2021/03/19(金)09:49 ID:pEtEADGt(1) AAS
>>769
そうですね
多分対応自体はわかると思います
しかし実際カリーハワード対応で基礎論の世界に持って行くことの効用がよくわかりません
基礎論の世界に持っていって基礎論でよく知られたなんかの定理が使えるとかいうわけでもなさそうですし
最初はcall by needの実装の話、すなわちcall by needでは展開された評価式に同じexpressionが出たとき、その内容を保持して同じ評価を何度も繰り返すのを防ぐらしいですが、もちろんどんな評価でも何でもかんでもメモするわけではないようなので、結局自分で手前でメモ化する必要がでたりします
どういう時はcall by needのメモ化が効いてどういう場合は効かないのかよくわからないので現状は“やってみる”しかないし、やってみて上手くいかなくても、なんか上手い書き方すればやってくれるのか、はなからだめなのか、その判別もつきません
775(1): 2021/03/20(土)08:58 ID:Hmrg9tvu(1/2) AAS
>>772
プログラムの世界において、ある事柄の性質や、事柄Aと事柄Bの間の関係を調べたいとき、
プログラムの世界の中ではなかなかうまく見えてこない場合がある。
そんなとき、 カリーハワード同型対応によって問題を論理の世界に移すと、
見通しが良くなり、調べやすくなることがある。
そういう意味では役立ちます。
質問者さんが例示した論文がまさにそれです。
一方、何かを作るためにプログラムをする(現場の)人たちにとっては、とくに役立つことは無いと思います。
役立った話を一切聞きません。
質問者さんが、名前呼び出しなどの「性質や関係」を学術的に深く知りたくて調べているのであれば、役立つと思います。
自作のプログラム言語で名前呼び出しを実装したくて調べているのであれば、役立ちませんね。
別の論文に当たった方がいいと思います。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s