> From: Taylor R Campbell <campb...@mumble.net> > Date: Mon, 3 Jun 2013 20:49:43 +0000 > > [...] > > 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.
We had a new star-parser operator. The host refused to compile it, as it should have. There was no "absurd bug". I worked around the problem by commenting out the new syntax. Luckily the missing bits were not needed by the cold-load or compiler, so I had a "trained" host that could compile the unaltered system. > [...] Scheme48 has been doing this right for decades. I am unhappy with separate compilation too. :-) Seriously: what does Scheme48 do "right", and does it have anything to do with our need for a release this time *or* last? > I didn't say that the absence of a portable fasdumper is `THE source > of the problem'; only your careful excerpting suggests that. Sorry, you said "*begin* to fix the source of the problem". I did acknowledge that a portable fasdump/fasload might allow us to delay a release. I *like* the idea of a fasdump/fasload written in Scheme. It might be fun to extend it into a customizable pickler of the sort for which Joe was looking. I just don't grok it as part of a new build process that is all "portickle" and less "fragile" and does the Right Thing with "a target system's macros". _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
