在这篇文章里我将介绍常见的解释器主要的工作流程,由于一个解释器通常有很多复杂的细节,在这里我仅仅是进行一些粗略的介绍。此外我将介绍人们通常是用怎样的方法来构建一个想要的解释器的。关于为什么我只介绍解释器而不介绍编译器的原因,请参见前言部分。
在上一篇文章里我曾经提到过,不论是解释器还是编译器,在运行的初期都需要做两件事:逐字逐句地解析程序员写的代码,并将其转换为一种内部的数据结构。做这些工作的被我们称为一个解释器的“前端”(front-end),而我们前面说的两件事则分别被称为“扫描(scan)”和“解析(parse)”。
首先,我先解释一下,为什么需要把程序员的代码转换为一种内部的数据结构?这主要是因为转换为一种数据结构后,解释器可以更快速,更方便地访问这个数据结构的某一部分,在这种数据结构中,我们向下访问一组数据中的一部分的时候,就可以像访问一个C语言的结构体成员或者Java的类成员一样容易(实际上很多解释器就是这么做的);需要优化或者转换我们的语言时,只需要修改这一数据结构即可。为什么不是逐条解析并执行呢?理论上讲如果你的语言足够简单,(例如汇编语言)确实是可以做到的,但实际上我们设计的语言远比汇编复杂得多,表达式a的结果可能依赖表达式b,因此我们不得不先求得b的值再求a的值;系统的状态也难以直接从代码中获知,例如,你可能可以用类似goto的语句指定解释器跳到指定行的代码,但如果我们要跟踪的代码在if/while语句中呢?在一个递归函数的某一层递归中呢?显然这些状态无法直接从代码的某一位置获得。
用什么数据结构来描述要解释的代码比较合适呢?例如,我们想要用数据结构来保存表达式1 * (2 + 3)