[R6RS] syntax-case semantics

[Anton van Straaten]

> Whether there's a hygiene issue here is debatable.  I say there's not one,
> because in my mind, hygiene issues involve interactions between macros,
> not within a single macro.  

I agree that the terminology isn't quite right.  It could be called a 
meta-hygiene issue, though.

At least in theory, it means that writing reusable and reliable 
syntax-generating procedures for use by macros should be trickier, since 
such a procedure has to take special steps to avoid having variables it 
introduces capture variables from the invoking macro's syntactic 
environment.

Such procedures are potentially unhygienic with respect to the invoking 
macro's syntactic environment, in that they can perform unintended 
capture.  This is analogous to the unhygienic relationship between e.g. 
a defmacro macro and the normal Scheme environment -- it's just 
occurring higher up the tower.

> While the SRFI 72 semantics is slightly simpler, the traditional semantics
> is easier to work with.  (There is a tacit admission of this fact in the
> SRFI exception that commonizes identifiers in unquoted nested quasisyntax
> forms.)  

Agreed.  The "meta-unhygiene" is often desirable, since the procedural 
code may deliberately want to deal with a variable that exists elsewhere 
in the same macro.

However, this is only likely to apply when a macro is fairly 
self-contained.  If a macro depends on a procedure defined elsewhere, 
the traditional semantics for SYNTAX starts to seem less appropriate: 
it's relying on a kind of dynamic environment to manipulate lexical 
variables, and that doesn't really seem to scale across procedure 
boundaries.

Essentially, the SYNTAX form should probably not be used to return much 
more than trivial syntax from stand-alone procedures.

> I might buy the "hygiene issue" or whatever you want to call it if
> I had ever run into it or seen anyone else run into it, but I haven't.  So
> I prefer the traditional semantics.

I assume that in practice, macros don't often rely on syntax-generating 
procedures of the sort which would trigger this issue.  One reason for 
that is probably that such procedures in the context of syntax-case 
would be likely to be written as macros themselves, and a separate macro 
introduces its own environment, which solves the problem.

Might it make sense to add to traditional syntax-case something like a 
FRESH-SYNTAX form, which uses the SRFI 72 semantics?  That would allow 
the sorts of problem examples given in the SRFI to be written safely and 
easily.

Of course, if this really would be solving a non-existent problem, then 
there'd be no point.  However, I'm not so sure that it's non-existent. 
It seems likely to me that this could come up when refactoring 
procedural macros.

Anton