Date: Mon, 3 Jun 2013 12:50:59 -0700 From: Matt Birkholz <m...@birkholz.chandler.az.us>
> From: Taylor R Campbell <campb...@mumble.net> > Date: Sun, 2 Jun 2013 04:43:23 +0000 > > Another approach would be to write a portable fasdump so that we can > begin to fix the source of the problem rather than keep working around > it release by release. We recently (4 years ago) had a problem with a new star-parser operator that was used in the runtime system before it was released. It is absurd that we ever had such a bug. There is no reason in principle why the host compiler's star-parser should influence the target system's star-parser. It is essentially an accident that the host compiler and target system happen to be derived from a lot of the same code and environment structures and package names. Scheme48 has been doing this right for decades. (And the only reason these bugs don't happen all the time, aside from the fact that we're kinda careful, is that the project is moving at a snail's pace. I have often wanted to add macros to the system and start using them (e.g., ASSERT and BEGIN0) but decided against it because it would break stuff and then forgot about it.) A fasdump/fasload that accommodates added and deleted primitives, s-code types, whatnot, will surely help, but its absence is not "THE source of the problem". I didn't say that the absence of a portable fasdumper is `THE source of the problem'; only your careful excerpting suggests that. The source of the problem is that the semantics of the target system depends too heavily on the way the host compiler was put together. We ought to be able to type ./configure --build=x86_64--linux --host=arm--netbsdelf --boot-scheme=racket make out of the box on some amd64 machine running GNU/Linux in order to build a working MIT Scheme for NetBSD on ARM. That should build a bootstrap toolchain (macro expander, sf, liar, &c. -- including a portable fasdumper) that can run in Racket and then use the bootstrap toolchain to build MIT Scheme (using the new MIT Scheme's `runtime' macros and star-parser). Making it all run in Racket or Scheme48 or whatever is a big task, of course, but restructuring the build along these lines -- and making every build be a cross-build -- shouldn't take too much work. The liarc build process roughly does this already, but it's very fragile and does the wrong thing with the target system's macros. I don't know what state the svm build process is in but I suspect it's similar. (And both of them badly need to be parallelized.) _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
