Re: [MIT-Scheme-devel] [commit 13b5bca] Fix new build to cross from 9.1.1.

[Taylor R Campbell]

   Date: Wed, 16 Oct 2013 10:24:33 -0700
   From: Matt Birkholz <address@hidden>

   > From: Taylor R Campbell <address@hidden>
   > Date: Tue, 15 Oct 2013 20:44:36 +0000
   > 
   > The toolchain necessary to build the system (macro expander, sf, cref,
   > compiler) should be able to run in a wide variety of host systems,
   > including many versions of Scheme [...]

   A cool branch.  It would be nice to more easily reason about who
   expanded what, but it is not so difficult in 99% of the cases.  It
   would be weird (and wonderful) to boot on another Schemeish, but at
   what cost?  The entire compiler must be written in R3RS?  No
   #!optional arguments or *parser or nutt'n?

Not R3RS, but nothing super-fancy like *PARSER.  Relying on records,
hash tables, bit strings, for example, is fine -- these are all
available in some form or another in other Schemes and we could write
compatibility shims for them without too much trouble.

   > [...]  The build should furthermore have clear semantics so that we
   > can get reproducible results in all those different environments.

   The semantics that RELEASE is our host and NEW-RELEASE our target is
   clear.  That runtime/ is syntaxed with RELEASE's *parser (unless it
   makes other arrangements) I thought was plain enough.  Tough cookies
   for those who want to use a new *parser operator before it appears in
   RELEASE, but they can make their arrangements.

There's no reason it shouldn't work to implement and use a new *PARSER
operator without a release cycle.  The language used in the source
code of runtime/ &c. should be described by the toolchain included in
src, and that toolchain should be a relatively vanilla Scheme program.

For that matter, there's no intrinsic reason why the toolchain
implementing this language should have to be written in Scheme -- it
could just as well be SML or C++.  It happens to be written in Scheme
because we like writing Scheme and it puts pressure on Scheme to be
fit for writing this kind of application.

   > It may be that using my portable fasdumper with the cross-compiler
   > will suffice to get this working, because it is guaranteed not to dump
   > SEQUENCE_3 objects even in a host that uses them in memory.

   The cross (I can't say portickle) fasdumper would be interesting if it
   dumped wildly different heap formats: low tags, constants at the start
   of a compiled code block, supposedly portickle stuff, etc.

That is exactly the idea of the fasdumper I wrote.

   > However, I am inclined to say that maybe we ought to cut 9.2 from
   > commit 96ffae5, from before I made a hash of the top-level makefile;
   > cherry-pick whatever important changes we've made since then; and
   > then fix up the build (and perhaps get cross-compilation working as
   > a first-class citizen!) in HEAD for 9.3.  What do you think?

   Your "hash" finally got the sequence-3's out of the native
   distribution's .bcis.  It turned my 15 minute builds into 45 minute
   builds, but that's what it takes to compile a cross-compiler,
   cross-compile a boot-compiler, and compile everything natively.

   Please keep the hash.  I was afraid 9.2 might appear with crap .bcis.
   If you just revert aab92f7 you can release a VERY nice 9.2 forthwith.

OK, we can do this for now -- but please leave a scary comment marking
the inclusion of runtime/ in the toolchain as a provisional kludge.
The only parts of the runtime that the toolchain needs to rely on are
the reader, the scode abstraction, and the macro expander.  There's no
reason to do a cold load to make a compiler application!