Date: Tue, 11 Jun 2013 18:58:27 -0700 From: Matt Birkholz <m...@birkholz.chandler.az.us>
Seriously: what does Scheme48 do "right", and does it have anything to do with our need for a release this time *or* last? The Scheme48 compiler and static linker (`SF/LIAR and DUMP-BAND') are more or less portable Scheme and clearly separated from the run-time library and the rest of the system. You can load a bootstrap compiler and linker into ~any version of Scheme48, or any of various other Schemes (although some of this has bitrotted because it wasn't exercised for a while), in order to build the run-time library, compiler, and linker to make a Scheme48 image (`all.com'). Notably, the language used in the run-time library, user interface (REPL and stuff), &c., is independent of the host compiler's concept of macros. If the run-time library depended on a hairy *PARSER macro, the bootstrap compiler (not the host compiler) would load in the source code for the current version of the *PARSER macro -- not whatever the host compiler had baked into it when it was built a decade ago. Whether or not we make it easy to bootstrap MIT Scheme from other Schemes, we ought to make it easy to load a bootstrap toolchain -- at least the macro expander and a portable fasdump, if not SF and LIAR too -- into ~any version of MIT Scheme to build the rest of the system. I *like* the idea of a fasdump/fasload written in Scheme. It might be fun to extend it into a customizable pickler of the sort for which Joe was looking. For that purpose, I think effort would be better expended on support for ASN.1 or protocol buffers or whatnot. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
