[r6rs-discuss] [Formal] Remove double phase semantics

[Matthew Flatt]

At Sat, 25 Nov 2006 19:16:10 -0500, William D Clinger wrote:
> Here's another use case that seems more likely to work with
> shared bindings than with the allegedly cleaner semantics:
> 
> Suppose string->symbol is implemented as a library, using a
> hash table that maps strings to symbols as its mutable state.
> With shared bindings, I think procedural macros would see the
> same symbols that are seen at run-time.  With the allegedly
> cleaner semantics, the symbols that would be available to
> procedural macros at macro expansion time would be completely
> different from the symbols that exist at run time.

I see no problem with that. One point of the separation is that an
implementor could make this choice. Maybe symbols tend to be used in
different ways at compile time and run time, so it's useful to have
different representations?

> Maybe that doesn't matter; I don't see anything in the draft
> R6RS that would require the symbols seen at macro expansion
> time to have anything to do with the symbols seen at run
> time. 

I'm not sure what it would mean to require them to be the same.

Suppose I compile a MzScheme program on my PPC machine today and run it
tomorrow on an x86 machine. In that case, the compile-time and run-time
representations of symbols are different. The only connection between
them is an external representation.

> If the R6RS were to require symbols to be the same
> at run time and at macro expansion time, however, then the
> R6RS ought not to require a semantics that makes it difficult
> or impossible to implement string->symbol in Scheme.

I agree with "doesn't matter". I don't think an R6RS programmer can
tell the difference, given that (according to the current draft) a
programmer can't rely on sharing between compile time and run time.

Matthew