There are lots of cool papers Dybvig has published related to Chez Scheme that are relevant for anyone hacking on compilers. Specifically, destination-driven code generation is really neat.
Dybvig was my compilers professor during my second semester of my senior year at Indiana University. He was a very good teacher with a well laid out class. Since I was a second semester senior, I screwed around and barely went to class and just barely scraped by. That was one of my bigger regrets in college was not taking advantage of that class.
I always recommend his talk "A macro writer's bill of rights" [0] to people. It ties into some of the papers he has written, and also shows how nice it is to have a source->source optimizer. You write some code, and can the look at it after most of the common transformations (inlining, DCE, loop unrolling, constant propagation).
I spent some time reading the r6ra discussions and was blown away by the thought that went into the whole thing. There are very few parts of the semantics of R6RS that are actually bothersome. The only thing I really don't like is promises and the dynamic environment.
"Why did you choose Chez Scheme over other Schemes to rebuild Racket?
The biggest weakness of the Racket BC (“before Chez”) implementation are its back-end compiler structure, its inefficient internal calling conventions (over-adapted to C), and its poor implementation of first-class continuations. Those are exactly the strengths of Chez Scheme. Furthermore, Racket’s evaluation model was always closely aligned with Chez Scheme, such as the emphasis on interactive evaluation and compilation.
It was clear up front that Chez Scheme lacked significant features that Racket needs, such as support for continuation marks and reachability-based memory accounting. However, the high quality of the Chez Scheme design and implementation, in contrast to old Racket’s implementation, made adapting Chez Scheme more appealing than retrofitting Racket’s old implementation further."
I have fond memories of Racket, my intro to CS course used it. I already knew how to program, but I was really only familiar with C and it stumped me, in a good way.
Sadly I have never used Racket since. The kind of stuff I'd use it for is well-covered by python.
> Made me think why they don't just build Racket entirely in its self!
I'm not sure either, but I remember it might be because Chez Scheme has a parallel garbage collector that they could reuse, and being Lisps they could easily maintain backwards compatibility.
I think that "stumping" characteristic is really important in intro-level CS courses. My university actually had two choices for CS100: JS or Racket, and as a TA I saw the Racket class as significantly more successful at setting students up for success.
Most students come in with some programming experience. A handful come in with a lot, the rest have none. The latter two groups fared about equivalently when compared with their counterparts in the other language intro. But the big group of students who had just enough knowledge to be dangerous benefited greatly from the Racket course, and my hypothesis on the subject is that the alienation from what they were used to 1) stopped them from checking out because they thought they knew it all already and 2) forced them to really evaluate their knowledge and separate the language specifics from fundamental truths.
This was the best feature of Indiana University’s Scheme-based curriculum - it leveled the playing field and caused us to start to think about programming not as engineering, but as a type of mathematics over data.
There still is a bit of a runtime system that you'd write in something like C - you'll see it in the "c" directory of the linked chez repository. Chez is reportedly very fast, it's much easier to use that than write your own from scratch.
I don't know the Racket situation (although I am using their chez fork), but I know that the Idris language chose to move from having their own C based runtime system to chez for the Idris2 rewrite. The reasons that I've seen were that it was much more performant than they could achieve on their own.
I suspect something similar is at play here. That the racket team wanted to concentrate on what makes racket special and leverage Chez for performance.
From what I have read, Chez is a quite performant implementation (benchmarks https://ecraven.github.io/r7rs-benchmarks/) and does a lot of things correctly (according to spec) and cleanly. Basing Racket on Chez takes advantage of the things Chez does well and probably saves a lot of time. I have too little knowledge about Racket's internals, to give a better and less general answer.
I think the commenter meant sending a specific function definition to the REPL, like in Common Lisp, Clojure, or F#'s REPLs, without re-evaluating the entire file, like how DrRacket does it. I think Racket has some functionality that allows it though, and I think the Racket Emacs mode supports it. I am not aware of how to do it with DrRacket.
In CL land, we have good support with Atom, Jupyter notebooks, Sublime, VSCode (new plugin, hard-ish to install), and to a lower extent Geany, Eclipse (basic support) and other terminal REPLs. https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Not to forget Lem, an emacs-like CL editor that works out of the box for CL, but also for other languages (Python, Rust…).
This README.md right here is the quintessential example of the exciting marketing and mindshare of new products and ideas that I have come to expect from my years of experience with working with the from the products and services associated with, and produced and maintained by cisco, and cisco partners, and I'm terribly happy for them and all of their successes.
My favorite is the slides on the development of Chez Scheme: http://icfp06.cs.uchicago.edu/dybvig-talk.pdf.
A few other good ones:
* Destination Driven Code Generation: https://legacy.cs.indiana.edu/~dyb/pubs/ddcg.pdf
* The Development of Chez Scheme: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72...
Here's a pretty full list: https://www.researchgate.net/scientific-contributions/R-Kent....