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

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Fri, 4 Oct 2013 19:08:25 +0000
> 
>    Date: Fri, 4 Oct 2013 11:30:16 -0700
>    From: Matt Birkholz <address@hidden>
> 
>    [...] Are you thinking: VPATH support in compile-file?
> 
> Maybe something like that.  [...]  What we should *not* do is add
> any kind of search path [...]

OK.  I don't remember clearly the implications of "doing VPATH".
Using a directory search path is not the feature I had in mind.

> (We could alternatively just add a parameter for the
> object directory.)

Can the argument be #F?  Meaning "compile AND evaluate (in the same
package)"?  Then I don't have to arrange a place for cross-compiler
objects I will never fasload.

>    [...] 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.

How mysterious! :-)

> 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.

You're talking gobbly-gook now.  What is "macro phasing"?  And
"broken" is "incompatible with separate compilation" right 'round again?

>    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?

Nope.  "Out" and "in" are just names.

We currently load runtime.sf on a host and let the host star-parser
expand any *parser syntax.  We would rather the new star-parser do the
new *parser syntax (and not just!).  We need new definitions for lots
of things when compiling a cross-compiler -- ANY compiler now.

Star-parser/ AFTER runtime/:
        (load "runtime/runtime.sf")
        (load "runtime/runtime.cbf")
        (load "runtime/make")

        (load "star-parser/compile")
        (load "star-parser/load")

Star-parser/ IN runtime/:
        (load "runtime/inner.sf")
        (load "runtime/inner.cbf")
        (load "runtime/make-inner")

        (load "star-parser/compile")
        (load "star-parser/load")

        (load "runtime/outer.sf")       ; latest *parser macros available!
        (load "runtime/outer.cbf")
        (load "runtime/make-outer")
        ...

I would not make it as cumbersome as that.  I would just load
(runtime) packages as they are mentioned in runtime.pkg, and add the
(runtime *parser) package before (runtime simple-file-ops), the first
user of *parser syntax.

> 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.

OK, but it can actually depend on anything available in (cross
runtime).

On Planet KISS, runtime/ is "compiled" by loading it into a (cross
runtime) package initialized with little more than essential R4RS
bindings.  If star-parser needs nothing more, it can be loaded first,
and its transformer used to expand *parser syntax throughout the
system.  (Please take me to Planet KISS.)