Re: [MIT-Scheme-devel] A tale of four builds.

[Taylor R Campbell]

   Date: Fri, 4 Oct 2013 11:30:16 -0700
   From: Matt Birkholz <address@hidden>

   > From: Taylor R Campbell <address@hidden>
   > 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.