写给程序员的编程语言科普——（一）解释器的基本工作流程和构造方法

在这篇文章里我将介绍常见的解释器主要的工作流程，由于一个解释器通常有很多复杂的细节，在这里我仅仅是进行一些粗略的介绍。此外我将介绍人们通常是用怎样的方法来构建一个想要的解释器的。关于为什么我只介绍解释器而不介绍编译器的原因，请参见前言部分。

在上一篇文章里我曾经提到过，不论是解释器还是编译器，在运行的初期都需要做两件事：逐字逐句地解析程序员写的代码，并将其转换为一种内部的数据结构。做这些工作的被我们称为一个解释器的“前端”（front-end），而我们前面说的两件事则分别被称为“扫描（scan）”和“解析（parse）”。

首先，我先解释一下，为什么需要把程序员的代码转换为一种内部的数据结构？这主要是因为转换为一种数据结构后，解释器可以更快速，更方便地访问这个数据结构的某一部分，在这种数据结构中，我们向下访问一组数据中的一部分的时候，就可以像访问一个C语言的结构体成员或者Java的类成员一样容易（实际上很多解释器就是这么做的）；需要优化或者转换我们的语言时，只需要修改这一数据结构即可。为什么不是逐条解析并执行呢？理论上讲如果你的语言足够简单，（例如汇编语言）确实是可以做到的，但实际上我们设计的语言远比汇编复杂得多，表达式a的结果可能依赖表达式b，因此我们不得不先求得b的值再求a的值；系统的状态也难以直接从代码中获知，例如，你可能可以用类似goto的语句指定解释器跳到指定行的代码，但如果我们要跟踪的代码在if/while语句中呢？在一个递归函数的某一层递归中呢？显然这些状态无法直接从代码的某一位置获得。

用什么数据结构来描述要解释的代码比较合适呢？例如，我们想要用数据结构来保存表达式1 * （2 + 3）