Чи тривіальна контекстна еквівалентність мови з "цитатою" -еваль?


13

У роботі [1] Мітчелл Ванд продемонстрував, що додавання fexprs до чистого обчислення лямбда тривілізує теорію контекстуальної еквівалентності, тобто два терміни є контекстуально еквівалентними, якщо вони -конгруентні. При вивченні відповідної роботи, він пішов «наш результат розширює старе спостереження Альберт Мейєр [2] , що і візуалізації контекстна еквівалентності тривіальним». Але посилаючись на [2], те, що можна було знайти, є лише наступним твердженням Мейєра:αevalquote

Я перша подумала , що в мовах з quote- evalфункціями , такими як LISP [3] не було ніякого типу відмінності між синтаксичними і виконуваними об'єктами. Насправді quote- evalздається досить безпечним у LISP, тому що, хоча quoteсинтаксично виглядає як добросовісний оператор, як скажімо cond, він насправді не поводиться як один (він має поведінку лише за час розбору, а не час виконання, наприклад, не може пройти quoteяк параметр до процедури). Тим НЕ менше, я до сих пір побачити переконливі приклади , де quote- evalфункція була стоїть.

Незалежно від одного незначного недоліку в цих коментарях, який може ввести читача в оману, щоб зробити висновок про те, що він condможе бути переданий як параметр до процедури. Якщо я правильно розумію, те, що сказав Мейєр " quote- evalздається досить безпечним", означає, що quote- evalможливо, не тривілізує теорію рівнянь, хоча він не запропонував доказів.

Редагувати:

Як запропонував Мартін, оскільки всі три статті цитуються, що стосуються сімейних мов LISP, давайте поставимо питання під цією ж установкою. Чи контекстна еквівалентність мови з quote- evalзокрема LISP - на землі тривіальною чи ні?

[1] Мітчелл Ванд, теорія Фекспрів тривіальна . Лісп і символічні обчислення 10 (3): 189-199 (1998).

[2] Альберт Мейєр, Пазли в практикумі програмування логіки з формальної розробки програмного забезпечення. 1984 рік

[3] Джон Маккарті, Рекурсивні функції символічних виразів та їх обчислення з допомогою машини, частина I . Комунікація ОСББ у квітні 1960 року.


1
Я б запропонував подумати, чи можете ви поставити запитання більш конкретним: існують різні способи реалізації eval / quo як конструкти, а також різні варіанти розробки контекстуальних еквівалентів для таких обчислень. Цікавою нещодавньою пов’язаною публікацією є Разум про багатоступеневі програми від Inoue, Taha.
Мартін Бергер

1
Ключова відмінність - це CTMP (метапрограмування під час компіляції, як це пояснюється на шаблонах Haskell, Lisp / Scheme / Racket і Converge) , і RTMP (метапрограмування під час виконання, наприклад, eval Javascript або MetaOCaml). Іншим параметром є введення тексту. . Ось короткий огляд розмови я дав кілька місяців тому на цю тему, зовсім неглибоко , боюся Що стосується контекстні еквівалентностей, мало роботи було зроблено, в основному , що володіє в рідкому стані програмування підтримку мета-програмування ..
Мартін Бергер

1
@ plmday: BTW, ідеалізована мова програмування Wand формалізується в «Теорії Fexprs Is Trivial» сильно відрізняється від метапрограмування, яке робить Lisp. Перший - RTMP, другий (залежно від конкретних реалізацій) - ні.
Мартін Бергер

1
@MartinBerger: Чи можете ви розмістити свою розмову у форматі PDF?
Дейв Кларк

1
@ Дейв Кларк, звичайно, ось це! Відгуки Ласкаво просимо.
Мартін Бергер

Відповіді:


2

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

Традиційно контексти для контекстуальної еквівалентності прийнято вважати контекстами, в яких "вирази", у будь-якому сенсі, що має мову, можуть з'являтися. Це виключає такі контексти "[]", коли контекст розміщує свій аргумент у прямому рядку. Такі види контекстів також були, IIRC, виключені Квіном, коли він спочатку описав референтну прозорість.

З цієї точки зору, я думаю, (quote [])це також не контекст. Натомість контексти - це місця, де потенційно може відбуватися оцінка виразів, наприклад, в тілі функції або в аргументі програми.

Потенційно проблематично, це означає, що в програмі Lisp з макросами (або програмою Racket або Scheme) ви не знаєте, що таке контексти, доки не запустите потенційно невизначальний процес розширення макросу, оскільки ви навіть не знаєте, де вирази є. Ви вважаєте це проблемою чи ні, це здебільшого філософське питання, а не технічне.


Я не думаю , є один спосіб , щоб виключити (quote []), а не видавати бажане за дійсне, як контекст: відкидаючи ідею лікування , 'datumяк синтаксичний цукор для (quote datum), тоді '[]як "[]"більше не є контекстом. Макроси схеми quoteвсе одно затьмарилися .
день

Я не розумію ваш коментар, @day. Чому стосунки між собою 'datumі що- (quote datum)небудь змінюють?
Сем Тобін-Хохштадт

Якщо quoteце мовна конструкція і 'datumпризначається (quote datum), люди швидше заперечать , що (quote [])це контекст. Якщо ми видалимо quoteз основної мови, але підтримуємо буквальний 'datumсинтаксис, то вони, швидше за все, будуть міркувати, тому що подібне, "[]"як відомо, не є контекстом.
день

@day, це непорозуміння. Немає жодного правильного визначення поняття "контекст". Просто різні контексти підтримують різні поняття контекстної еквівалентності. Наприклад, пробіл є семантично значущим в "[]"контексті, але не в (quote [])контексті. Що можуть "сперечатися" люди, немає ні тут, ні там.
Сем Тобін-Хохштадт

Я погоджуюся, що немає жодного правильного визначення контексту. Але є одне традиційне визначення, засноване на абстрактному синтаксисі, те, яке Ванд використовує у своїй роботі, а Мейєр використовує у своїй статті, щоб поставити під сумнів статус контекстної еквівалентності Ліспа. Що ви запропонували, це замінити традиційне визначення контексту контекстом оцінювання. Що я запропонував - це збереження традиційного визначення контексту, вилучення quoteз абстрактного синтаксису, але підтримка (конкретного) буквального синтаксису (простір-незначного) цитати. З того, що я бачу, обидва способи призводять до "Ні" до початкового питання.
день
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.