[r6rs-discuss] [Formal] Trivial Enhancement of macros in v5.91: capture-syntax

From: William D Clinger <will>
Date: Thu Nov 30 09:24:27 2006

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.

Andre van Tonder quoting me:

> > Yes, they would be non-generative, but with the draft
> > R6RS that is expressed by using a symbol. With the
> > separated binding, invoke-separately-for-each-phase
> > semantics, an L1-symbol is not an L0-symbol.
>
> Or are they ;-) Presumably symbols themselves cannot be implemented
> as a non-generative record type without running into a circularity
> issue, so I guess they must either be generative or truly primitive.
> But I don't think they can be generative, since the draft says "two
> symbols are identical (in the sense of eq?, eqv? and equal?) if and
> only if their names are spelled the same way", which I interpret to
> imply that an L1-symbol must indeed be eq? to an L0-symbol with the
> same spelling, assuming both are covered by the r6rs term "symbols".

That's an interesting question, isn't it? To return to
your earlier example, must a Scheme-symbol be eq? to a
Java-symbol with the same spelling, assuming both are
covered by the r6rs term "symbols"?

> As another consequence, I infer from the section on equality
> predicates that the corresponding strings obtained via
> symbol->string must be string=?.

You appear to agree with me that the separated binding,
invoke-separately-for-each-phase semantics won't really
work unless the fundamental types are known to be the same
in L0 and L1.

It does not appear possible to achieve that property if
those fundamental types are implemented in R6RS Scheme
using the separate binding, invoke-separately-for-each-phase
semantics.

Implementors who wish to use R6RS Scheme as their systems
programming language will figure that out, and are likely
to solve the problem by adopting the shared binding,
invoke-once-per-session semantics.

Implementors who use some other language as their systems
programming language might use the separated binding,
invoke-separately-for-each-phase semantics.

That is how we end up with the library system of the draft
R6RS.

It seems to me that we could solve the problem by allowing
each library to declare whether it wants to be invoked
separately for each phase. That would make it possible
to implement string->symbol and the fundamental types in
R6RS Scheme, using invoke-once-per-session libraries,
while allowing programmers who prefer to think of L0 and
L1 as completely unrelated languages that just happen to
have exactly the same fundamental syntax and fundamental
types to go ahead and think that way.

Will
Received on Thu Nov 30 2006 - 09:24:18 UTC