> From: Taylor R Campbell <campb...@mumble.net>
> Date: Fri, 4 Oct 2013 19:08:25 +0000
>
> Date: Fri, 4 Oct 2013 11:30:16 -0700
> From: Matt Birkholz <m...@birchwood-abbey.net>
>
> [...] 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.)
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
