[plt-scheme] Reexpansion of modules

Matthias Felleisen is alleged to have written:
> 2. Yes, we could expand PLT Scheme to PLT Scheme [core] first but
> even in this core language you have so many library calls and
> extensions, resolution of semantic issues, etc, that NOW WATCH
>
>  -- compiling the rest in Larceny is either impossible or
>  -- it doesn't produce code that is faster than PLT Scheme and
> faithful to its semantics.
>     [Evaluation order is just one "switch" (ever wondered about the
> love and attachment of compiler hacks to switches?)
>     that slows down object code in Larceny a lot. Why? I don't know.]

When you take a language whose order of evaluation is
unspecified, and arbitrarily declare that a compiler
shall use only one particular order of evaluation,
compliance with that diktat will entail some loss of
performance.  One would hope that the diktators know
this and understand why.

As for the love and attachment of compiler hacks to
switches: orthogonal switches are more versatile than
a menu of selectable languages, especially for research.

As for why (something resembling but not quite)
left-to-right evaluation is a compiler switch in
Larceny: it is because a fairly large number of people
have interpreted the left-to-right evaluation order of
MzScheme as permission to write non-portable code that
relies upon that evaluation order.  When that code is
valuable enough to be used in other systems, as it
sometimes is, its reliance on left-to-right evaluation
should really be fixed, but there is an economic argument
for hacking the compiler to work around those bugs in
the short term.

As for why left-to-right evaluation is somewhat slower
in Larceny: any fixed order of evaluation is going to
be slower than letting the compiler choose an efficient
order of evaluation.  In the short term, there is an
additional performance hit from disabiling *all*
optimizations that might change the order of evaluation
(not just those whose purpose is to choose a good order
of evaluation).  In the long term, some performance can
be won back by rewriting all of those optimizations so
they try to choose a good order of evaluation that is
also indistinguishable from the diktat, but that is
considerably more difficult than merely choosing a good
order of evaluation, and (with the current semantics of
Scheme) is necessary only when compiling buggy code, so
it tends not to be a high priority for compiler writers.

Will