> From: Taylor R Campbell <[email protected]> > Date: Sat, 29 Aug 2009 23:01:10 -0400 > > [...] > 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 am getting no traction from that. Are you re-stating my problem to make the solution easier to visualize? There IS a communication problem: fasload needs more information from the macro system in order to re-establish the proper links... ? But I do not see how using separate data structures for variables and keywords will help. The interpreter environments model the lexical contours of the code, which are relevant to both macro expansion and variable reference. ? > [...] Without a naming authority [...] universal names are not > practical. I would stick with the naming authority we have now. > [...] In MIT Scheme the situation is complicated by the existence > of a separate interpreter which also uses the macro expander. A "separate" interpreter that "also uses" is a mighty fine hair. Again, I am not sure where you are going with this distinction. > [...] 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. You must have a lot of big problems that you want the module system to solve. What are these "actual" dependencies? Build dependencies? I don't expect CREF to model build dependencies because I know they include all the little .cdecl files my C-include macro loaded. My build process has to ensure that all files mentioning (C-sizeof "GdkColor") get re-compiled when the C-sizeof macro definition changes OR the C declaration in gdkcolor.cdecl changes. I don't want to solve any BIG problems. I just want to be able to fasload a reference to a variable in a named environment. I guess my work will NOT relate to any serious module system effort. ;-) _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
