Что, если таковые имеются, является неправильным с этим определением letrec в Схеме?
R5RS дает предложенные макроопределения для форм библиотеки синтаксиса:
http://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.3
Который также определяет letrec, очень сложным способом, конечно, не, как я определил бы его, я буду просто использовать:
(define-syntax letrec2
(syntax-rules ()
((letrec2 ((name val) ...) body bodies ...)
((lambda ()
(define name val) ...
body bodies ...)))))
Насколько я понимаю семантику letrec, который я использую очень часто, поскольку именованное позволило. Это работает таким образом, однако поскольку у меня была своя справедливая доля дебатов с философами, которые думают, что могут просто опровергнуть специальную относительность или установленные фонологические теории, я знаю, что, когда Вы думаете, что у Вас есть простое решение сложной проблемы, это, вероятно, НЕПРАВИЛЬНО. Должна быть некоторая точка, где этот макрос еще не делает satify семантика letrec, они, вероятно, использовали бы его.
В этом определении определения локальны для тела letrec, они могут обратиться друг к другу для взаимной рекурсии, я не совсем уверен, что (если таковые имеются) является неправильным.
4 ответа
Хорошо, я наконец нашел причину, это так просто, как бесполезно, в моем определении нет ничего неправильного, и на самом деле это связано с некоторыми ошибками, превосходящими ошибку в R5RS.
http://community.schemewiki.org/?scheme-faq-macros
Ищите 'letrec', вы все не смогли бы ответить на мой вопрос о том, что не так, очевидно, все было не так, R5RS имел "опечатка" в информативном разделе очевидно. Думаю, теперь я буду вынужден принять свой ответ ...
Возникает вопрос, почему авторы R5RS не выбрали это простое решение и выбрали очень сложное, которое даже содержало ошибку .. .
Хороший вопрос.
Я думаю, что проблема с последовательностью define заключается в следующем:
«Порядок оценки выражений expr ... не указан, поэтому программа не должна оценивать ссылку на какую-либо из переменных , связанных выражением letrec, до того, как будут вычислены все значения »
Здесь: {{1} } http://www.scheme.com/tspl4/binding.html#./binding:s20
R5RS утверждает, что семантика letrec точно такая же, как и у внутренних определений. См. раздел, посвященный последнему для деталей; Я цитирую ключевой фрагмент ниже:
содержащие внутренние определения всегда могут быть преобразованы в полностью эквивалентное выражение
letrec.
Таким образом, определение letrec в терминах внутренних определений просто смещает проблему вокруг.
Кроме того, я считаю, что проще определить макрос letrec и иметь внутренние определения lambda desugar в letrec, чем вставить весь этот сложный код в обработчик lambda и построить letrec поверх этого. Это не касаясь вопроса о том, какая форма введения взаимно рекурсивных привязок в область не верхнего уровня... ;-)
Мне кажется, что вы переложили ответственность за реализацию с макроса на компилятор, чего разработчики R5RS, похоже, пытаются избежать.
На самом деле в R5RS локальные определения реализованы с помощью letrec. См. 6.2.2 Внутренние определения.
Я думаю, что намерения разработчиков хорошо подытожены во введении к R5RS:
Языки программирования должны разрабатываться не путем нагромождения функций поверх возможностей, а путем устранения слабости и ограничения, которые делают дополнительные возможности кажутся необходимыми. Схема демонстрирует, что очень небольшое количество правил для формирования выражений, без ограничений на как они составляются, достаточно, чтобы сформировать практичный и эффективный язык программирования язык, который является достаточно гибким, чтобы поддержки большинства основных парадигм, используемых сегодня.
edit1: Пример внутренних определений, преобразованных в r5rs-версию letrec. PLT scheme 4.2.5 collects/r5rs/main.ss
(define-syntax (r5rs:body stx)
(syntax-case stx (let)
[(_ (let () . body))
#'(let () . body)]
[_
;; Convert internal definitions to `r5rs:letrec', as opposed
;; to `letrec'.
...
В PLT Scheme в режиме R5RS действительно преобразует внутренние определения в R5RS-версию letrec. Вы также можете проверить это сами, используя макрорасширитель DrScheme на любом коде с внутренними определениями.