[PLT] 柯里化的前生今世（四）：编译器与解释器
关于
本文是系列文章中的第四篇，
在上一篇中，我们提到了形式语言与文法，S表达式与M表达式，同像性。
本文将开始写一个简单的解释器，
通过具体实现，我们来理解求值环境，动态作用域和静态作用域，还有闭包等概念。
当然，一篇文章来写完这些肯定是不够的，我们可以慢慢来，循序渐进。
写完了这个解释器之后，我们会增加一些新的功能。
编译器与解释器
编译器会将源代码转换成另一种语言的代码，然后在支持后一种语言的机器上执行。
而解释器则不同，它会逐行分析源代码，直接执行分析结果。
值得一提的是，编译和解释是执行代码的两种手段，
具体的语言实现很可能采用两者的混合形式。
例如，一段Java程序，会首先经过javac编译为字节码，
字节码再交由Java虚拟机来解释执行。（JIT和RTSJ，略。。
编译器包含以下三个部分，
编译器前端：词法分析，语法分析，最终生成抽象语法树这种中间代码。
编译器优化：中间代码多次转换，多种优化，
编译器后端：目标代码生成，优化目标代码。
解释器不包含目标代码生成阶段，将优化结果直接执行。
前端和优化，是编译器和解释器共有的。
抽象语法树
编译器前端会分析源代码文本，生成一棵抽象语法树。
假如，我们有如下源代码，
(1+2*3)*(4-5)
使用ANTLR，我们得到了（具体）语法树，
语法文件如下：
grammar Expr;
expr: expr ('*'|'/') expr
| expr ('+'|'-') expr
| INT
| '(' expr ')'
;
INT: [0-9]+ ;
WS: [ \t]+ -> skip ;
我们看到语法树包含了产生式的名称，这在后续处理过程中是不需要的，
因此，编译器前端会将具体语法树转换成一种中间形式——抽象语法树。
(* (+ 1 (* 2 3)) (- 4 5))
这不就是S表达式吗？
对的，编译器前端会将任何语言的源代码转换成与具体语法无关的抽象语法树，
而S表达式正是这种抽象语法树的线性编码。
（因此，你写任何语言，本质上都是在写Lisp。。
格林斯潘第十定律：
任何C或Fortran程序复杂到一定程度之后，都会包含一个临时开发的、不合规范的、充满程序错误的、运行速度很慢的、只有一半功能的Common Lisp实现。
简化解释器的实现
为了简化解释器的实现，我们会直接分析S表达式（抽象语法树），并且略过优化环节。我们也不解释四则运算表达式，因为这涉及到了操作符的定义问题。
我们将直接实现lambda表达式和函数的调用。
(define (eval-exp exp)
(handle-decision-tree
`((,is-symbol? ,eval-symbol)
(,is-self-eval-exp? ,eval-self-eval-exp)
(,is-list?
((,is-lambda? ,eval-lambda)
(,is-function-call-list? ,eval-function-call-list))))
exp))
和其他解释器的教材不同的是，我没有写那么多的if-else，
而是把决策模式提取出来了，这样会更清晰一些。
eval-exp会根据exp的具体形式，寻找相应的处理方式，
而各个处理方式中，还有可能再用到eval-exp来处理子表达式。
因此，这是一个递归执行的过程。
下文，我们会剖析这个简单的解释器，
把每个处理分支都实现一下。
关于写作意图
本系列文章的写作目的是想借着柯里化这个概念，
把函数式编程相关的知识点串联起来。
为什么选择柯里化呢，因为柯里化首先和高阶函数相关，
我可以借此来引入作用域的概念，
continuation本身就是一个单参函数，顺便就可以介绍了，
hygienic macro也涉及到了标识符的查找，学了求值环境也容易理解了。
其次，带参数的类型，可以类比函数的柯里化来理解，
要想理解带参数的类型，我们就得学习类型，以及代数数据类型，
从而继续深入下去，学习Functor，Applicative，Monad这些类型类。
这样类型系统就揭开了神秘的面纱。
当然，这些都是偏工业应用的，并没有涉及理论基础，
自动机理论，可计算性理论，形式语义，也不适合在本系列中提及，
写完本系列后，我会尝试写其他系列，希望能覆盖掉某些点，
以此来督促自己努力学习，小心求证。
参考
程序设计语言：实践之路
编程语言实现模式
The Definitive ANTLR 4 Reference
Lisp in Small Pieces
Java 是编译型语言还是解释型语言？
Abstract vs. Concrete Syntax Trees
