This page is part of the web mail archives of SRFI 24 from before July 7th, 2015. The new archives for SRFI 24 contain all messages, not just those from before July 7th, 2015.
Hello! I'm afraid the equivalence (letrec-mixed ((macro-name transformer) ...) ((variable init) ...) body body2 ...) = (let ((variable #unspecified) ...) (letrec-syntax ((macro-name transformer) ...) (set! variable init) ... body body2 ...)) is not entirely correct with respect to R5RS (even if we remove (macro-name transformer)). Al* Petrofsky explains the reason in the following discussion thread: http://groups.google.com/groups?hl=en&selm=87bsoq0wfk.fsf%40app.dial.idiom.com The equivalence rule also has a technical error, which it inherits from the R5RS definition of letrec (the 'body' may actually be a 'define' form). I'm afraid I don't understand how the set!-free implementation outlined in the corresponding section differs from the set!-based implementation. "Upon run-time, an environment frame (a set of locations) is created when the evaluation of letrec starts, and the alpha-converted variables v* denote each one slot in this frame. The frame contains originally undefined values. The initializing expressions e are evaluated in some order and the resulting values are written to the environment frame." According to this description, the "set!-free" implementation destructively mutates the bindings -- which is exactly what set! does. Calling an environment frame "a set of locations" is perhaps somewhat simplistic: the environment is a set of bindings; some Scheme implementations may choose to make bindings mutable to avoid introducing any "locations". Is the section "Note on set!-free implementations" really necessary at all? R5RS definitely defines regular letrec using set!. There are pure-functional _approximations_ to letrec, but they can never be completely precise, as Amr Sabry showed. Thus a set!-free letrec can't satisfy R5RS.