Re: [MIT-Scheme-devel] interpreted runtime broken

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> 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".