[r6rs-discuss] [Formal] Remove double phase semantics
aghuloum at cs.indiana.edu
Sat Nov 25 21:13:52 EST 2006
On Nov 25, 2006, at 7:16 PM, William D Clinger wrote:
> I am posting this as an individual member of the Scheme
> community. I am not speaking for the R6RS editors, and
> this message should not be confused with the editors'
> eventual formal response.
> AndrevanTonder wrote:
>> The much cleaner semantics is the one in which a separate set of
>> bindings is instantiated for each level.
> Marcin 'Qrczak' Kowalczyk questioned whether that semantics
> works for this use case:
>> Let's imagine a Scheme compiler which hosts its own interpreter.
>> Certain libraries (e.g. the standard library) are provided only in
>> compiled form, and the interpreter just links to their version which
>> is compiled into the interpreter program instead of interpreting
>> source. Assume that they contain mutable state.
> 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.
Right. And not only would string->symbol produce different
symbols, every use of string->symbol at macro-expansion time
would produce different symbols. This makes it extremely
hard to write useful macros that construct automata, parsers,
generate code based on database schemas, etc.
> 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
Maybe the draft doesn't require symbols to be different, but
in practice, I think it does in every implementation. With
separate sets of symbols at every phase, a macro cannot even
perform test (eq? (syntax->datum #'x) 'the-symbol).
> 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. Also, I don't think R6RS should even specify the
obvious that the symbol 'car' is the symbol 'car' is the
symbol 'car' no matter where or what or when. Phases aside,
foo in Chez scheme is the same as MzScheme's foo is the same
as Larceny's foo. Why should it be different across phases
in the same implementation!
More information about the r6rs-discuss