我正在中间代码的章节中进行类编译器设计。通过在线进行一些研究，我发现了这句话：
当源程序可以包含复合指令时，递归解释是必要的。
我无法在google上找到复合指令。
答案 0 :(得分：2)
在这种情况下（参见the link），作者正在与他称之为迭代解释器的对比，迭代解释器只读取每条指令并服从它，然后转到下一条指令，并且必须对一系列指令进行分析，以找出执行它们的顺序。
但是，对我而言，这种材料的质量似乎值得怀疑。
答案 1 :(得分：1)
来自Chapter 1 Notes - Intro to Compilers
# High level languages support the use of complex expressions.
# Example:
x + y * z / (w + 1)
Parsers使用递归技术来分析复杂表达式并构造语法树。
答案 2 :(得分：1)
那chapter有点啰嗦。
解释器：
用一种语言表达的程序，用另一种语言表达程序。
有关使用相同语言编写解释器的情况，请参阅self interpreter和meta-circular interpreter。
解释器编译源程序并立即执行。
不，那将是just in time compiler; JIT技术可以由解释器使用，但也可用于减少已编译可执行文件的大小。真正的解释器不是JIT编译器。
解释比执行编译的机器代码慢。
通常情况下，虽然有时候完整源代码的解释器可以比JIT编译器更好地进行优化。
当源程序可以逐行执行时，迭代解释是可能的。
如果不是这样，也可能，除非他们使用“迭代解释”来表示“一次读取一行源代码并处理它”，但后来他们有了 “[迭代]解释器[...]重复读取，分析和执行的序列。[...]在迭代循环中重复。”，所以不 - 你可以很好地完成任何输入，一旦你解析了它并做了一些处理。
命令语言的解释器可以是迭代的。
是的，但在这方面command languages并没有什么特别之处。任何语言都可以使用迭代或递归方法进行解释。
当源程序可以包含复合指令时，递归解释是必要的。
您可以将任何递归过程映射到具有显式堆栈的迭代过程，因此递归实现绝不是严格必需。
我认为这意味着与术语复合的表达式相同，主要是因为这是唯一合理的方式。
如果您有口译员，可以看到：
z = a + 5
然后对于表达式a + 5，它可以查找a的值是什么，它知道常量5，然后它可以计算a + 5并存储结果在z。
如果表达式是：
z = a + ( b * c )
然后它可以查找a的值是什么，但是要计算b * c，它必须递归调用自身，或者将z = a + pop()推送到堆栈并计算{{1} }}。
为了使用迭代解释器解释复合术语的表达式，您可以使用临时解码器将源转换为线性形式，因此：
push(b*c)变为：
z = a + ( b * c )
所有带复合项的表达式都可以简化为非复合词。通常这种转换是在代码到达解释器的主循环之前完成的，这使得主循环更简单，更快。
高级语言的解释器必须是递归的。
错，见上文。
查询语言的解释器必须是递归的。
错，见上文。
递归解释比迭代解释慢。
一般都是，但我确信如果你找到它们会有一些例外。
答案 3 :(得分：-1)
以下是您的参考资料：