Re: [MIT-Scheme-devel] interpreted runtime broken

[Taylor R Campbell]

   Date: Tue, 11 Jun 2013 18:58:27 -0700
   From: Matt Birkholz <address@hidden>

   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.