[R6RS] syntax-case semantics

[dyb at cs.indiana.edu]

> > Incidentally, I have not proposed to include a syntax-object?  predicate
> > or to require that syntax objects be distinct from other types.
>
> 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 agree, and I'm willing to specify full opaqueness.

> 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.

I find opaqueness aesthetically more pleasing, cleaner, and more rigourous
from a user's standpoint.  Yes, the mostly s-expr representation is more
convenient for a small class of macros, but it's not a lot of trouble to
use syntax->list, and one could trivially write syntax->s-expr that recurs
down to the identifier level if one didn't want to be bothered with using
syntax->list at multiple levels.

I think users are also sophisticated enough to appreciate what you refer
to as implementation arguments as well, like constant expansion overhead,
straightforward support for preservation of shared structure and cycles in
constants, and tractable source-object correlation both in memory and in
compiled files.

Kent