理解Scheme/Racket中abort延续：两种写法为何结果不同？

• 近期在Racket环境下学习Scheme的延续与限定延续控制算子，参照论文用call/cc实现了shift/reset算子，初始代码运行符合预期。
• 在理解*abort函数定义时遇到困惑：
  • 原代码采用((lambda (v) (*meta-continuation* v)) (_thunk))或等价的(let ((v (_thunk))) (*meta-continuation* v))写法，运行结果为预期的17
  • 改为直接调用(*meta-continuation* (_thunk))后，计算结果变为9，reset中存储的嵌套shift延续仿佛被丢弃
• 原本认为两种写法等价：无论是否将(_thunk)的结果绑定到变量再传入*meta-continuation*，(_thunk)的延续都应该是*meta-continuation*，即便call/cc导致不返回，想明确二者的差异所在。

核心差异在于**(_thunk)执行时所处的延续环境完全不同**：

1. 原写法（lambda/let绑定）：
   执行(_thunk)时，它的当前延续是「将结果传递给*meta-continuation*」——也就是lambda (v) (*meta-continuation* v)的剩余逻辑。*meta-continuation*是reset捕获的顶层延续，这个写法相当于把(_thunk)的执行结果完整“交付”给顶层延续处理，(_thunk)内部的shift会正确捕获reset范围内的嵌套延续。

2. 修改后的写法（直接嵌套调用）：
   此时(_thunk)是作为*meta-continuation*的参数被求值的，它的当前延续是「等待参数求值完成后，执行*meta-continuation*本身」。但*meta-continuation*是一个会直接接管控制流的延续，当(_thunk)内部触发shift时，它捕获的延续会被这个“参数求值等待逻辑”截断，不再是原写法中完整的、能复用reset嵌套延续的上下文。

对应到你的案例，原写法中shift捕获的嵌套延续会被*meta-continuation*正确结合，最终得到17；修改后，嵌套延续被破坏，导致计算结果变为9。

简单总结：原写法给(_thunk)保留了一个“传递结果到顶层延续”的中间延续上下文，而修改后的写法直接把(_thunk)的延续绑定到*meta-continuation*的参数位置，打乱了shift捕获延续的逻辑链。

内容的提问来源于stack exchange，提问作者Ric