nis*_*s84 0 compiler-construction scheme interpreter language-design
将'cond'改为特殊形式而不是语法糖会有什么样的优势?
在一篇有关Scheme(Lambda the Ultimate Declarative,§1.2)的具有里程碑意义的论文中,斯蒂尔写道:
然而,无可否认,IF-THEN-ELSE似乎是最容易表达所有其他条件的最简单的条件控制操作符.
然后他在§4.1中写道:
虽然我建议只构造编译器的低级部分,加上必要的宏来提供标准的LISP功能,如COND和PROG,但可以很容易地想象构建一个ALGOL编译器,例如,提供一个解析器和必要的宏.作为前端.
这斯蒂尔试图在这等多篇论文,其中包括他的点硕士论文 Rabbit的编译器,是if
比简单cond
,一般它更有意义的宏观扩展库的语法cond
和case
到像简单的语法至关重要if
.这样您就可以保持编译器需要简单理解的输入语言,这样可以更容易地推理,实现和优化.这一切都符合我猜想的极简主义设计.
从表面上看,人们可能会想到cond
可以更优化地编译(想想切换表).与没有实际数据或证据的"优化"的所有问题一样,这可能会成为一个不成熟的结论,事实上我不会打赌我的钱是真的.
因此,为了回答您的问题,我认为cond
在Scheme中制作基本语法而不是宏时没有真正或持久的优势.或者,如果有优势,至少会有一些缺点,比如更复杂的评估者.