I love CREF. It is a great help. Its configuration files are second only to the TAGSs in my list of favorite references. However... :-)
I tried to hide the procedure call-alien behind my C-call syntax, exporting just the latter. I was hoping my reference to call-alien would be closed in (ffi macros), but I get a free reference. For now I export call-alien to () and ignore the risk of capture. SOS does better. Its macros use a procedure named "absolute" that replaces variables that should be closed in (sos macros) with e.g. (access add-method system-global-environment). An export, e.g. from (sos method) to (), makes that work. 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. 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! 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"? _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
