> From: Taylor R Campbell <[email protected]>
> 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?
_______________________________________________
MIT-Scheme-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
