Scheme can be compiled. https://github.com/cisco/ChezScheme
In A Brief History of Lisp Machines (2008)cisco
ChezScheme
Scheme2016–2025
cisco / ChezScheme
ChezScheme
Chez Scheme
26Distinct people
34Mentions
0Explicit recommenders
7.4KGitHub stars
What to know before exploring
What it is
Chez Scheme
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year34 dated mentions
Observed mentions: 2016-04-26 15:11:27 UTC to 2025-11-10 17:25:51 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 5 | 3 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 2 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Tip: Clone this repo with git clone --filter=blob:none to avoid
eagerly downloading large boot files for older versions.
Chez Scheme is both a programming language and an implementation of
that language, with supporting tools and documentation.
Supported platforms (bytecode interpreter may work for others):
Windows: x86, x86_64, AArch64
Mac OS: x86, x86_64, AArch64, PowerPC32
Linux: x86, x86_64, ARMv6, AArch64, RV64G, LoongArch64, PowerPC32
FreeBSD: x86, x86_64, ARMv6, AArch64, PowerPC32
OpenBSD: x86, x86_64, ARMv6, AArch64, PowerPC32
NetBSD: x86, x86_64, ARMv6, AArch64, PowerPC32
Solaris: x86, x86_64
GNU/Hurd: x86, x86_64
Haiku: x86_64
Android: ARMv7, AArch64
iOS: AArch64
WebAssembly via Emscripten (bytecode interpreter only)
As a superset of the language described in the
Revised6 Report on the Algorithmic Language Scheme
(R6RS), Chez Scheme supports all standard features of Scheme,
including first-class procedures, proper treatment of tail calls,
continuations, user-defined records, libraries, exceptions, and
hygienic macro expansion.
Chez Scheme also includes extensive support for interfacing with C
and other languages, support for multiple threads possibly running
on multiple cores, non-blocking I/O, and many other features.
The Chez Scheme implementation consists of a compiler, run-time
system, and programming environment.
Although an interpreter is available, all code is compiled by
default.
Source code is compiled on-the-fly when loaded from a source file
or entered via the shell.
A source file can also be precompiled into a stored binary form and
automatically recompiled when its dependencies change.
Whether compiling on the fly or precompiling, the compiler produces
optimized machine code, with some optimization across separately
compiled library boundaries.
The compiler can also be directed to perform whole-program compilation,
which does full cross-library optimization and also reduces a
program and the libraries upon which it depends to a single binary.
The run-time system interfaces with the operating system and supports,
among other things, binary and textual (Unicode) I/O, automatic
storage management (dynamic memory allocation and generational
garbage collection), library management, and exception handling.
By default, the compiler is included in the run-time system, allowing
programs to be generated and compiled at run time, and storage for
dynamically compiled code, just like any other dynamically allocated
storage, is automatically reclaimed by the garbage collector.
The programming environment includes a source-level debugger, a
mechanism for producing HTML displays of profile counts and program
"hot spots" when profiling is enabled during compilation, tools for
inspecting memory usage, and an interactive shell interface (the
expression editor, or "expeditor" for short) that supports multi-line
expression editing.
The R6RS core of the Chez Scheme language is described in
The Scheme Programming Language,
which also includes an introduction to Scheme and a set of example programs.
Chez Scheme's additional language, run-time system, and
programming environment features are described in the
Chez Scheme User's Guide.
The latter includes a shared index and a shared summary of forms,
with links where appropriate to the former, so it is often the best
starting point.
Get started with Chez Scheme by Building Chez Scheme.
For more information about the implementation and a guide to modifying
Chez Scheme, see implementation notes.
For more information on Chez Scheme, see the Chez Scheme Project Page.
Read the full README on GitHubWhat Hacker News says
7 sourcesBack in the day, Chez Scheme was pretty damn fast:
https://github.com/cisco/chezscheme
Dybvig went to Cisco and open-sourced it. Last I read, Racket lang is swapping over to use Chez as its foundation: https://racket-lang.org
I've also heard that HN is written in Arc, which is a Lisp dialect that runs on top of Racket.
In Ask HN: Will Rust be as popular as Go or C++?> 1. The persistent approach is not right for global variables, which are dynamically bound. So I ended up needing two Environment classes, a Map-based one for the global scope, and then a persistent one for locals. That, of course, also requires an interface so that most code can work polymorphically with both types.
Can you give an example of what you mean?
"Global variables" are simply variables declared at a top-level scope. They don't need to be "dynamically bound" if you unravel the top-level into a sequences of statements that thread their environment (which is a bog-standard practice for interpreters, and how you should handle blocks, too), unless you'd like to be able to reference variables declared below you in the global scope. And that can be resolved by passing a dynamic environment in addition to the lexical one. Or by makin
Read the rest
g a single pass over the global space, grabbing all the declared names, and making that your initial lexical environment. But, of course, this is all speculation without an example.
> I considered having a problem exercise to do effectively that, but I felt like it might be reaching a little too far for a first-time language implementer.
Uniquely renaming variables is, in my opinion, a far simpler concept to grasp than nesting scope resolution. It would also be far easier to implement, with notably less code change, and continue to allow you to add another compiler pass and allow the reader to cover ground. The actual downside is that it achieves your goal without needing to explain the whole mess, which means the chapter doesn't get to spend time explaining how to think about resolving variables.
> code like this is not common:
Your toy example is, obviously, a situation where you should reconsider what you're doing. However, a program such as
lookup :: Env -> Ear -> Value
lookup = ...
f :: Env -> Expr -> Expr
f env exp =
let lookup = lookup env
in ...
is a fairly common pattern in automatically curried languages, or languages with functional-style loops (see [0] for such a usage of shadowing). I don't think that your stance is wrong, but I think decrying other stances isn't particularly fair to the language design world, where there are many languages where such shadowing is neither rare nor often an error. Of course, there is some play here insofar as treating function declarations differently from other variables, which is not the case in many languages where this behavior is accepted.
Also, for what it's worth, translating the above code to JavaScript yields a stack overflow error if you invoke lookup inside of `f`.
0. https://github.com/cisco/ChezScheme/blob/06f858f9a505b9d6fb6...
Chez Scheme [0] is written using the nanopass framework, and it's regarded as one of the fastest Scheme compilers in existence [1]. Before it was rewritten to use the nanopass system, Chez's compiler was known for its performance in terms of lines of code compiled per second; the rewrite slowed it down a bit, but the quality and performance of generated machine code improved. Andy Keep and Kent Dybvig wrote a paper about the project [2]. I haven't browsed the Chez source, but it's a good way to answer your question.
[0] https://github.com/cisco/ChezScheme
[1] http://ecraven.github.io/r7rs-benchmarks/benchmark.html
[2] https://www.cs.indiana.edu/~dyb/pubs/commercial-nanopass.pdf
In My first fifteen compilersApparently a fast compiler that produces fast programs, with Windows, Mac and 64-bit support as well. Although there are no binaries of the 9.4 release, you'd have to build it yourself:
https://github.com/cisco/ChezScheme/releases
https://cisco.github.io/ChezScheme/release_notes/v9.4/releas...
In The Development of Chez Scheme (2006) [pdf]Note that Chez Scheme is now open source. This is a great gift to all compiler hackers, and I sincerely thank Cisco for the release.
https://github.com/cisco/ChezScheme
In The Development of Chez Scheme (2006) [pdf]