SICP 책은 Scheme에서 Scheme 인터프리터를 구현하는 방법을 설명합니다. 나는 이것을 몇 개월 동안 켜고 끄고 놀았고 나의 코드는 책에서 벗어났다. 이제는 strict-eval
절차를 구현 한 단계에 도달했으며 항상 표현식 및 환경 및 메모 정보를 캡슐화하는 '썽크'를 반환하는 lazy-eval
대응 물을 구현하려고 시도하고 있습니다. 난 force-thunk
메모와 함께 썽크를 평가하는 절차가 있습니다. 내 빠르고 더러운 구현은 현재 set!
표현 주위에 썽크 래퍼를 반환하며 물론 이상한 의미 (썽크가 강요 될 때까지 부작용이 발생하지 않음)가 발생합니다. 나는 이것을 바꾸고 나의 lazy-eval
절차가 엄격한 표현 인 set!
에 매우 유혹 당한다. 사실, 더 정확하게 말하면, 할당 된 표현의 평가를 지연 (그래서 썽크를 생성)하지만, 바인딩의 변경을 지연시키지 않아야합니다 (즉, 환경에서 즉시 새로운 썽크에 심볼을 할당하십시오). 부작용을 지연시켜야하는 이유가 있습니까?게으른 평가를해야합니다! 사실 엄격한가?
0
A
답변
1
set!
은 바인딩을 변경하고 참조 투명성에서 인터 피터를 변화하는 세계를 처리해야하는 것으로 변경합니다. 나는 당신의 묘사에 바인딩이 오래된 것 대신에 새로운 덩어리로 묶여 져야한다고 동의한다고 생각한다. 그러므로 바인딩은 게으르지 만 값은 여전히 게으르다.
(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`
그런 다음 실제 바인딩의 위상을 지연하는 경우 display
에 강제로 이전 썽크가 사용되지 않습니다 때문에 set!
-expression에서 반환 된 값을 강제하지 않습니다 따라서 x
가 될 것이다 위의 코드?
+0
대단히 고마워요! –
''set! '(및 몇 가지 다른 기본 요소)를 엄격하게 지정하지만 값을 강제로 지정하지 않는 경로는 [Lazy Racket]입니다 (http://docs.racket-lang.org/lazy/index.html).)가 선택했습니다. – molbdnilo
대단히 감사합니다! –