程序解释期间的高效增量哈希计算

时间:2012-04-25 01:05:17

标签: hash lisp scheme interpreter memoization

我想写一个递归memoizing Scheme解释器。在评估期间的任何时候,解释器应该能够检测它何时接收到它之前看到的一对表达式和环境作为参数。

evalapply的简单记忆效率低下。它需要在每次调用eval / apply时在哈希表中查找参数,这需要在哈希表匹配上遍历整个(可能很大的)参数。

例如,假设解释器评估程序

(car (list A))

其中A计算大对象。当解释器评估应用程序(list A)时,它首先单独评估listA。在将list应用于A之前,它会在其哈希表中查找之前是否已经看过此应用程序,遍历整个A对象以计算哈希值。稍后,当memoizing解释器将car应用于包含A的列表时,它会计算此列表的哈希值,该哈希值再次涉及遍历整个A对象。

相反,我想构建一个解释器,逐步建立近似唯一的哈希值,避免重新计算,并尽可能保证冲突。

例如,可以递归地扩展解释器操作的每个对象及其值的MD5,或者,如果它是复合对象,则使用其组件哈希的MD5。环境可以为其每个变量/值条目存储散列,并且可以根据各个散列计算环境的散列。然后,如果环境中的条目发生更改,则无需重新运行整个环境来计算环境的新哈希。相反,只需要重新计算已更改的变量/值对的哈希值,并且需要更新该组哈希值的全局哈希值。

是否存在逐步建立近似唯一哈希的相关工作,特别是在递归记忆和/或程序评估的背景下?

1 个答案:

答案 0 :(得分:2)

请注意,如果表达式是不可变的(不允许自修改代码),那么您可以对它们使用EQ相等。如果环境是不可变的,您可以同样对待它们。 EQ相等性很快,因为您只是将机器指针中的位作为哈希值。

然后问题是改变环境的分配,导致表达式值发生变化。如果他们被允许,怎么处理这个。

一种方法是记录在词法范围内包含破坏性代码的环境,并以某种方式对它们进行注释,以便评估者能够识别出这样的“污染环境”,而不是为它们进行缓存。

顺便说一句,你显然希望哈希表具有弱语义,这样任何变成垃圾的对象都不会堆积在内存中。

相关问题