Chez Scheme(github.com)
github.com
Chez Scheme
https://github.com/cisco/ChezScheme
5 comments
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.
[0] https://m.youtube.com/watch?v=LIEX3tUliHw
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.
[0] https://m.youtube.com/watch?v=LIEX3tUliHw
If you want to see how destination driven code generation (DDCG) works concretely, check out this old presentation by a V8 developer.
It shows concretely how DDCG compares to common optimizations like peephole and top-of-stack caching.
And shows concrete examples of compiling various forms (expressions, assignment, control flow, etc) with DDCG.
The only reason it's on my personal Github is because the original is so hard to find.
https://github.com/eatonphil/one-pass-code-generation-in-v8
It shows concretely how DDCG compares to common optimizations like peephole and top-of-stack caching.
And shows concrete examples of compiling various forms (expressions, assignment, control flow, etc) with DDCG.
The only reason it's on my personal Github is because the original is so hard to find.
https://github.com/eatonphil/one-pass-code-generation-in-v8
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 learned about Chez when Racket started their rewrite from C to Chez. Made me think why they don't just build Racket entirely in its self!
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 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.
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.
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.
Go Huskies?
Here is an interview talking about the move to ChezScheme https://www.notamonadtutorial.com/rebuilding-the-racket-comp...
"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."
And much more.
"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."
And much more.
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.
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.
Off topic, but I just noticed this post's post ID on HN: 32600000
I love scheme but I hate emacs.
So I just never program in scheme.
So I just never program in scheme.
This works great for any Scheme, I think: https://docs.racket-lang.org/drracket/
It works for Schemes that DrRacket supports or ones implemented via #lang. I don't think Chez Scheme is one of those.
There's actually a plugin that lets one use Chez directly from DrRacket.
Got a link?
I used the plugin to run the Chez version of minikanren some time ago. I think it was this one:
https://github.com/Syntacticlosure/chez-runner
There might be more on the racket package server.
https://github.com/Syntacticlosure/chez-runner
There might be more on the racket package server.
Last time I checked, it didn't have true REPL development ? i.e you couldn't "just eval" a function ?
DrRacket has had a REPL at least since 2013 (which was when I first used it).
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.
Yes exactly ! Sory for confusion.
so does doug hoyte, apparantly, which is why the final words of 'let over lambda' are dedicated to using vi instead of emacs to hack on lisps.
Right, but what about normal text editors?
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…).
`ed` doesn't really integrate with anything other than stdio.
what's with all these y's in their names! hoyte, dybvig
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....