[R6RS] Ticket #110: Remove double phase semantics

William D Clinger will at ccs.neu.edu
Tue Nov 28 17:57:09 EST 2006

Matthew wrote:
> I'm happy if programs are portable only when they use `datum->syntax'
> on things when an external representation in R6RS. Would "might raise
> an exception" be acceptable>

Yes.  I think that's exactly the right compromise.

> > Let's remember, however, that the reason it is important
> > for the low layer to exist outside the PLT library system
> > is that, in PLT Scheme, the library system uses separated
> > binding semantics.
> I still disagree. The syntax system needs to know how to communicate
> syntax objects from one phase to another. Sharing the set of symbol
> (and other) values makes it a lot easier, but it's not the only way
> implementation.

Granted.  On the other hand, the current draft R6RS does not
appear to require semantics-preserving communication between
phases, and at least one of the reference implementations does
not even try [1].

> Many Scheme implementations routinely use different representations for
> compile-time symbols and run-time symbols, right? Some of them, for
> example, use an interpreter to execute procedural macros, but the
> generated code is compiled and executed in a very different way.

Yes.  To mention just one example, we've been running Twobit
in Larceny (self-hosting) for about ten years, but we tended
to run Twobit in MzScheme under Windows because, until our
recent releases of Larceny/IA32, MzScheme was more convenient
under that OS.  I have no idea how symbols are represented in
MzScheme, and it doesn't matter in the least.

The reason it doesn't matter for separate compilation is that
marshalling via external representations (or some equivalent
mechanism) solves the problem.  With interactive REPLs or
eval, however, that marshalling is normally omitted, as in
Andre's reference implementation [1].  Andre's recent posts
were the immediate cause of my alarm.


[1] http://lists.r6rs.org/pipermail/r6rs-discuss/2006-November/001197.html

More information about the R6RS mailing list