Блог

В книге SICP описывается, как реализовать интерпретатор Scheme в Scheme. Я играю с этим и выключаю уже несколько месяцев, и мой код эволюционировал от книги. Теперь я достиг стадии, когда, внедрив strict-eval процедуру, я пытаюсь реализовать lazy-eval аналог, который всегда возвращает ‘thunk’ (некоторый объект, инкапсулирующий выражение и информацию о среде и запоминании). У меня есть force-thunk процедура, которая оценивает thunk с запоминанием. Моя быстрая и грязная реализация в настоящее время возвращает оболочку thunk вокруг set! выражения, и, конечно, это приводит к странной семантике (никакого побочного эффекта не возникает, пока thunk не будет принудительно выполнен). У меня очень возникает соблазн изменить это, и моя lazy-eval процедура должна быть строгой для set! выражений. На самом деле, чтобы быть более точным, я подумываю о том, чтобы отложить оценку присваиваемого выражения (поэтому создайте из него блок), но не откладывать изменение привязки (т. Е. Немедленно Назначить символ новому блоку в среде). Есть ли какая-либо причина, по которой я должен отложить побочный эффект?

set! изменяет привязку и изменяет интерпретатор с ссылочной прозрачности на необходимость обрабатывать меняющийся мир. Я думаю, я согласен с вашим описанием, что привязка должна ассоциироваться с новым thunk вместо старого, таким образом, привязка не установлена ленивой, но ее значение по-прежнему лениво.

 (define x expression) ; ==> x is a thunk
(set! x (  x x)       ; ==> x is a new thunk that references the old `x`
(display x)           ; display would force the evaluation of the nested thunks referenced by `x`
  

Если вы отложите фактическую фазу привязки, то приведенный выше код никогда не будет принудительно возвращать возвращаемое значение из set! -expression поскольку оно никогда не используется и, следовательно x , будет принудительно введенным старым thunk display ?