Re: [racket-users] Some concern about ChezScheme...

['Paulo Matos' via Racket Users]

On 06/02/2019 13:42, Matt Jadud wrote:
> On Tue, Feb 5, 2019 at 8:01 AM 'Paulo Matos' via Racket Users
> <racket-users@googlegroups.com <mailto: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. 
> 

I was quite surprised to read these nanopass ideas have been around for
so long. I might have heard of them about half a decade ago at the most.
I actually thought they were pretty recent... always learning...

OK, after reading your comment and skimming through the code it might be
that my problem is not being totally aware of the details of nanopass
compilation and therefore looking to the code and instead of being able
to abstract away portions of the code for different functions, just
seeing a huge blob of incomprehensible scheme with absolutely no comments.

> 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 guess a long comment describing some of this in the beginning of the
file would certainly be useful. In any case, as someone who dealt with a
lot of code and most of it development tools related I have never seen
anything like this. It would certainly be a lot clearer if each of the
passes had their own file. For example, in GCC all passes have their own
file and they are amazingly well commented. So if you open a file like
the register renaming pass
(https://github.com/gcc-mirror/gcc/blob/master/gcc/regrename.c) although
it is close to 2000 lines of C, it's pretty readable (assuming you know
how GCC IR works, of course). Also, you know this code is doing a
specific job, instead of doing 'all jobs', as in the case of the
cpnanopass file. But given Matthew's other message, I don't want this to
come across as me whining about the state of Chez but instead a call for
action to improve the situation. :)

> 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
> 

Scheme code is usually denser than C, therefore I am certainly less
scared by 2200 lines of C than I am by 16000 lines of scheme.

> * 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
> <mailto:racket-users+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

-- 
Paulo Matos

-- 
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.