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. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/5a8c4714.1c69fb81.4222f.a242SMTPIN_ADDED_MISSING%40gmr-mx.google.com. For more options, visit https://groups.google.com/d/optout.
