Date: Sat, 5 Oct 2013 14:49:37 -0700
From: Matt Birkholz <p...@birchwood-abbey.net>
> From: Taylor R Campbell <campb...@mumble.net>
> Date: Fri, 4 Oct 2013 19:08:25 +0000
>
> (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.
No, I am trying to separate the program that analyzes another
program's source (the compiler) from the mechanism we have for
combining and running programs (the evaluator). The global package
database makes this hard enough. Loading a fresh compiler into the
system that is compiling the fresh compiler at the same time as this
is happening is not something that our code is set up to do sanely at
the moment.
> 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?
See Matthew Flatt's paper `Composable and Compilable Macros'.
`Broken' means it is fragile, if it works at all, and unnecessarily
painful to reason about.
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")
...
This is basically what I had in mind, except I meant to move the
`outer' stuff outside runtime/ altogether. However, for now, it will
do well enough to load *parser into the bootstrap toolchain.
On Planet KISS, runtime/ is "compiled" by loading it into a (cross
runtime) package initialized with little more than essential R4RS
bindings.
It should not be necessary to use a (cross runtime) package. We ought
to be able to write a program that operates on descriptions of
packages independent of the way that program was organized itself in
MIT Scheme.
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
