Date: Sat, 29 Aug 2009 18:31:05 -0700 From: [email protected] (Matt Birkholz)
I also read Taylor's bug report #15020, which observes that variables syntactically closed in any environment but () cannot be fasdumped. The syntactic closures refer to environments, which refer to... basically, everything. I infer that if I succeeded in closing call-alien in (ffi macros), I would not be able to fasdump any expansions. The main problem here is that the compiler/linker and the macro system fail to communicate, and that the macro system uses the wrong data structure, interpreter environments. I would like to fix my problem (and 90% of Taylor's?) by expanding such a variable reference into a peculiar free variable reference. My C-call syntax would expand into a reference to call-alien closed in (runtime ffi), and the file syntaxer would expand this into a free reference to a binding named |call-alien(runtime ffi)| (uncapturable by convention?). Fasload then links the "free" variable binding to the appropriate source binding at load time. Simple? I can't take credit for the idea. I heard basically the same proposal many years ago (from Jinx?). I could hardly appreciate the finesse in the solution (nor even the problem!) at the time. Now... I *need* it! If we're happy with universal names for modules, that works. But what happens when someone else writes a different program called a `compiler', or a program to transmit distress signals in Morse code, and wants to load it into an image that already has LIAR and the Scheme Object System loaded? Without a naming authority -- which could be so simple as (quite literally speaking) a URI authority -- universal names are not practical. Universal names for modules and bindings are not necessary, however, to make a system work. In Scheme48, modules and environments are only necessarily part of the compiler and linker; compiled code need know only about value cells, which the compiler and linker set up. (The macro system, incidentally, is part of the compiler, not the run-time system. In MIT Scheme the situation is complicated by the existence of a separate interpreter which also uses the macro expander.) Systems such as the interactive command processor (the REPL) are built `reified': the linker links them and reifies their modules and environments so that they can refer to their own modules and environments. (The linker thus acts like the U combinator.) The project homepage says that we plan to implement a module system(!). I assume the above issues are in the bailiwick of that effort. Is there a sketch of the desired "module system"? Chris and I have very different ideas of what a module system should look like. For a discussion of some of the issues surrounding module systems for Scheme, see Flatt, `Composable and Compilable Macros: You Want It When?', 2002. CREF is not really an appropriate starting point -- aside from its failure to record actual dependencies, rather than just environment linkage, in order for any of this to work well, the compiler/linker and macro system have to communicate. _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
