[R6RS] syntax-case semantics
Anton van Straaten
anton at appsolutions.com
Mon Mar 20 02:44:33 EST 2006
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
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.
More information about the R6RS