Yes, I think this change is helpful, giving clear definition of begin in transformer-spec and removes confusions.

On Sun, Apr 23, 2017 at 9:21 PM, Marc Nieper-Wißkirchen <> wrote:
Please excuse the long delay.

Could you please review the clarifications I added to the specification here:

If you think these changes are helpful, I will propose to incorporate the changes as an erratum to this SRFI because, technically, it is in fact an error not to mention `begin' explicitely.

All the best,


Am 22.03.2017 um 02:54 schrieb Shiro Kawai:
Probably the confusion is that the use of 'begin' here isn't apparent of
being which one of three definitions of 'begin' in R7RS.

1. (begin <expression-or-defintion> ...)  ; can appear as part of
<body>, outermost level of <program>, REPL, or inside (begin ...) of
this use
2. (begin <expression> ...) ; can appear in <expression>
3. (begin <command-or-definition> ...) ; as <library-declaration>

I think the intention that it is begin #1 is implied in the "in order to
facilitate writing ..." paragraph, but it's not explicit that this
<macro use> is treated as if it consists of <body> (or, we could augment
R7RS 4.2.3 to say that begin#1 can appear in <macro-use> used as
<transformer-spec>).  It's confusing because we get used to think begin
itself doesn't create a <body>.  For example, Takashi's example
(define-syntax foo (begin (define bar 0) ...)) isn't symmetric to
ordinal definitions, where (define foo (begin (define bar 0) ..)) isn't
allowed.  So it'll help to notify the reader that they are indeed different.

On Tue, Mar 21, 2017 at 4:12 AM, Marc Nieper-Wißkirchen
< <>> wrote:

    -------- Weitergeleitete Nachricht --------
    Betreff:    Re: Invalid test case.
    Datum:      Tue, 21 Mar 2017 13:42:47 +0100
    Von:        Marc Nieper-Wißkirchen <>
    Antwort an:
    An:         Takashi Kato <> <>

    Am 21.03.2017 um 08:52 schrieb Takashi Kato:

    Then I need a bit more clarification. If the above case is allowed by this
    SRFI, then I think it implies one of the following 2 thing:

    - define-syntax, let-syntax or letrec-syntax may take sequence of <definition>
      followed by <transformer spec>
      (define-syntax foo (begin (define bar 0) (syntax-rules () ((_) bar))))
    This is what the spec currently says:

    " Whenever a keyword is bound to a macro transformer, and the macro
    transformer is given by a transformer spec that is a macro use, the
    keyword is bound to the macro transformer given by the transformer
    spec that results from transcribing the macro use. It is an error if
    the macro use does not expand into a transformer spec (but see below).

    In order to facilitate writing sophisticated custom macro
    transformers, it is allowed that a transformer spec expands into a
    sequence of multiple definitions eventually followed by a
    transformer spec (whose expansion may make use of the introduced

    What shall I clarify here? Where do you see any ambiguity?


    - <macro use> inside of the <transformer spec> must specially be handled to
      detect any <definition>

    Either way, it's nice to be clarified by post finalization note.


    Takashi Kato

    On 20 March 2017 at 22:41,  <> <> wrote:

    thanks for asking this question.

    Am 08.03.2017 um 10:06 schrieb Takashi Kato:

    I believe the test case "Auxiliary definitions in custom macro
    transformers" is incorrect. The
    definition of the test is the following:

    (define-syntax my-macro-transformer
      (syntax-rules ()
         (begin (define foo 2)
            (syntax-rules ()
              ((_) foo))))))
    (letrec-syntax ((foo (my-macro-transformer)))

    However this would be expanded to like this:

    (letrec-syntax ((foo (begin (define foo 2)
                                (syntax-rules ()
                                  ((_) foo)))))
    The spec allows that "in order to facilitate writing sophisticated
    custom macro transformers" transformer specs expand into sequences of
    multiple definitions eventually followed by a transformer spec (which is
    the case in the example above). The scope of these definitions are in
    the scope of the bindings of the letrec-syntax binding construct.

    The "foo" inside "(define foo 2)" and the foo in the syntax-rules
    template are effectively being renamed due to hygiene. Thus, the whole
    construct expands into "2".

    Was my explanation helpful?



    To unsubscribe from this list please go to