This page is part of the web mail archives of SRFI 93 from before July 7th, 2015. The new archives for SRFI 93 contain all messages, not just those from before July 7th, 2015.
> 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