It might not have the same lingo as the modern type checking specification but most of the ideas are there. It talks about type systems, type expressions, type rules, constructed types like array/struct, type variables for unknown types, etc. It puts the type rules in the grammar productions. It stores the type info in the AST nodes. It uses the chained symbol tables as the type environments.
It has sections on type conversion, operator/function overloading, polymorphic functions (parameterized types), and type unification.
It has all the pieces and steps to build a type checker.
https://www.amazon.com/Compilers-Principles-Techniques-Tools...
It has 11 sub-sections, 2 of which are about type checking
6.3 - Types and Declarations, pages 370-378
6.5 - Type Checking - pages 386 - 398
So that's about 20 pages out of 993 pages. A fraction of a chapter!
---
What I was referring to is the appendix "A Complete Front End", which contains a lexer and parser, but not a type checker! Doesn't sound complete to me.
I guess they have a pass to create the three-address code, and type checking is only in service of that. But they don't give you the source code!
---
Also weirdly, when you look at the intro chapter "The structure of a compiler", it goes
1.2.2 Syntax Analysis
1.2.3 Semantic Analysis (3 paragraphs that mentions type checking and coercions)
1.2.4 Intermediate Code Generation
But when you look at the chapters, there's NO semantic analysis chapter! It goes from (4) Syntax analysis, (5) Syntax-directed translation, to (6) intermediate code generation.
I think there's a missing chapter! (or two)
WTF. The 2nd edition is really butchered.
What the heck happened ...
The second edition cut a bunch of C++ material out.
And yeah I don't think I missed anything -- I think it even had better diagrams.
So yeah I believe that general rule! I didn't realize that at the time I bought the Dragon Book.
Pretty sad how you can lose knowledge over time!
---
The books also respond to fashion -- e.g. Java was a popular teaching language, so they had to add more Java. I think that is reasonable in some ways but can backfire in the long term.
Although I guess I am not too excited about MIX assembly in TAOCP and so forth, so it's a hard problem
Books also tend to become more sparse on the page, and with more pointless “illustrative” stock photos that add nothing and take up page real estate (leading to more advanced topics being dropped to reclaim space), but make the book seem more approachable to undergraduates.
Generally applies more to physics, chemistry, and math books than computer science, but it is a general phenomenon.
https://mukulrathi.com/create-your-own-programming-language/...
https://jaked.org/blog/2021-09-07-Reconstructing-TypeScript-...
I read through the first 10 chapters of TAPL, and skimmed the rest. The first 10 chapters were good to remind myself of the framing. But as far as I can tell, all the stuff I care about is stuffed into one chapter (chapter 11 I think), and the rest isn't that relevant (type inference stuff that is not mainstream AFAIK)
This is also good:
https://github.com/golang/example/blob/master/gotypes/README...
And yeah some of us had the same conversation on Reddit -- somebody needs to make a Crafting Interpreters for type checking :) Preferably with OOP and functional and nominal/structural systems.
---
Also, it dawned on me that what makes TAPL incredibly difficult to read is that it lacks example PROGRAMS.
It has the type checkers for languages, but no programs that pass and fail the type checker. You are left to kind of imagine what the language looks like from the definition of its type checker !! Look at chapter 10 for example.
I mean I get that this is a math book, but there does seem to be a big hole in PL textbooks / literature.
Also I was kinda shocked that the Dragon Book doesn't contain a type checker. For some reason I thought it would -- doesn't everyone say it's the authoritative compiler textbook? And IIRC there are like 10 pages on type checking out of ~500 or more.