[r6rs-discuss] Now, where were we?
samth at ccs.neu.edu
Tue Feb 24 08:53:48 EST 2009
On Mon, Feb 23, 2009 at 2:59 PM, William D Clinger <will at ccs.neu.edu> 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  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
Nor do I know anyone who's suggested a way to make this work ,
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".
 I've verified this in PLT Scheme's Module language, Larceny's
ERR5RS REPL, and Ikarus' default REPL.
 Obviously, mandating the most straightforward of interpreter
semantics makes this work, but that would seem like a mistake for
samth at ccs.neu.edu
More information about the r6rs-discuss