@Mohanson 这个有意思，我当初就是想写一个 TS 的静态版，没想到一入此坑深似海 ...

nit:
> 编译器是一种将源语言翻译为另一种等价语言的程序软件
编译器对语言的等价性没有要求，只是源代码和目标代码的语义是等价的（经过优化之后语义可能也不完全等价）

> minits 项目的主要工作就集中在中端
生成 IR 一般是算在前端里面的，比如 LLVM 有 Clang、Julia、F18、Rust 等多个“前端”，LLVM 自身算是“中端”+“后端”。LLVM 代码里面有个 CodeGen 文件夹和 Target 文件夹，这俩主要构成“后端”，也就是 LLVM IR->MC，但是 Clang 代码里面也有个 CodeGen 文件夹，这个算是“前端的后端”，也就是 AST->LLVM IR，和 LLVM 的 CodeGen 是有区别的。中端就是 IR->IR。

> 在做语法分析时常用的技术手段是 "Increamental parsing", 也就是增量分析.
我认为对于新人来讲应该重点讲 Recursive Descent，Incremental Parsing 是比较高级的东西
另外看了这一段我是没理解 Incremental Parsing 是怎么做的
最后我觉得 ... 用自然语言举例有点糟糕

> 这在 C 代码中是无法想象的, 因为 C 的基本规则是先声明后赋值. 在 TS 中却可以这么用, 因为 TS 里有一个专门的模块负责维护代码内所有变量的类型, 函数签名或类签名. 这个模块的名字是 TypeChecker
有点乱 ... 首先 C 和 TS 在这里不一样，原因就是 C 标准和 TS 标准的规定不一样，也就是说是个设计问题，不是实现问题。另外 C 编译器一般也有“一个专门的模块负责维护代码内所有变量的类型, 函数签名” ... 一般编译器都有这个东西，这个叫 Symbol Table，然后操作 Symbol Table 的模块可能叫 TypeChecker （ Clang 里面直接就叫 Sema ），TypeChecker 的作用首先是 check，其次才是 infer。

> LLVM 是一个模块化的编译器套件, 它同样遵循上面的几个原则, 但它最伟大的贡献在于提出了通用中间语言表示, 也就是 LLVM IR. 但其实在 LLVM 之前, 绝大部分编译器都有自己的中间表示, 但缺点是它们是不通用的--也就是只在自己的领域内使用. 大部分后端优化, 比如消除冗余代码, 它们的算法是相同的, 但在 LLVM 之前它们要在不同的语言上各自实现一遍. 像 GCC, 它为了支持不同硬件平台, 它内部的许多编译阶段必须做到硬件无关性, GCC 内部使用了一种硬件平台无关的语言, 这个中间语言的名字叫 RTL
据我了解 GCC 有不止一个 IR，除了 RTL 之外至少还有 GENERIC 和 GIMPLE （ LLVM 其实也不止一个，只不过就使用层面而言主要用 LLVM IR ），RTL 已经比较底层了。GENERIC 其实也是 language-independent IR。LLVM 做得好的一个是 License （在当前）占便宜，一个是历史包袱比 GCC 小，然后是把生态建设起来了。换句话说“通用中间语言表示”一直都有，只是在 LLVM 之前一直没人用。
GCC 社区现在已经开始想要解决人员不足的问题了。比如参加 LLVM 的 conference 就算学生也是要收你五十刀的，GCC 的 conference 是免费的，如果是学生甚至可以申请路费赞助，可见 ...

> 实现完全复用 Clang 的 IR 优化和对应硬件平台的代码生成
Clang 不做优化和 CodeGen，这是 LLVM 做的，只是用 Clang 做了 driver

最后我觉得你可以额外讲一下这个项目之后的前景，比如现在是完全没有动态内存分配的 ... 当然作为一个入门教程这些倒没什么必要，不过如果我在现场的话我会提这个问题的