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

From: Andre van Tonder <andre>
Date: Thu Nov 30 15:11:52 2006

On Thu, 30 Nov 2006 dyb_at_cs.indiana.edu wrote:

> This makes sharing of system state, such as the symbol hash table used by
> the reader and string->symbol, both convenient and efficient. What if the
> application---or some system-like layer above the base
> implementation---has some reason to share state, say to cache
> configuration information loaded from a file? Doing so will not be as
> convenient or efficient, if it is even possible. I'm always suspicious of
> capabilities that are available only to the system.

Note that I withdrew the comment where I asked for unshared state at the
expense of shared - I was simply explaining how it can be implemented to avoid
the issues with sharing of constants. Also, in deference to the kinds of
requirements you describe, and to your arguments regarding performance or size,
I have made my implementation configurable so that the shared semantics can be
selected.

However, I would not wish the next draft to require the shared model at the
expense of the unshared. Rather keep both. The fact that the unshared model
exists in the current draft in fact forbids portable programs from using state
at macro-expansion time in precisely some of the ways that have been argued to
be bad style.

For example, as long as the cached information you describe is never
mutated, or only ever used at one level, I don't expect there to be an
observable difference (except performance) between the two models.
The current draft in fact requires portable program not to use mutation to
communicate across levels (even if one can do so in one of the models).
Discarding the unshared model would in fact loosen this last constraint on the
use of mutation at macro-expansion time by guaranteeing in effect that mutable
state may be used in portable programs to communicate across levels.

Cheers
Andre
Received on Thu Nov 30 2006 - 15:11:15 UTC