Yコンビネーターとテールコールの最適化

F＃のYコンビネーターの定義は

let rec y f x = f (y f) x

fは、最初の引数として、再帰的サブ問題の継続を期待しています。yfを継続として使用すると、fが次の呼び出しに適用され、開発できることがわかります。

let y f x = f (y f) x = f (f (y f)) x = f (f (f (y f))) x etc...

問題は、先験的に、このスキームがテールコールの最適化を使用できないことです。実際、fで保留中の操作がある可能性があります。その場合、fに関連付けられたローカルスタックフレームを変更できません。

そう ：

• 一方では、Yコンビネータを使用するには、関数自体とは明示的に異なる継続が必要です。
• TCOを適用する必要がある場合は、fで保留中の操作はなく、f自体のみを呼び出します。

これら2つを調整する方法を知っていますか？アキュムレータトリックを使用したYや、CPSトリックを使用したYなど？それともそれができる方法がないことを証明する議論？

これら2つを調整する方法を知っていますか？

いいえ、そして正当な理由で、私見。

Yコンビネータは理論的な構造であり、ラムダ計算を完全にチューリングするためにのみ必要です（ラムダ計算にはループがなく、ラムダには再帰に使用できる名前がありません）。

このように、Yコンビネーターは本当に魅力的です。

しかし、実際の再帰にYコンビネーターを実際に使用する人はいません！（それが本当に機能することを示すために、たぶん楽しみのためを除いて）

テールコールの最適化、OTOHは、名前が示すように、最適化です。言語の表現力には何も追加しません。それは、スタックスペースや再帰コードのパフォーマンスなどの実用的な考慮事項だけが、私たちがそれを気にしているからです。

あなたの質問は次のようなものです：ベータ削減のためのハードウェアサポートはありますか？（ベータ削減は、ラムダ式がどのように削減されるかを知っています。）しかし、関数型言語（私の知る限り）は、実行時にベータ削減されるラムダ式の表現にソースコードをコンパイルしません。

私はこの答えについて完全には確信していませんが、私が思いつくことができる最高のものです。

yコンビネータは本質的に怠け者です。厳密な言語では、余分なラムダを使用して遅延を手動で追加する必要があります。

let rec y f x = f (y f) x

定義は、終了するために怠を必要とするように見え(y f)ます。そうでない場合、引数は評価を終了せず、fそれを使用したかどうかを評価する必要があります。レイジーコンテキストでのTOCはより複雑で、さらにの結果は、(y f)アプリケーションを使用せずに関数合成を繰り返しますx。これがO（n）メモリを取る必要があるかどうかはわかりませんが、nは再帰の深さですが、（Haskellに切り替えると実際にはわからないので、可能な限り同じタイプのTOCを実現できるとは思いません。 F＃）

length acc []    = acc
length acc (a:b) = length (acc+1) b 

まだ気付いていない場合は、Haskell foldlとfoldl'Haskellの違いが状況に光をあてるかもしれません。foldl熱心な言語で行われるように書かれています。しかし、TOCされる代わりに、実際にfoldrはアキュムレーターが部分的に評価できない潜在的に巨大なサンクを保存するためよりも悪いです。（これはfoldlとfoldl 'の両方が無限リストで機能しない理由に関連しています。）したがって、Haskellのより新しいバージョンでfoldl'は、巨大なサンクが作成されないように関数が繰り返されるたびにアキュムレータの評価を強制します。http://www.haskell.org/haskellwiki/Foldr_Foldl_Foldl%27がこれを私よりもうまく説明できると確信しています。