Christian wrote: > In Chapter 10: > > "A definition in the sequence of forms must not define any > identifier whose binding is used to determine the meaning of > the undeferred portions of the definition or any definition > that precedes it in the sequence of forms. For example, the > bodies of the following expressions violate this restriction." > > is there a definition of "used to determine" and "undeferred > portions"?
The R6RS contains no formal definition of those phrases. The formal definition used by Larceny is found in lib/R6RS/r6rs-expander.sch: every call to register-use! records a binding "used to determine the meaning of the undeferred portions of the definition or any definition that precedes it". > reason is that the following fails on larceny (when it > reaches the line "(add-to-box foo 1)"), and I'm not sure why > this falls into the restriction above ... (or if it falls > into the restriction I'm not sure how this restriction can > be computeable at all) > > http://paste.lisp.org/display/75331 That code defines foo after the meaning of foo has already been used to determine the outcome of a call to free-identifier=?. Here's the story: (add-to-box foo 1) gets transcribed to something like (begin (if-is-not-defined/stmt foo (define foo (make-box '()))) (box-content-set! foo (cons 1 (box-content foo)))) Macro processing of if-is-not-defined/stmt calls free-identifier=? several times, passing foo as an argument each time. That counts as a use of foo only if the call returns true, as in the last call to free-identifier=?. If there were no errors, then the final result of macro rewriting would be something like (begin (define foo (make-box '())) (box-content-set! foo (cons 1 (box-content foo)))) Because foo is defined by that code after the meaning of foo had been used to determine the outcome of a call to free-identifier=?, the macro expansion violates an absolute ("must") requirement of R6RS chapter 10. Larceny uses Andre van Tonder's implementation of libraries and macros, which does an excellent job of detecting errors like this. Other implementations of the R6RS might not be able to detect this violation, even though the word "must" implies that detection of this violation (and rejection of the program before any part of it can begin its execution) is an absolute requirement of the R6RS. Since the R6RS offers no formal definition of its requirement, I don't think you should become too upset about implementations that fail to enforce it. Will _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
