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

[Taylor R Campbell]

   Date: Mon, 3 Jun 2013 12:50:59 -0700
   From: Matt Birkholz <address@hidden>

   > From: Taylor R Campbell <address@hidden>
   > Date: Sun, 2 Jun 2013 04:43:23 +0000
   > 
   > Another approach would be to write a portable fasdump so that we can
   > begin to fix the source of the problem rather than keep working around
   > it release by release.

   We recently (4 years ago) had a problem with a new star-parser
   operator that was used in the runtime system before it was released.

It is absurd that we ever had such a bug.  There is no reason in
principle why the host compiler's star-parser should influence the
target system's star-parser.  It is essentially an accident that the
host compiler and target system happen to be derived from a lot of the
same code and environment structures and package names.  Scheme48 has
been doing this right for decades.

(And the only reason these bugs don't happen all the time, aside from
the fact that we're kinda careful, is that the project is moving at a
snail's pace.  I have often wanted to add macros to the system and
start using them (e.g., ASSERT and BEGIN0) but decided against it
because it would break stuff and then forgot about it.)

   A fasdump/fasload that accommodates added and deleted primitives,
   s-code types, whatnot, will surely help, but its absence is not "THE
   source of the problem".

I didn't say that the absence of a portable fasdumper is `THE source
of the problem'; only your careful excerpting suggests that.  The
source of the problem is that the semantics of the target system
depends too heavily on the way the host compiler was put together.

We ought to be able to type

./configure --build=x86_64--linux --host=arm--netbsdelf --boot-scheme=racket
make

out of the box on some amd64 machine running GNU/Linux in order to
build a working MIT Scheme for NetBSD on ARM.  That should build a
bootstrap toolchain (macro expander, sf, liar, &c. -- including a
portable fasdumper) that can run in Racket and then use the bootstrap
toolchain to build MIT Scheme (using the new MIT Scheme's `runtime'
macros and star-parser).

Making it all run in Racket or Scheme48 or whatever is a big task, of
course, but restructuring the build along these lines -- and making
every build be a cross-build -- shouldn't take too much work.  The
liarc build process roughly does this already, but it's very fragile
and does the wrong thing with the target system's macros.  I don't
know what state the svm build process is in but I suspect it's
similar.  (And both of them badly need to be parallelized.)