AFAIK, Перші докази використання функцій вищого порядку відносяться до статті Шенфінкеля 1924 року: "Про будівельні блоки математичної логіки" - де він дозволив передавати функції як аргументи іншим функціям.

Це здається цікавим. Однак, все, що я читав про його роботу (і про розширення Крірі), схоже, натякає на одне в тій чи іншій формі: [функції вищого порядку] ... це позбавляє потреби у пов'язаних змінних ...

Те, що я не зміг обернути головою, - це велика справа? Чому логіки та математики того часу дбали про це? І чи ми, як теоретики, дбаємо про це сьогодні? Чому було "новаторським" позбутися зв'язаних змінних і який вплив він (або робить) на обчислення (теоретично), як ми це знаємо?

PS: Я знаю, як його робота проклала шлях для обчислення та вплив "його" на обчислення та функціональне програмування в цілому. Моє запитання здебільшого спрямоване на час "до" створення λ -калькуляції та "після" статті Шенфінкеля. Той факт, що Каррі самостійно підхопив цю роботу, яка згодом була відома як "комбінаційна логіка", занадто натякає на важливість роботи Шенфінкеля.$\lambda$$\lambda$

TL; DR. Метаматематика зв’язування є тонкою : вони здаються тривіальними, але не є - чи маєте ви справу з логікою (вищого порядку) або 𝜆-численням. Вони настільки тонкі, що обов'язкові уявлення утворюють відкрите дослідницьке поле з конкуренцією ( виклик POPLmark ) кілька років тому. Є навіть жарти людей на місцях з приводу складності підходів до в’язки.

Отже, якщо ви переймаєтесь метаметематикою (а більшість математиків цього не робить), вам потрібно мати справу з прив’язкою. Але багато математиків можуть сміливо ставитися до формалізації зв'язування так, ніби це було "фундаментальною" проблемою.

Ще один момент полягає в тому, що прив'язка була єдиною "новою" проблемою в мовах з функціями вищого порядку, тому що теорія мов зі зв'язуванням - це просто алгебра (для констант) + зв'язування. Мітчелл "Основи мов програмування" насправді подає речі в цьому порядку і є досить освічуючим.

Мені відомо про те, як його робота проклала шлях для λ-числення та вплив "його" на обчислення та функціональне програмування загалом. Моє запитання здебільшого спрямоване на час "до" створення λ-обчислення та "після" роботи Шенфінкеля.

Я, мабуть, щось бракую, але це зауваження, мабуть, не має ніякого значення. Зв'язування логіки вищого порядку і зв'язування в λ-обчисленні здаються настільки ж важкими, тому, поки люди піклувалися про логіку вищого порядку, їм доводилося мати справу зі зв'язуванням. Я упереджений, використовуючи теорію теорії типу Curry-Howard-ізоморфізму, яка реалізує логіку, просто реалізуючи теорію типів (де типи є формулами, а програми - термінами доказів), так що я просто займаюся обов'язковим проведенням одного разу.

З іншого боку, IIRC, на той час справді мало хто піклувався про роботу Шенфінкеля - частково через те, як він (не) публікував її, - документи переважно писали колеги на основі проведених ним досліджень (див. Тут , стор. 4) ; Каррі потім знову відкрив теорію.

Caveat: Я не історик, а аспірант з ПЛ, тому моя - це сучасна (і, сподіваюся, точна) точка зору на цю тему.

Редагувати:

Чому зв’язування тонке, трохи конкретніше

Для цього є дві грані - по-перше, реалізувати це важко. По-друге, метаматематика - це математика маніпулювання доказом: ця маніпуляція, як правило, є автоматичною, тобто це алгоритм - так що, по суті, ви стикаєтесь із усіма труднощами впровадження, плюс доказів щодо них. Нижче я наводжу приклади. Приклади мають сучасну перспективу - вони стосуються фактично формалізованих доказів. Однак деякі труднощі поширюватимуться на точні докази вручну - до тих пір, поки ви не обдурите деталі.

Це показує, що Шенфінкель просто дав перше рішення цієї проблеми, але це було далеко не остаточним.

Реалізація його тонка через тінізацію

$(\lambda f. f~1 + f~2) (\lambda x . x)$$(\lambda x . x)~1 + (\lambda x . x)~2$$(\lambda f x. f (f x))\ (\lambda g y . g~y)\ z$$(\lambda g y . g~y)\ (\lambda g y . g~y)\ z$$(\lambda y . (\lambda g y . g~y)~y)\ \ z$

$\lambda x y. x$$y$$\lambda y. y$$\lambda y'. y$

Гірше те, що контрприклади наївним алгоритмам важко побудувати, коли ви вже знаєте про проблему, не кажучи вже про те, коли ви цього не зробите. Помилки в майже правильних алгоритмах часто лежать непоміченими роками. Я чую, що навіть хороші студенти, як правило, не придумують (самостійно) правильне визначення заміни та уникнення заміни. Насправді аспіранти (включаючи мене) та викладачі не звільняються від цієї проблеми.

Це одна з причин, чому деякі (включаючи один з найкращих підручників з мов програмування, типів та мов програмування Бенджаміна Пірса) рекомендують безіменне представлення (не зовсім комбінаційна логіка, хоч вона і використовувалася, а швидше індекси deBrujin).

Докази про це тонкі

Виявляється, докази про зв'язування не простіші, ніж реалізація, як було сказано вище. Звичайно, правильні алгоритми існують, і докази щодо них існують - але без вдосконаленої техніки, для кожної мови, що використовує прив'язку, потрібно повторити докази, і ці докази просто дуже великі і дратівливі, якщо ви використовуєте визначення для прив’язки до ручки та паперу .

$B$$A$$A$$B$$B$

Далі я переглянув найкращий приклад того, "що піде не так, якщо ви спробуєте формалізувати стандартне визначення". Рассел О'Коннор (який знаходиться на цьому веб-сайті) формалізував першу теорему про незавершеність Геделя в Coq (доказ теореми такого типу, що згадувався вище) - і ця теорема передбачає логіку (з усіма відповідними алгоритмами) в іншій логіці (із синтаксисом перша логіка кодується як числа). Він використовував визначення, які використовуються на папері, і формалізував їх безпосередньо. Шукайте "заміну" або "змінну" і підраховуйте, як часто вони з'являються посиланням на проблеми, щоб отримати враження. http://r6.ca/Goedel/goedel1.html

Я ніколи не використовую ці визначення у своїй роботі, але кожен альтернативний підхід має певний мінус.