简单易懂的程序语言入门小册子(6):基于文本替换的解释器,引入continuation
当我写到这里的时候,我自己都吃了一惊。 环境、存储这些比较让人耳熟的还没讲到,continuation先出来了。 维基百科里对continuation的翻译是“延续性”。 这翻译看着总有些违和感而且那个条目也令人不忍直视。 总之continuation似乎没有好的中文翻译,仿佛中国的计算机科学里没有continuation这个概念似的。
Continuation这个概念相当于过程式语言里的函数调用栈。 它是用于保存“现在没空处理,待会再处理的事”的数据结构。 这样说有点抽象,举个例子,函数应用那条表达式的求值过程(call-by-value)是这样:
- 计算
eval(M) ,结果是λX.L , - 计算
eval(N) , - 做替换
L[X←eval(N)] 。
解释器一次只能计算一个表达式,所以当它计算
假设
- 计算
eval(M2) , - 做替换
L1[X←eval(M2)] 。 - 计算
eval(N) , - 做替换
L[X←eval(N)] 。
可以看到,continuation是一个FILO(先进后出)的数据结构,也就是栈。
在之前的解释器里并没有提到continuation,但是解释器仍然能正常工作, 这是因为解释这个解释器的解释器——Racket解释器——帮我们管理了continuation。 这一节的目标是自己管理continuation。
从一个简单的递归函数做起
先说一个概念:尾调用。 假设一个函数体中有一句函数调用表达式
学过C或者C++都知道,调用函数的时候是要保存信息到函数调用栈的(我上学时学的这俩,不知道其他语言的课上会不会讲函数调用栈)。 尾调用的特点是:尾调用理论上不需要保存信息到函数调用栈——实际上也不需要,但是有些语言就不支持,比如说Python。 换句话说,尾调用不会导致continuation增长。 这个很好理解,因为尾调用是最后求值的表达式了,不需要备忘后面要做的事(后面没有事了),所以也就不会导致continuation增长。 后面会从continuation的角度说明为什么尾调用不会令continuation增长。
题外话: 刚才提到“理论上”和“实际上”。 经常能听到这种句式:理论上怎么怎么,可惜,实际上是吧啦吧啦。 其中“吧啦吧啦”是一句对“怎么怎么”的否定。 我觉得这是反科学以及读书无用论的潜意识在作祟,另外有时候是用来逃避责任的借口。 理论上怎么样,实际上就应该怎么样。 如果有套理论的结论和现实的结果不同,那么这就不能称为理论,最多算个猜想,而且是个错误的猜想。
如果一个尾调用是一个递归调用,那么就称为尾递归。 尾递归又叫迭代。 我们现在要做的事其实就是把一个递归程序(之前写的解释器)中的非尾递归全改成尾递归, 也就是递归转迭代。
为了熟悉递归转迭代的套路,先拿一个简单的递归函数练练手。 这个函数就是之前用到的double函数:
加入continuation后的求值过程如下:
然后是写代码。 针对
上面代码中用Lisp里的list数据结构来保存continuation。 我们可以不用list来保存continuation。 Continuation备忘的是“待做的事”。 这个“待做的事”可以理解为一个过程,也就是一个函数。 所以,可以用函数来保存continuation!
空mt是一个直接返回参数的函数(lambda (v) v)。
用函数来保存continuation的写法看起来蛮像回调函数(callback)。 Lisp的一个噱头是程序与数据统一对待,这也算是一个体现吧。 用函数还能实现对象(面向对象编程的对象),这是题外话了。 用函数保存数据一个好处是熟悉这种方法后写起来很方便; 坏处是扩展访问方式比较麻烦,并且调试的时候不能打印详细信息。
顺便再说一下,这种带着一个continuation当参数传来传去的代码风格叫continuation passing style,也就是传说中的CPS。 将一段不带continuation的代码转换成continuation passing style的过程叫CPS变换。 (更准确的说,CPS变换是指将代码中的非尾调用转换成尾调用。)