Date: Fri, 4 Oct 2013 11:30:16 -0700 From: Matt Birkholz <m...@birchwood-abbey.net>
> From: Taylor R Campbell <campb...@mumble.net> > Date: Fri, 4 Oct 2013 13:41:41 +0000 > > [...] > One thing we ought to be able to do is use different source and object > trees. That way, we could have one object tree for a (cross-compiler) > toolchain, and one object tree for the target, and a single makefile > to regenerate everything. [...] Are you thinking: VPATH support in compile-file? Maybe something like that. I'm not sure how it should be integrated into the system. What we should *not* do is add any kind of search path -- that is, a list of pathnames where things might be found. If we do add a parameter to COMPILE-FILE &c. for the source directory, it should be *the* source directory, and not a list of possible source directories. (We could alternatively just add a parameter for the object directory.) > I would like to be able to run a program without a macro expander, > compiler, &c., in the address space, [...] This is the same address space that comes in 64bit quantities now? How about shaking such things out? You will want to do that aggressively anyway if you are trying to fit into tiny hardware. Virtual address space size is not the only concern. > Fixing the system so that loading without compiling and loading > after compiling have the same semantics is worthwhile; eliminating > support for a distinct compilation step altogether is not. You will have to limit macro expanders somehow. Syntaxing in a fresh environment and discarding that environment afterward is going to make the semantics match? You'll just ignore side-effects beyond the discarded environment? ? We ought to do macro phasing the way Racket does. A program that depends on side effects from the transformer procedures of the macros it uses is a broken program. > We ought to be moving stuff *out* of runtime/, not into it. There's > already too much crap there. Only stuff that is an important part of > a running Scheme program should go in there, really. Yes, an "inner" runtime. Star-parser needs an inner runtime loaded/compiled before it can be loaded/compiled. The users of the *parser syntax also need an "inner" runtime, but it is not the same one. I don't understand. Can you be more specific? The star-parser macro transformer is a normal Scheme program that shouldn't depend on any interesting new features of the runtime, so it should be able to run in the host Scheme no matter what we've done to the new runtime we're trying to build. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
