[R6RS] Ticket #110: Remove double phase semantics

[Matthew Flatt]

At Tue, 28 Nov 2006 11:13:42 -0500, William D Clinger wrote:
> If we can't require sharing across phases, the best we
> can do is to allow it, while making sure that nothing
> else in the R6RS inadvertently assumes the separated
> binding semantics.

I agree with this conclusion.

> As stated earlier, I think it is important we not restrict
> the domain to datum->syntax to datums.

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>


In case it's useful, I offer a few more clarifications:

> > It's because the module system exists on top of of the layer that
> > defines external representations.
> 
> Agreed.  The reason that matters is as I said: the layer
> that defines external representations must use a shared
> binding semantics.
> 
> The bottom line is that implementors who want to write
> most of their code in Scheme, and allow Scheme libraries
> to define new types and new external representations,
> will use a shared binding semantics for libraries.
> 
> > The fact that the lower layer is in C is unfortunate, but not
> > important. The fact that the low layer exists outside the library
> > system is indeed important.
> 
> 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.

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.

> > But, it's also not important that the lower layer persists across
> > phases. You can always separate compile time and run time in MzScheme
> > --- even at the level of symbols --- by restarting MzScheme.
> 
> Sure.  Persistence isn't what matters.  What matters is
> that two incompatible registries never exist within a
> single execution, or if they do exist then incompatible
> representations that result from incompatible registries
> become resolved via semantics-preserving marshalling.

Yes, that sounds right to me.

> > > To fix this problem, I recommend the following.
> > > 
> > >   * Accept the recommendation of Ticket #110, and require
> > >     implementations of R6RS Scheme to use the shared binding
> > >     semantics.
> > 
> > This doesn't seem practical to me. A compiler like Chicken, for
> > example, would have to package compiled code with all state accumulated
> > at expand time.
> 
> I give up.  What's so special about Chicken?

I just picked an implementation at random where programs are typically
run in a separate OS-level process than they are compiled.

Matthew