dummyscheme 是一个受 Lua 启发的 Scheme 方言与解释器。它以 R5RS 为兼容目标，把 Scheme 源码编译为基于寄存器寻址的字节码，并将尾调用优化、一等公民延续 call/cc 和闭包变量的扁平装箱纳入运行时设计。它值得关注的地方不只是“又一个 Lisp”，而是尝试把 Scheme 中最难处理的控制流语义放进一台相对紧凑的虚拟机。
为什么选择寄存器字节码
字节码虚拟机常见两种路线：栈式指令和寄存器式指令。栈式虚拟机通过不断压栈、出栈传递中间值；寄存器式虚拟机则让指令显式引用当前调用帧中的槽位。
例如，下面的 Scheme 表达式：
(+ (* a b) c)
如果用寄存器字节码表示，可以想象成下面的形式。这里仅用于说明模型，并不是 dummyscheme 的真实指令格式：
MUL R3, R0, R1 ; R3 = a * b
ADD R4, R3, R2 ; R4 = R3 + c
RET R4
这种设计与 Lua 虚拟机的思路相近：函数调用帧既保存局部变量，也充当指令操作数的寄存器区。它通常能减少纯栈式机器里的 PUSH、POP 和交换指令，但代价是编译器必须完成寄存器槽位分配，单条指令的编码也可能更宽。
对 Scheme 而言，真正的难点还包括词法闭包、可变捕获变量以及任意位置出现的尾调用。寄存器架构并不会自动解决这些问题，但它为调用帧和局部变量提供了一个清晰的落点。
尾调用不是普通的编译器优化
R5RS 要求实现支持 proper tail recursion。也就是说，尾位置上的函数调用不能持续增加控制栈，否则大量 Scheme 程序虽然语义正确，却会因为递归深度耗尽内存。
普通调用大致会执行以下操作：
- 创建新的调用帧；
- 保存返回位置；
- 跳转到被调用函数；
- 函数返回后恢复旧调用帧。
尾调用不需要回到当前函数继续计算，因此虚拟机可以复用或替换当前帧，而不是再压入一层。这也是字节码解释器通常需要区分 CALL 与尾调用指令的原因之一。
下面是一段可用于检查尾调用行为的 R5RS 程序：
;; tail-call.scm
(define (sum-to n acc)
(if (= n 0)
acc
(sum-to (- n 1) (+ acc n))))
(display (sum-to 10000 0))
(newline)
预期输出为：
50005000
可以把 10000 逐步提高，用它观察解释器是否保持稳定的调用栈占用。不过，这只是工程层面的压力测试，不应把某一个输入规模当作 R5RS 合规性的完整证明。
call/cc 为什么会改变调用帧设计
call-with-current-continuation，通常写作 call/cc，会把“程序接下来要做什么”包装成一个可以保存和调用的值。调用这个值时，程序不是执行一次普通函数返回，而是恢复捕获时的控制上下文。
dummyscheme 通过调用帧的 copy-on-write 机制实现不限次数使用的延续，也就是通常所说的 multi-shot continuation。捕获延续时，运行时可以先共享调用帧；当某一分支需要修改共享状态时，再复制相应数据。与每次捕获都立即深拷贝所有帧相比，这种方法有机会降低只捕获、不反复修改场景的成本。
下面的程序会多次调用同一个延续，同时修改由闭包捕获的局部变量，可用于同时检查 call/cc、multi-shot 行为和变量装箱：
;; continuation.scm
(define (demo)
(let ((resume #f)
(count 0))
(let ((value
(call/cc
(lambda (k)
(set! resume k)
'first))))
(display value)
(newline)
(set! count (+ count 1))
(if (< count 3)
(resume
(if (= count 1)
'second
'third))
(begin
(display "done")
(newline))))))
(demo)
预期输出：
first
second
third
done
假设本地构建得到的可执行文件名为 dummyscheme，可以这样运行；如果项目实际生成了其他名称，只需替换最后一行中的命令：
cat > continuation.scm <<'SCM'
(define (demo)
(let ((resume #f)
(count 0))
(let ((value
(call/cc
(lambda (k)
(set! resume k)
'first))))
(display value)
(newline)
(set! count (+ count 1))
(if (< count 3)
(resume (if (= count 1) 'second 'third))
(begin
(display "done")
(newline))))))
(demo)
SCM
./dummyscheme continuation.scm
完整延续通常会捕获从当前位置到程序顶层的控制上下文，因此成本和行为都比异常跳转或普通回调更复杂。摘要中提到的界定延续仍属于后续计划；它只捕获到指定边界，适合协程、回溯和效果处理等更局部的控制流，但不能直接假设当前版本已经支持。
扁平 box 如何服务闭包变量
闭包只读取外层变量时，可以复制值或引用稳定的槽位；一旦内层 lambda 使用 set! 修改外层变量，多个闭包就必须看到同一个可变位置。常见做法是把该变量提升为 box：调用帧和闭包都保存 box 引用，实际值放在 box 中。
所谓扁平 box，可以理解为闭包直接定位最终的可变单元，而不是经过一串逐层链接的环境或 box 链。以下程序适合验证共享捕获位置是否正确：
;; closure-box.scm
(define (make-counter)
(let ((n 0))
(lambda ()
(set! n (+ n 1))
n)))
(define counter (make-counter))
(display (counter))
(newline)
(display (counter))
(newline)
(display (counter))
(newline)
它应依次输出 1、2、3。实现层面还需要处理两个关键问题：未被捕获的局部变量不应无条件装箱；一个变量一旦被多个闭包共享，也不能意外生成彼此独立的 box。
采用与评估清单
如果要把 dummyscheme 用于语言实验、嵌入式脚本或虚拟机研究，可以从下面几项开始验证：
- 用深度尾递归测试调用帧是否保持有界；
- 用同一个 continuation 多次恢复，检查 multi-shot 语义；
- 在恢复延续前后修改闭包变量，观察 copy-on-write 与 box 是否正确协作；
- 使用 R5RS 测试集检查数字、列表、端口、宏和错误行为，而不只测试语法解析；
- 对延续捕获频率、共享帧写入比例和闭包数量做基准测试；
- 在依赖界定延续之前确认当前版本能力，因为它仍被描述为计划支持。
寄存器字节码可以让执行路径紧凑，尾调用保证 Scheme 程序不会被宿主栈限制，copy-on-write 调用帧则为多次延续提供实现基础。三者结合很有研究价值，但性能最终取决于帧复制粒度、寄存器布局、垃圾回收以及 box 分配策略，不能只从架构名称推断。