我现在正在阅读 SICP,并不太了解 5.5.6 SICP 的词法寻址中描述的词法寻址的必要性。
因为它说“因为我们的语言是词法范围的,所以任何表达式的运行时环境都将具有与出现表达式的程序的词法结构平行的结构”,我认为在运行中搜索变量的成本相同 -编译环境中搜索的时间环境。为什么我们要费心去实现一个编译环境?我认为编译环境将具有与程序的词法结构平行的相同结构,这与运行时环境相同,不是吗?
我现在正在阅读 SICP,并不太了解 5.5.6 SICP 的词法寻址中描述的词法寻址的必要性。
因为它说“因为我们的语言是词法范围的,所以任何表达式的运行时环境都将具有与出现表达式的程序的词法结构平行的结构”,我认为在运行中搜索变量的成本相同 -编译环境中搜索的时间环境。为什么我们要费心去实现一个编译环境?我认为编译环境将具有与程序的词法结构平行的相同结构,这与运行时环境相同,不是吗?
词法寻址对于加速变量查找很有用。如果没有词法寻址,查找变量需要在运行时遍历当前环境的框架,或其封闭环境的框架等等——因为我们不知道变量绑定在哪里,如果有的话。这在书中提到:
到目前为止,我们的编译器已经实现了它,它生成使用评估器机器的查找变量值操作的代码。这通过将变量与当前绑定的每个变量进行比较来搜索变量,通过运行时环境逐帧向外工作。如果框架嵌套很深或变量很多,则此搜索可能会很昂贵。
相比之下,词法寻址查找的过程在编译时准确地知道在哪里找到变量,从而大大减少了查找变量所需的时间:
lexical-address-lookup
将环境和由两个数字组成的词法地址作为参数:一个帧号,它指定要传递多少帧,以及一个位移号,它指定在该帧中要传递多少个变量。Lexical-address-lookup
将产生存储在该词法地址相对于当前环境的变量的值。如果我们将lexical-address-lookup
操作添加到我们的机器上,我们可以使编译器生成使用此操作引用变量的代码,而不是lookup-variable-value
.