Оптимізація комбінаторів та хвостових викликів Y

Визначення комбінатора Y у F # є

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.

Чи знаєте ви про якийсь спосіб, щоб ці двоє могли примиритися? Як Y з акумуляторним трюком, або Y з фокусом CPS? Або аргумент, що доводить, що це неможливо зробити?

Чи знаєте ви про якийсь спосіб, щоб ці двоє могли примиритися?

Ні, і з поважної причини ІМХО.

Y-комбінатор - теоретична конструкція, і він потрібен лише для того, щоб зробити обчислення лямбда повним (пам’ятайте, що в обчисленні лямбда немає циклів, а також у лямбда не є імен, які ми могли б використовувати для рекурсії).

Як такий, комбінатор Y справді захоплюючий.

Але : Ніхто насправді не використовує Y-комбінатор для фактичної рекурсії! (За винятком можливо для задоволення, щоб показати, що це справді працює.)

Оптимізація хвостових викликів, OTOH, є, як видно з назви, оптимізацією. Це нічого не додає виразності мови, ми хвилюємося лише через практичні міркування, такі як простір стеків та виконання рекурсивного коду.

Отже, ваше запитання виглядає так: чи існує апаратна підтримка для зменшення бета-версії? (Бета-скорочення - це зменшення лямбда-виразів, ви знаєте.) Але жодна функціональна мова (наскільки мені відомо) не компілює свій вихідний код для подання лямбда-виразів, які будуть бета-скороченими під час виконання.

Я не зовсім впевнений у цій відповіді, але це найкраще, що я міг придумати.

Комбінатор y по своїй суті лінивий, строгими мовами лінь потрібно додавати вручну через додаткові лямбда.

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

Ваша дефініція виглядає так, що для її припинення потрібна лінь, або (y f)аргумент ніколи не закінчуватиметься, і доведеться оцінювати, fвикористовував він чи ні . ТОК в ледачому контексті є складнішим, і, крім того, результат (y f)повторної композиції функції без застосування x. Я не впевнений, що для цього потрібно взяти O (n) пам’ять, де n - глибина рекурсії, але я сумніваюся, ви могли б досягти того самого типу TOC, як це можливо, з чимось на зразок (перехід на Haskell, тому що я насправді не знаю F #)

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

Якщо ви цього ще не знаєте, різниця між foldlі foldl'в Haskell може висвітлити ситуацію. foldlпишеться так, як це було б зроблено нетерплячою мовою. Але замість того, щоб бути TOC'd, це насправді гірше, ніж foldrтому, що акумулятор зберігає потенційно величезний громовідвід, який неможливо частково оцінити. (Це пов’язано з тим, чому і foldl, і foldl 'не працюють у нескінченних списках.) Таким чином, в останніх версіях Haskell foldl'додано, що змушує оцінювати акумулятор кожного разу, коли функція повторюється, щоб забезпечити не створення величезного блоку. Я впевнений, що http://www.haskell.org/haskellwiki/Foldr_Foldl_Foldl%27 може пояснити це краще, ніж я.