[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] Module system?
From: |
Matt Birkholz |
Subject: |
Re: [MIT-Scheme-devel] Module system? |
Date: |
Sun, 30 Aug 2009 09:34:08 -0700 |
> From: Taylor R Campbell <address@hidden>
> 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. ;-)