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

From: William D Clinger <will>
Date: Thu Nov 30 12:10:52 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.

Sam Tobin-Hochstadt quoting me:

> > 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.
>
> How would this work if a library that had to be invoked-once was
> imported by one that had to be invoked multiple times? Or the other way
> around?

If library (r6rs base) has invoke-once semantics, and is
imported by a library (r6rs) that is invoked separately
for each phase and has separated binding semantics, then
(r6rs base) would be invoked only once, no matter how
many times (r6rs) is invoked. The identifiers that are
exported by (r6rs base) would be re-exported multiple
times by (r6rs), possibly at different phases, but the
initialization of the table used by string->symbol would
be performed only once, and there would be only one copy
of the actual string->symbol procedure.

If library (foo) has invoke-separately-for-each-phase
semantics, and is imported by library (bar), then (foo)
would definitely be invoked the one and only time that
(bar) is invoked.

Andre van Tonder quoting me:

> > 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.
>
> I don't think I would agree with this. I achieve both the
> separate-binding and shared-binding semantics by translation
> to the system r5rs Scheme via name-mangling of variable
> references (the main difference being that the latter
> requires a little more name-mangling than the former), while
> all constant literals are translated to constant literals of
> the system Scheme....

It sounds to me as though your implementation translates
to a target language that offers a reliable semantics for
symbols. Please forgive me if I am reading too much into
your description.

If you are suggesting that some implementors will use some
non-R6RS language as their systems programming language, then
we are in complete agreement on that. If R6RS Scheme were
to require separated binding, invoke-separately-for-each-phase
semantics, then *all* implementors would be likely to use
some non-R6RS language as their systems programming language.

Will
Received on Thu Nov 30 2006 - 12:10:11 UTC