[R6RS] syntax-case semantics

[Anton van Straaten]

>>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.
> 
> 
> That's conceivable, but I believe it's a non-problem in practice, and I
> hate to complicate the common case to fix a non-problem.  

Good point.

BTW, I realized that I overstated the nature of the problem in the quote 
above: unintended capture can only occur if the code in question is 
passed a syntax object containing an identifier from the invoking 
macro's syntactic environment, and then uses that object within a scope 
which introduces a same-named identifier.

(Just for completeness, there's an alternative scenario in which 
procedural code could generate syntax which contains a free reference 
that is inadvertently captured by an identifier in the invoking macro's 
syntactic environment.  However, if that capture is unintended, then it 
means that the free reference would have been an error otherwise, so 
there doesn't seem to be a case for supporting this, except possibly 
from an error-checking perspective.)

>>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.
> 
> 
> That's a good idea, worth considering anyway.

Well, according to Matthew I seem to have reinvented 
make-syntax-introducer.  I'll have to read the PLT manual sometime! ;)

I do think that specifying something like this could be a good idea, if 
it doesn't complicate anything too much.  But I'll give this all some 
more thought, now that I have a better understanding of the issue and 
its context.  Thanks for all the input.

Anton