Skim

https://andykeep.com/pubs/dissertation.pdf

Also see the this text:

https://www.cs.umd.edu/class/fall2025/cmsc430/Notes.html

Nanopass uses structures internally to represent the programs.

The Nanopass dsl just gives the user a nicer syntax to specify the transformations.

So, a conventional linked representation of a tree (but not a tree of cons cells).

Yes.

An Incremental Approach to Compiler Construction

Abdulaziz Ghuloum

http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

Abstract

Compilers are perceived to be magical artifacts, carefully crafted by the wizards, and unfathomable by the mere mortals. Books on compilers are better described as wizard-talk: written by and for a clique of all-knowing practitioners. Real-life compilers are too complex to serve as an educational tool. And the gap between real-life compilers and the educational toy compilers is too wide. The novice compiler writer stands puzzled facing an impenetrable barrier, “better write an interpreter instead.”

The goal of this paper is to break that barrier. We show that building a compiler can be as easy as building an interpreter. The compiler we construct accepts a large subset of the Scheme programming language and produces assembly code for the Intel-x86 architecture, the dominant architecture of personal computing. The development of the compiler is broken into many small incremental steps. Every step yields a fully working compiler for a progressively expanding subset of Scheme. Every compiler step produces real assembly code that can be assembled then executed directly by the hardware. We assume that the reader is familiar with the basic computer architecture: its components and execution model. Detailed knowledge of the Intel-x86 architecture is not required.

The development of the compiler is described in detail in an extended tutorial. Supporting material for the tutorial such as an automated testing facility coupled with a comprehensive test suite are provided with the tutorial. It is our hope that current and future implementors of Scheme find in this paper the motivation for developing high-performance compilers and the means for achieving that goal.

Inspired by Ghuloum's book is this really nice book by Nora Sandler: Writing a C Compiler https://norasandler.com/book/

Another recent book inspired by Ghuloum is Essentials of Compilation: An Incremental Approach (which publishes Python and Racket versions) https://github.com/IUCompilerCourse/Essentials-of-Compilatio...

Nada Amin has a nice implementation of Aziz's approach, with tests:

https://github.com/namin/inc

One of the greatest papers in computer science. So dense in its 11 pages, yet very approachable.

I misread it too.

Loved the examples!

This is pretty small.

http://scheme.dk/blog/2006/12/self-evaluating-evaluator.html

If you are into continuations, check Friedman's papers on ReadScheme.

https://github.com/schemedoc/bibliography/blob/master/page6....

In particular look at "Programming with Continuations", "Engines Build Process Abstractions" and "Continuations and Coroutines".

Yes. I am following the Scheme tradition of representing immediate values as tagged pointers. And (ref i31) is the obvious choice when using WebAssembly. I am happy you and the team added GC to WebAssembly.

Details on the representation.

https://github.com/soegaard/webracket/blob/main/compiler.rkt...

I am more or less only using the linear memory for the JavaScript FFI. FASL-encoded values are passed back and forth to JavaScript.

I wouldn't say compiling full Racket to WebAssembly is impossible. But I think the consensus is that one can't add a WebAssembly backend to the compiler in the same manner as the x86 and arm backends. These backends manipulate the stack in ways WebAssembly prohibits.

This forces an Racket implementation to make continuations explicit. And that will most likely mean a WebAssembly backend will be slower than the native backends.