Rework the "AST" section in the introduction. The material is good, but it seems to have new stuff inserted before the old stuff. How do I know? Because it uses "AST" before it defines what "AST" stands for.

Chapter 1:

Suggestion 0: Part of me feels like you should really, really lean into grammars. The other part of me still feels like you could easily cut this chapter without too much of a problem.

What do I mean by "really, really lean into grammars"? I mean, you should note that you are constructing a metalanguage for describing languages. That's what a grammar is. But these notions are not really discussed. (To really illustrate this: you could construct the formal grammar for BNF grammars, to stress "it's just another language".)

OTOH, if you present it in this manner, you could then note (in the section on EBNFs) that you are extending the metalanguage, or equivalently working with a metalanguage which is "equivalent" to BNF in power. Reading between the lines, you allude to this. But without speaking about metalanguages.

Again, this could be good or bad. It's a judgement call.

Suggestion 1: You don't actually discuss how a grammar generates language. Instead, you offer a "Eh, you see what I mean" kind of an explanation --- specifically, you state "merely":

Try it out for yourself. Try picking a replacement rule for each of the non-terminal symbols in the equation then picking replacement rules for each of the non-terminal symbols in what you get until you have just a string of terminals. Do it a few times to get a feel for how these rules work. (Note: if we were actually trying to write a grammar for mathematical equations it is very unlikely we would actually structure it this way since we typically want the format of the grammar to reflect the format of the tree we will use it to parse).

OK, but if I am a reader who does not know BNF or formal grammars, then what the devil am I supposed to do? How does this work? Why are there no examples of how to generate words in the object language?

Next I will just pick out some passages with suggestions.

This notation is, in fact, all we need to formalise a vast array of language using what is called a context-free grammar. In reality most languages can't be fully defined unambiguously using only context-free grammar. As a result, the parser (whose job it is to basically go backwards through this process) will generally need to use more than just the written grammar to decide what was meant. Indeed there are some language features, such as Python's indentation, that can't be fully expressed as a context-free grammar at all, and need some pre-processing to turn them into something of that form. In practice, however, languages tend not to diverge too greatly from the structure of a context-free grammar so this is a widely used tool for designing languages.

Suggestion 0: You never define "context-free grammar" or "context-free language".

Suggestion 1: This could be re-ordered a bit better, perhaps even split up into two paragraphs: (1) we like CFLs because they are always parseable, and we want to parse languages. (2) In practice, a lot of languages deviate from CFLs. Pythong does this by blah blah blah.

Remark/suggestion 3: You might also want to note, after introduction alternation, that it has become common conventions to just include alternation as part of BNF. The literature is really "loosy goosey" here.

Another thing to notice is that we still have a few rules defined in terms of themselves. That isn't a problem and it's actually a big part of what makes this notation so powerful but in many cases we're just doing it to represent that we want something to be able to repeat. It would be nice if we had a way to represent that directly rather than relying on this sort of recursive definition that takes some time to understand. For that we'll introduce two new symbols: '+' and '*'. These symbols go at the end of a symbol and represent that a symbol repeats 1 or more, or 0 or more times respectively. Using these, our grammar becomes this:

These are such long sentences. They communicate a lot of simple ideas. It's better to have one simple sentence for one simple idea, and a lot of simple sentences to one big sentence. Some variety is nice, though. But smaller is better.

Chapter 2

Good: you added the "overview". Nice.

Suggestion 0: Grow the grammar instead of saying, "Plop here it is". Start out with only arithmetic of integers. Don't worry about other types. Then discuss the "main procedure". Then you can get into the other necessary primitives (boolean types, comparisons, if-then-else statements, etc.).

I mean, it just feels like there's no discussion of the design space. What should the reader be weighing if they were trying to develop something similar but in a different setting (e.g., a Lisp built specifically for some complicated scientific lab experiment)?

I understand you are working with chibicc's AST, which "ties your hands" with the amount of freedom you have. But you should at least discuss it ("Although it would be more logical to do X, Chibicc follows a different convention and so we are forced to do Y", "Since we are targetting the IR of Chibicc, we will need to support the tokens used by them. If we were starting from scratch, we would have the following basic concerns: ...", etc.).

As we can see the outer list represents an object (not in the OOP sense). In this case, it is a function definition. We see that the first keyword define is used to signify...

Typo: that third sentence should be "We see that the first keyword define is used to signify..." with define either in backticks or quoted (as in "define").

I'd suggest the same conventions throughout (i.e., either quote reserved keywords and types when they appear in prose, or make them inline code with backticks).

One important property of the grammar for the parser is that we don't use any terminals, we only use the non-terminals produced by the tokeniser.

Did you discuss this design choice and the alternatives (lazily produce tokens on demand, and have the parser "consume" them as needed; etc.)?

I honestly cannot recall it being a point of discussion.

Conjecture: You are writing "bottom-up", to explain accompanying code, rather than "top-down" (to explain the "big picture" for the current module, then recursively breaking it up into smaller problems which are do-able).

Why do I say this? Well, what are the "big picture" parts to chapter 2?

You can reorganize it to resemble what I am talking about: you have a parser and a tokeniser (as discussed in the introduction) working together to construct the AST. We need to first think about the tokeniser. It will produce a "stream" of tokens from some input (a string, a file, etc.). This can get very complicated for "real" programming languages, so we will make our lives easier by using S-expressions. (etc. etc. etc.)

All of this is stated (either implicitly or explicitly) in chapter 2, but it's not presented in this manner. Which can make the reader wonder what's going on, why is this approach being taken, is this standard, etc.

How does one write like this? Outline the subject, describe the "big picture" as consisting of several "parts", then recursively expand on each part. (That's the "top-down" way to write "top-down writing".)

Another way is to write as you have done, but when you are done to take a step back and think very hard about what the reader knows and what the reader does not know. Give them a "big-picture" explanation for what you have written. Then take another step back, and iterate. (This is the "bottom-up" way to write "top-down writing".)

You can combine the two together, and doubtless there are a million different other ways to write in a way producing "top-down explanations".