Email list hosting service & mailing list manager


SRFI-24 quibbles oleg@xxxxxx 30 Jan 2002 04:30 UTC

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.