On Tue, Feb 5, 2019 at 8:01 AM 'Paulo Matos' via Racket Users < racket-users@googlegroups.com> wrote:
> > Matthew mentions the move to Chez will help maintainability and I am > sure he's right because he has been working with Racket for a long time > but my experience comes from looking at backend files. When you look at > them you end up being forced to look elsewhere, specifically the > cpnanopass.ss file [3]. Well, this file is the stuff of nightmares... > It's over 16000 (sixteen thousand!!!) lines of dense scheme code, whose > comments are not necessarily Chez-Beginner friendly (maybe Alexis wants > to rewrite it? [4]). Interestingly, having been in the classroom* around '98-2000 when some of these nanopass ideas were being developed (or, really, when I think they were really hitting stride in the classroom---I'm sure they were being developed well before), I find [3] to be exceedingly readable. Well, not "exceedingly": I think it would benefit from some breaking apart into separate modules. However, it uses the nanopass framework for specifying a series of well-defined languages, each of which can be checked/tested between pipeline stages. Some of the more gnarly code is in the register allocation... which is unsurprising. I do like that I can flip to the end, see the driver for all the passes, and each pass is a separate, match-like specification of a transformation from one language (datatype) to another. Ignoring the fact that there's support code in the file, 16KLOC suggests around 500 lines per pass (at roughly 30 passes, it looks like); 500 lines seems to me to be a manageable unit of code for a single pass of a compiler that should, if written true-to-form, does just one thing per pass. (This is, I suspect, a classic "YMMV" kind of comment.) I can't say that I'm about to step in and join the compiler team (save us all from the thought!). I do think that it's nice to see the idea a nanopass compiler 1) in production and 2) having the maturity to become part of the production back-end of Racket. If [1] is where some/much of Racket's backend currently lives, I am ecstatic that the backend will be more Scheme (Chez? Racket?) than C/C++. Cheers, Matt [1] https://github.com/racket/racket/blob/master/racket/src/racket/src/compile.c * As an aside, one of the few times I remember Kent Dybvig making a "joke" in class was when he introduced the pass "remove complex operands." It was called "remove-complex-opera*." At Indiana, where Opera is a Thing, I think it was particularly funny as an inside joke of sorts. He devolved for a moment into what I can only describe as giggles---but, it was subtle just the same. It brings me a certain amount of joy to see "np-remove-complex-opera*" in [3]. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
