[R6RS] syntax-case semantics

[Anton van Straaten]

Michael Sperber wrote:
> William D Clinger <will at ccs.neu.edu> writes:
> 
> 
>>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.

Me too.  Compound syntax represented as lists has obvious utility and 
appeal, and it's likely to be popular.

> I remember my first steps trying to use explicit-renaming macros, and
> trying to understand the SYNTAX-CASE papers, and the fact that
> compound syntax are lists there always confused me to no end as a
> user.  This may be a presentation issue,  [...]

I experienced something similar, but I do think it's a presentation 
issue.  Although the list structure of syntax objects was described in 
the papers, it wasn't exploited much in the examples, since the focus 
was of course on the pattern matching.  A few examples focusing on using 
the list structure of syntax would probably have been sufficient to 
drive the point home.

In the SRFI 72 case, the fact that the quasisyntax form uses standard 
quasiquote syntax pretty much does it.  This was less obvious in the 
original syntax-case because there was no quasisyntax form.

> I still find it, as a user, counterintuitive and ad-hoc to (to
> formulate this in very naive terms) overlay datums upon syntax and
> only selectively change those bits (the symbols/identifiers) that get
> affected by the particular notion of hygiene we have, and thus
> allowing annotation, and not do it for the rest.

Presumably *any* notion of hygiene is only going to involve identifiers, 
not other kinds of literal values, so from that perspective, it seems 
unnecessary to wrap such literals, i.e. leaving them unwrapped is not 
ad-hoc.

But if that's the only issue, atomic literals and vectors could be 
represented as syntax objects while still maintaining the list structure 
of syntax.  That would still allow car/cdr navigation of syntax, which 
seems to me the main usability benefit of the approach.

Anton