Date: Wed, 16 Oct 2013 10:24:33 -0700 From: Matt Birkholz <p...@birchwood-abbey.net>
> From: Taylor R Campbell <campb...@mumble.net> > Date: Tue, 15 Oct 2013 20:44:36 +0000 > > The toolchain necessary to build the system (macro expander, sf, cref, > compiler) should be able to run in a wide variety of host systems, > including many versions of Scheme [...] A cool branch. It would be nice to more easily reason about who expanded what, but it is not so difficult in 99% of the cases. It would be weird (and wonderful) to boot on another Schemeish, but at what cost? The entire compiler must be written in R3RS? No #!optional arguments or *parser or nutt'n? Not R3RS, but nothing super-fancy like *PARSER. Relying on records, hash tables, bit strings, for example, is fine -- these are all available in some form or another in other Schemes and we could write compatibility shims for them without too much trouble. > [...] The build should furthermore have clear semantics so that we > can get reproducible results in all those different environments. The semantics that RELEASE is our host and NEW-RELEASE our target is clear. That runtime/ is syntaxed with RELEASE's *parser (unless it makes other arrangements) I thought was plain enough. Tough cookies for those who want to use a new *parser operator before it appears in RELEASE, but they can make their arrangements. There's no reason it shouldn't work to implement and use a new *PARSER operator without a release cycle. The language used in the source code of runtime/ &c. should be described by the toolchain included in src, and that toolchain should be a relatively vanilla Scheme program. For that matter, there's no intrinsic reason why the toolchain implementing this language should have to be written in Scheme -- it could just as well be SML or C++. It happens to be written in Scheme because we like writing Scheme and it puts pressure on Scheme to be fit for writing this kind of application. > It may be that using my portable fasdumper with the cross-compiler > will suffice to get this working, because it is guaranteed not to dump > SEQUENCE_3 objects even in a host that uses them in memory. The cross (I can't say portickle) fasdumper would be interesting if it dumped wildly different heap formats: low tags, constants at the start of a compiled code block, supposedly portickle stuff, etc. That is exactly the idea of the fasdumper I wrote. > However, I am inclined to say that maybe we ought to cut 9.2 from > commit 96ffae5, from before I made a hash of the top-level makefile; > cherry-pick whatever important changes we've made since then; and > then fix up the build (and perhaps get cross-compilation working as > a first-class citizen!) in HEAD for 9.3. What do you think? Your "hash" finally got the sequence-3's out of the native distribution's .bcis. It turned my 15 minute builds into 45 minute builds, but that's what it takes to compile a cross-compiler, cross-compile a boot-compiler, and compile everything natively. Please keep the hash. I was afraid 9.2 might appear with crap .bcis. If you just revert aab92f7 you can release a VERY nice 9.2 forthwith. OK, we can do this for now -- but please leave a scary comment marking the inclusion of runtime/ in the toolchain as a provisional kludge. The only parts of the runtime that the toolchain needs to rely on are the reader, the scode abstraction, and the macro expander. There's no reason to do a cold load to make a compiler application! _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
