Sam TH wrote: > I believe that this would cause the `define-inline' example to produce > an error, just as it does in current implementation of REPLs for > interacting with R6RS programs, such as Larceny's ERR5RS mode.
Ah, you are right! I was misreading your original example, thinking it was designed to illustrate the ambiguity in the semantics of R5RS top-level definitions. With my semantics, your example results in a call to an undefined variable, which is one of the standard errors that most R5RS REPLs already detect. > Would this be accomplished by making the suggestion of section 5.2.1 a > requirement, and thus making this a portable program: > > (set! this-id-does-not-exist 42) That is an orthogonal question. The semantics I suggested would not allow that unless the R5RS restriction against such things were also dropped. > I'm confused. The semantics of R5RS section 7.2 (the non-normative > denotational semantics) does not specify the behavior of macros, The semantics of the corresponding section of the R6RS, Appendix A, also does not specify the behavior of macros. > Again, the semantics of R5RS Section 7.2 does not mention macros, so > we'd have to come up with some fix for that, perhaps along the lines > of what you've suggested above. Why do you take that as an objection to the R5RS semantics, but not to the R6RS semantics? > However, the semantics you suggested > above are not the same as the semantics that R6RS assigns to top-level > programs, in which the `define-inline' example I provided displays the > expected string. As I have stated many times, and as your examples also prove, the R6RS semantics for top-level programs is not compatible with REPLs. As a logical consequence of that, any proposal that would make the semantics of top-level programs compatible with REPLs will have to be different from the R6RS semantics. The R6RS semantics of top-level programs is not set in stone. For example, the R6RS semantics of top-level programs that import from libraries other than the specific libraries described in the R6RS documents is explicitly implementation-dependent. Many of us would like to fix that, just as many of us would like to fix the incompatibility with REPLs. Will _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
