On Mon, Feb 23, 2009 at 2:59 PM, William D Clinger <[email protected]> wrote: > 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.
Ok, I'm glad we're now clear on this. >> 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? I don't think this is an objection to either semantics - I think both are quite useful. However, neither of them shed light on the question of how REPLs should support macro definitions while integrating with R6RS-style top-level programs. >> 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. I agree that the semantics is not set in stone, and I also hope that the problems of specifying how to import libraries not defined in the R6RS is addressed. However, every implementation of the R6RS has provided a way of importing libraries that are not defined by the R6RS, so we know that this is feasible. To my knowledge, no implementation [1] of the R6RS has provided a REPL for interacting with R6RS libraries or programs that handles the `define-inline' example in the similar way to how it is handled by an R6RS top-level program. Nor do I know anyone who's suggested a way to make this work [2], aside from Per's suggestion yesterday, even though this has been a problem for systems with both macros and REPLs for a long time. Thus my conclusion that "It's hard to give them a consistent semantics". [1] I've verified this in PLT Scheme's Module language, Larceny's ERR5RS REPL, and Ikarus' default REPL. [2] Obviously, mandating the most straightforward of interpreter semantics makes this work, but that would seem like a mistake for Scheme. -- sam th [email protected] _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
