[R6RS] syntax-case semantics

[William D Clinger]

Kent wrote:
> > I also prefer SRFI 72's less opaque definition of a syntax object,
> > because it is less mysterious and because it allows the authors
> > of procedural macros to reuse more of Scheme's standard library
> > without having to mess with syntax-object->datum or syntax->list.
>
> That's something I'm unwilling to consider for the surface langauge.

What does "unwilling to consider" mean in this context?  That
you will vote against it when we vote?  Or that you will not
allow this issue to come up for a vote?

> > ....There is no need for weak pointers.
>
> Unless, of course, you consider syntax objects (particularly, identifiers)
> that remain in the system indefinitely as part of macro-generated
> transformers, including those that are recorded in compiled files, at
> which point even a weak hash-table approach becomes messy at best.

So far as I know, we are not considering anything that would
require macro-generated transformers to be recorded in files
at all, let alone compiled files.

Keeping macro-generated transformers in files (compiled or
otherwise) *does* create a need for weak pointers to files,
but not for weak pointers to objects.  The file containing the
macro-generated transformers should disappear when any of the
files/systems that contributed to it disappear or change.  In
particular, any change in a source file might invalidate some
of the source code location information anyway.

It follows from this that implementations that choose to keep
macro-generated transformers in files (compiled or otherwise)
are going to have to attach dependency information to those
files.  Treating source code location information as part of
that dependency information is no big deal.  You can do that
without using weak pointers to objects.

What it comes down to, then, is the preservation of source
code locations for syntax objects that are embedded within
macro-generated transformers that might be called during
macro expansion of definitions and expressions that are
typed into a read/eval/print loop or something similar.

In Larceny, I know how to find all macro-generated
transformers that would be created during macro expansion,
how to find all syntax objects to which they refer, how to
extract information about their source code location from
the temporary hash table, and how to transfer that information
to a permanent hash table.

I doubt whether I would bother to use weak pointers for that
permanent hash table, since any macro-generated transformers
that outlive the macro expansion of the library that created
them are likely to remain reachable themselves until that
library is reloaded.  Although Larceny does provide weak
pointers (as an experimental and undocumented feature), I
would not use weak pointers unless I decide to concern myself
with long-term storage leaks caused by unbounded reloading of
libraries that create macro-generated transformers.  I doubt
whether I would ever become terribly concerned about that
particular source of storage leaks.

Will