Support srfi-147

[shirok]

Now we accept general expressions as transformer-spec, as far as it yields a macro transformer, so we've already come half way to support srfi-147.

https://srfi.schemers.org/srfi-147/srfi-147.html

It fails when <transformer spec> is a <macro use> that expands into (being <defintiion> ... <transformer spec>). (It words if we directly have (begin ...) form).

[shirok]

Allowing arbitrary expressions, and especially the (begin <definition> ... <transformer-spec>) form, pose a difficult issue. It can create a lexical environment at runtime, that only to be inserted by the macro.

One of such case is exhibited by a test of srfi-147:

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

        (test-equal 42 (* 21 (letrec-syntax ((foo (my-macro-transformer)))
                               (foo)))))

(my-macro-transformer) expands into a (begin ...) form, which evaluates at compile-time to become a macro transformer. When that is expanded in the test-equal form, it inserts a variable reference to foo, which is the identifier introduced in the macro expansion. But currently, transformer-spec is evaluated solely in the compile-time environment, the binding of foo introduced in my-macro-transformer does not exist in the runtime environment.

The definition in the new (begin ..) form may close any runtime environment surrounding it, so we need to emit the binding form into the macro output somehow, and let the runtime evaluation takes care of it.