I think it's time to swap in the Racket-implemented macro expander, so
I propose to merge the changes in the `racket7` repo to the main
`racket` repo (but as one commit, leaving the history to `racket7`).
If we agree that this is a good idea, then I recommend making the
switch next week.
It's difficult to swap in a big change like this early enough in a
normal release cycle, and the remaining 4-6 weeks for the current cycle
would not be enough time. So, I also suggest skipping the next release
cycle and starting the one after that early. Starting early will allow
for a kind of "beta" test period and still put the release well before
the start of the fall semester.
The benefit of switching is that the new expander implementation tends
to be more reliable than the current one (which keeps having issues
related to the bridge between modules and namespace). The new
implementation will also be easier to improve with new features or
better expansion algorithms; it's the implementation with a long-term
future.
The drawback of switching is performance --- certainly in the short
run, and probably for a long time. The performance of `racket7` has
only improved 10-25% in the last few weeks, so the numbers and plots in
the Racket-on-Chez report are still close to right:
http://blog.racket-lang.org/2018/01/racket-on-chez-status.html
The most relevant things to look at there are the startup times in
"Performance: Startup" and the first two plots in "Performance:
Distribution Build". Roughly, expansion takes x2 as long.
As programs get bigger, the startup difference tends to be smaller. For
example, DrRacket startup time is slower by only about 10%. Also, the
difference in expansion/compilation time can be smaller if a module's
expansion is mostly in macros instead of the expander. So, x2 is more
of an upper bound than a rule.
At this point, I'm ready to take the x2 performance hit for expansion
and compilation to get away from the old expander implementation.
[Note: There was previously a bigger performance obstacle with
platforms where the Racket JIT is not supported, since interpreting
the Racket-implemented expander means a x10-x20 slowdown. We've solved
that problem by building a little Racket-to-C compiler. The generated
C code, comiled as part of the runtime system, performs only slightly
worse than JIT-generated code. So, the change in expander performance
will be mostly independent of whether the JIT is available.]
I've run a package build with `racket7`, and there are a handful of
failures that look related to the expander. I expect to fix those
before a switch, if we decide to make the move. There will still be
bugs after the transition, but I expect that we'll reach a stable and
compatible state fairly quickly.