[R6RS] syntax-case semantics

[William D Clinger]

> Incidentally, I have not proposed to include a syntax-object?  predicate
> or to require that syntax objects be distinct from other types.  So while
> standardizing on SRFI 72's less abstract representation would limit
> implementation options and may inhibit various extensions, standardizing
> on the more abstract representation does not.  In particular, if we
> standardize on the more abstract representation, an implementation can
> still employ the SRFI 72 representation.

I'm worried that this is the worst of all possible worlds.
If we say syntax objects are not supposed to be taken apart
except by syntax-specific taker-aparters, but allow systems
to represent syntax objects as in SRFI 72, I think a lot of
systems are likely to do that, and we're liable to end up
with a portability problem: lots of SRFI-72-compliant macros
that aren't R6RS-compliant.

I was kind of hoping someone would offer an argument for
making syntax objects opaque that made sense from a user's
or macro writer's perspective.  Almost all of the SRFI 72
arguments for opaque syntax objects, and ours too, have
been argued from an implementor's perspective, mostly on
the source/object correlation.

Although SRFI 72's syntax objects are less abstract than
Chez Scheme's or MzScheme's, I think the syntactic tower
is more abstract, and offers some worthwhile advantages
for users, writers, *and* implementors.  This may have
something to do with the phasing problems that Matthew 
mentioned, so I'm anxious to get on with our discussion
of those issues.

Will