需要調用/按名稱調用Lisp解釋器策略的開銷

Question

我有一個部分完成的解釋器，用於詞法范圍的“純Lisp”（沒有set! ），它使用按需調用評估模型，該模型通過簡單的緩存進行逐個調用，解釋器自然使用環境 -基於評估模型。

評估lambda抽象的標准方法，例如，從正式的paramatres和評估抽象的環境構建一個新環境，並簡單地將參數的評估放在它們自己的環境中。 然后在新環境中評估抽象主體是行不通的，因為它意味着按值調用語義。

我對這個問題的解決方案是用“查找函數”替換需要“環境”的概念，它只是將符號作為參數，並生成相關的數據。 這可以很容易地從一個環境。 Lambda應用程序只需通過查找函數再次對主體進行評估，該查找函數由定義所在的環境和參數所在的環境構成。 它只是在需要時懶洋洋地評估它們。

我想知道的是這個模型的開銷是多少，為每個應用程序生成這些查找的成本是多少，這些查找的代碼非常大。 我知道在Scheme中的lambda應用程序和創建是相當便宜的，許多來源主張廣泛使用它們來維護代碼的可讀性，即使在很多情況下它們會有輕微的開銷。 但由於lambda應用程序在任何lisp中無處不在，我想知道使用可能不同的模型可以節省多少性能。 我嘗試在谷歌搜索這個，但我找到的所有需要​​解釋的解釋器的模型更加尷尬，但通常是為了適應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在環境列表上簡單地使用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--重寫它。

啊，我最初甚至無法提交這個，因為標簽“按需調用”尚不存在，很有希望開始。

Answer 1

“你可能做的另一件事就是簡單地用每個單獨的數據標記一個可以在數據結構中從中檢索的環境，它可能看起來很詳盡，但最后所有需要標記的都會想到它是列表和一個非常特殊的情況，lambda抽象的主體只包含一個符號。 對於“您的”模型中的其他數據，其評估與其環境無關。

這也解決了懶惰的cons細胞和列表的一個主要問題，它們只是傳遞給程序中的其他位置。

因此，假設列表本身標有環境，您可以在評估時提取環境。