Re: [MIT-Scheme-devel] A tale of four builds.

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Sat, 5 Oct 2013 22:51:11 +0000
> 
> [...]
>    > We ought to do macro phasing the way Racket does.  A program that
>    > depends on side effects from the transformer procedures of the macros
>    > it uses is a broken program.
> 
>    You're talking gobbly-gook now.  What is "macro phasing"?  And
>    "broken" is "incompatible with separate compilation" right 'round again?
> 
> See Matthew Flatt's paper `Composable and Compilable Macros'.
> `Broken' means it is fragile, if it works at all, and unnecessarily
> painful to reason about.

I found The Racket Guide chapter 16, presumably the same thing.  If I
read enough of it, my FFI syntactic transformers, for syntax like

        (C-include "gtk")
        ...
        (C-sizeof "GdkEvent")

could share info via a *c-includes* binding in the environment of the
FFI module:

        (define *c-includes*)

        (define-syntax c-include
          (syntax-rules (*c-includes*)
            ((_ args ...)
             (set! *c-includes* (include-cdecls args ...)))))

        (define-syntax c-sizeof
          (syntax-rules (*c-includes*)
            ((_ c-type)
             (c-includes/sizeof *c-includes* c-type))))

AND that binding would be duplicated per user module, so saying

        (C-include "gdbm")

in another module (file?) would not clobber the gtk c-includes.

A serendipitous win!?  To get the same effect I had to use things like
syntactic-environment->environment and environment-define.

And that is why my FFI must be separately compilable?  You would like
to fasload it multiple times, into various environments-for-syntax --
one per (require-for-syntax 'FFI) phase?