[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SRFI-24 quibbles

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.


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:


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

"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.