> Section 3 mentions "singleton identifiers" as a possible form for
> syntax abstractions, and refers to section 3.6 for more information. I
> couldn't find this in 3.6.

This should probably have been a reference to Section 3.4, which mentions
what happens when a keyword appears in ``any other definition or
expression context,'' i.e., not in the first position of a list-structured
input form.

> The interpretation of DEFINE-SYNTAX according to section 3.3 seems
> to be difficult to integrate with the expansion of internal
> DEFINEs into LETREC* forms. Would it be possible to add a
> definition of the full expansion process in the SRFI here?

Section 3.1 describes body expansion in detail, but what it doesn't do is
explicitly say that the expander constructs a letrec* form from the
defined variables, expanded right-hand-side expressions, and expanded body
expressions.  I've made a note to add this.

> According to section 3.4, transformers are procedures which accept a
> single argument. Not only is this incompatible with existing systems
> (such as explicit renaming), it is also problematic for later
> extension. I think it would be more useful to use a new form here,
> such as (SYNTAX-TRANSFORMER STX (SYNTAX-CASE STX ...)) or
> (SYNTAX-LAMBDA (STX) (SYNTAX-CASE STX ...)).

This is definitely worth considering.  Although it would require a lot of
existing code to be updated, it should be a relatively easy change to
make, and it does allow for implementation and possible future RNRS
extensions, as you say, like adding an environment argument to give access
to the compile-time environment.

> Variable transformers are introduced in the same section. The
> whole purpose of this seems to be to allow a generalized SET!
> similar to SRFI-17. This seems somewhat kludgey, and not very much
> related to the purpose of syntax transformation. What is the
> rationale to define a generalized SET! together with other syntax
> transformations, and not as a specific extension to SET!?

There's no overlap here with SRFI 17.  SRFI 17 allows one to define what
happens to assignments of the form:

  (set! (id e ...) e)

whereas variable transformers allow one to define what happens with
"ordinary" assignments of the form

  (set! id e)

This can be used, for example, to allow method bodies in an OOP system to
access instance variables as if they were ordinary variables, by
transforming references into the appropriate instance access operations
and assignments into the appropriate instance mutation operations.

> Finally, section 3.6 mentions #(pattern*) etc. as a possible
> pattern. R5RS does not allow vector literals, they do have to be
> quoted. Does this mean one can define #(foo) to be semantically
> meaningful syntax in R6RS? What is the rationale for allowing
> this?

A vector is not a valid form (definition or expression).  A syntactic
abstraction must be list- or improper-list-structured (with a keyword as
the first element) or a singleton identifier (a keyword).  A vector can
appear as part of the syntax of a syntactic abstraction, however, and the
syntax is useful if you ever want to delve into a constant that may
contain vectors.

Thanks for your feedback.

Kent Dybvig