haskell - 解释器环境使用 IORef [48 小时内自己写一个 Scheme]

Question

在chapter 7非常好的Write yourself a Scheme in 48 hours在解释语言中处理变量的环境(Scheme，其中变量是可变的)被引入为

type Env = IORef [(String, IORef LispVal)]

-- where LispVal is a simple type representing a lisp value:
data LispVal = Atom String
             | List [LispVal]
             | DottedList [LispVal] LispVal
             | Number Integer
             | String String
             | Bool Bool

非 tl;dr(下文 tl;dr)

State monad 不是一个好的选择是有原因的(环境将被传递并最终需要存在于 runState 的“外部”)所以IORef 被选中。但是，我想知道为什么不只是用 Map String LispVal 表示一个环境？在我对 GHC 如何编译我们的程序的(有限的)理解中，如果我们稍后使用 Map.insert 更改了一个根本不应该复制整个 map 的变量。那么这里真的需要IORef的可变性吗？换句话说，IORef 显然是去这里的路吗？此外，我的印象是，如果可能，最好避免使用 IORef，典型的用例是从外部框架中的回调之类的东西中“泄漏”值。

不过，我努力想出一个比较两种备选方案性能的好实验。看来 GHC 对我的确定性重复调用的优化太好了。

tl;dr

1. 在上面的示例中使用 IORef 是否很明显，无论是在性能方面还是在其他注意事项(可变性，否则代码中的 IO 都是纯代码)方面？
2. 如果我们希望使用 insert 或 insertWith 进行频繁更改，那么在这里使用 Map String LispVal 是不是一个糟糕的选择？

Answer 1

1. Map String LispVal 明显优于[(String, LispVal)]。使用列表的唯一原因是传统:Scheme 解释器是出了名的极简主义，并且经常在 Scheme 中实现，其中基本数据结构是一对，从中可以很容易地构建关联列表，但是映射需要更多的工作。如果您可以轻松访问采用您的实现语言的真实 map ，请使用它，除非您想假装它仍然是 1970 年代。

2. 对于您目前定义的 LispVal 类型，实际上并不需要任何 IORef。我认为作者正在使用 IORef 来准备处理 lambda 和闭包。闭包将为它的环境捕获一个 Env。如果像你想象的那样实现，没有 IORefs，那么就像

   (let ((x 1))
     (let ((f (lambda () x)))
       (set! x 2)
       (f)))
   

   必须返回 1，而 2 是所需的结果。解释器需要一种方法让 set! 表达式修改已经捕获的环境。

   我还没有特别认真地考虑过你是否真的需要两层 IORef，或者一层就足够了。不过，这本书的作者可能有。