Hello, >> I think it can be done effectively, but I'm not quite sure what you >> mean by "dynamic module composition." Do you mean that this might >> prevent you from making modules that use arbitrary other modules? Or >> that it might not work if you loaded modules at runtime from the REPL? > > I was referring to the ability to connect code snippets at run-time (by > means of use-modules, C-x C-e in Geiser, etc.) and have an evolving, > live system. > > Having types associated with values makes this easier. It may become > harder once the compiler has built assumptions into the generated code > about the types each procedure expects.
I agree. I think that for statically generating code, where we want to do as much optimization as possible, we need something called a "program definition", which is a list containing all entry points to the program. Then you could assume that all control flow starts at those entry points. I also think of this as something that the compiler will eventually use as well - for instance, if you want to generate a library, you would provide a list of the functions that would be entry points. For a standard unix program, there would be just one entry point. (The big advantage for the compiler is that the list could also contain ABI information, which is useful for people who make libraries that need to be ABI-compatible. I can argue for this more if you like.) It's not clear to me how well analysis will work in dynamically-edited code, but I would like to do as much as possible there. I think the key to that will be a combination of caching generated code, and invalidating the caches when necessary, and generating specialized versions of functions that are called by other compiled code but are separate from the generic entry points to those functions. > About Kanren, there’s “The Reasoned Schemer”. I've ordered that book; it should be here soon. My plan is to read things for the next couple weeks, to make sure I really understand how an analyzer needs to work, come up with a plan for Guile's, and then email the list again to discuss it. Thanks, Noah