Performance 按需调用/按名调用Lisp解释器策略的开销

我已经为一个词汇范围的“pure Lisp”（no

set！

）完成了部分解释器，该解释器使用一个按需调用的评估模型，该模型可以通过简单的缓存按名称调用，解释器自然地使用一个基于环境的评估模型

评估lambda抽象的标准方法，例如，从形式参数和评估抽象的环境构建一个新环境，并简单地将参数的评估放在它们自己的环境中。然后在新环境中评估抽象体将不起作用，因为它将意味着按值调用语义

我对这个问题的解决方案是在需要的地方用“查找函数”替换“环境”的概念，它只是以一个符号作为参数，并生成一个相关的数据。可以很容易地从环境中制作。Lambda应用程序只是通过使用查找函数再次计算主体来完成，该函数由定义所在的环境和参数所在的环境组成。只有在需要时才对其进行惰性评估

我想知道的是，这个模型的开销是多少，为每个应用程序生成这些查找的成本有多高，这些查找的代码相当大。我知道Scheme中的lambda应用程序和创建相当便宜，许多源代码都主张广泛使用它们来保持代码的可读性，尽管在很多情况下它们会有轻微的开销。但由于lambda应用程序在任何lisp中都无处不在，我想知道使用一个可能不同的模型可以节省多少性能。我试着在谷歌上搜索这个，但是我发现所有的call by need解释器模型都更加笨拙，但通常都是为了适应

set

我的一些相关代码：

使用查找功能的计算器：

; evaluates a datum using a lookup
; lookup is a function which takes a symbol as an argument and produces the value
; some sorts of more powerful environment
; if lookup is a standard environment, treats it as such
(define (eval-datum! d lookup)
  (cond 
    ((quoted? d) (dequote d)) ; if quoted, just dequote
    ((hastype d symbol-type) ; symbols ... 
     (if (procedure? lookup) ; checks if it's an environment or a lookup function
         (lookup d)
         (lookup-symbol d lookup)))
    ((hastype d pair-type) (eval-pair! d lookup)) ; function application
    (else d))) ; rest is considered self-evaluating

以及生成更高级查找的函数。这尤其让我担心，尽管它是尾部递归的，并且使用非常便宜的
eq？
和
null？
比较，但它看起来并不像在环境列表上简单地使用
assq
那么有效，有时甚至连对它们缺乏随机访问也让我有点担心

; extends a lookup for use in a lambda abstraction
; the inner environment is where the lambda is defined
; the outer environment where it is applied
; params can be either a pair or a symbol
; params automatically tries to match the argument's pattern
(define (extend-lookup! params args inner-env outer-env)
  (lambda (s)
    (let checkparams ((params params) (args args))
      (cond
        ((eq? s params) (datum args)) ; for an improper list or a single symbol, simply turn the arglist into an evaluable list
        ((null? params) (lookup-symbol s inner-env)) ; if the number of paramatres are exhausted, simply use the inner-env
        ((eq? s (car params)) ; in case of a formal parametre match ...
              (refeval! args 0 outer-env)) ; evaluate the needed argument and return it
        (else (checkparams (cdr params) (cdr args))))))) ; repeat for the next paramatre

显然，求值器是通过一个简单的术语简化系统工作的，当计算列表中的表达式时，该系统只是用它们的结果替换它们，只要结果不被认为是自求值的，就引用它们。这是可能的，因为它是一个纯粹的函数式lisp。它还可以一次性捕获缓存和大部分垃圾收集

我应该补充一点，我一直对开销和复杂性理论的理解很差。对于那些说“如果你想要性能，为什么要用Lisp制作解释器？”的人来说，这只是对一般结构的测试，看看它是否有效，我很快就会用C重新编写它

啊，一开始我甚至不能提交这篇文章，因为“按需调用”标签并不存在，这是一个很有希望的开始。
另一件“你”可能做的事情是简单地在每个数据上标记一个可以在数据结构中从中检索的环境，它可能看起来很详尽，但最终需要标记的是列表和一个非常特殊的情况，即lambda抽象的主体只包含一个符号。对于“您的”模型中的其他数据，其评估与环境无关

这也解决了一个主要的问题，就是在程序中的其他地方传递的单元格和列表

因此，假设列表本身标记有一个环境，只要对其进行评估，就可以提取该环境。
看看Queinnec的《小片段Lisp》。尤其是卫生防护中心。在那里，他建立了一系列口译员，每一个都比最后一个快。他解释了几种技术的优缺点。