我对Macros非常感兴趣,刚刚开始了解它的真正力量.请帮我收集宏系统的一些很好的用法.
到目前为止,我有这些结构:
模式匹配:
安德鲁赖特和布鲁斯杜巴.Scheme的模式匹配,1995
Prolog精神的关系:
Dorai Sitaram.在schelog中编程. http://www.ccs.neu.edu/home/dorai/schelog/schelog.html
Daniel P. Friedman,William E. Byrd和Oleg Kiselyov.理性的计划者.麻省理工学院出版社,2005年7月
Matthias Felleisen.将Prolog音译为方案.技术报告182,印第安纳大学,1985年.
可扩展循环结构:
塞巴斯蒂安·埃格纳 方案中的热切理解:SRFI-42的设计."计划与功能规划研讨会",2005年9月第13-26页.
奥林颤抖.循环的解剖:范围和控制的故事.在国际功能规划会议,第2-14页,2005年.
班级系统:
PLT.PLT MzLib:图书馆手册.技术报告PLT-TR2006-4-v352,PLT方案公司,2006年 http://www.plt-scheme.org/techreports/
Eli Barzilay.骗取. http://www.barzilay.org/Swindle.
组件系统:
Ryan Culpepper,Scott Owens和Matthew Flatt.组件接口中的语法抽象.在生成编程和组件工程国际会议,第373-388页,2005年
软件合同检查
Matthew Flatt和Matthias Felleisen.单位:用于HOT语言的酷模块在ACM SIGPLAN会议上编程语言设计和实现,第236-248页,1998年
Oscar Waddell和R. Kent Dybvig.扩展句法抽象的范围.在编程语言原理研讨会上,第203-215页,第199页
解析器生成器
Scott Owens,Matthew Flatt,Olin Shivers和Benjamin McMullan.Scheme中的Lexer和解析器生成器.关于计划和功能规划研讨会,2004年9月第41-52页.
工程语义工具:
Matthias Felleisen,Robert Bruce Findler和Matthew Flatt.PLT Redex的语义工程.MIT出版社,2009年8月.
编译器转换的规范:
Dipanwita Sarkar,Oscar Waddell和R. Kent Dybvig.用于编译器教育的纳米框架.功能规划期刊,15(5):653-667,2005年9月.教育明珠.
新的执行形式
具有可序列化延续的Servlet Greg Pettyjohn,John Clements,Joe Marshall,Shriram Krishnamurthi和Matthias Felleisen.广义堆栈检查的延续.在国际功能规划会议上,第216-227页,2005年.
定理证明系统
塞巴斯蒂安·埃格纳 方案中的热切理解:SRFI-42的设计.在计划与功能规划研讨会上,2005年9月第13-26页.
基类的扩展与类型
Sam Tobin-Hochstadt和Matthias Felleisen.打字方案的设计和实施.在编程语言原理研讨会上,第395-406页,2008年.
怠惰
Eli Barzilay和John Clements.没有辛勤工作的懒惰:将懒惰和严格的语言结合起来进行教学.在教育中的功能和声明性编程中,第9-13页,2005年. …
在我完全理解如此强大的lisp宏的过程中,我想到了一个问题.我知道关于宏的一条黄金法则是"当一个函数完成工作时不要使用宏".然而阅读第9章 - 实践:构建单元测试框架 - 从实用Common Lisp I一书中介绍了下面的宏,其目的是消除测试用例表达式的重复,伴随着结果错误标记的风险.
;; Function defintion.
(defun report-result (result form)
(format t "~:[FAIL~;pass~] ... ~a~%" result form))
;; Macro Definition
(defmacro check (form)
`(report-result ,form ',form))
好的,我理解它的目的,但我可以使用函数而不是宏来完成它,例如:
(setf unevaluated.form '(= 2 (+ 2 3)))
(defun my-func (unevaluated.form)
(report-result (eval unevaluated.form) unevaluated.form))
在我不断学习 lisp 的过程中，我遇到了一个概念问题。这有点类似于这里的问题，但也许在主题上适合说我的问题是一个抽象级别。
通常，什么时候应该创建宏而不是函数？在我看来，也许天真地，很少有情况需要创建宏而不是函数，并且在大多数剩余情况下，函数通常就足够了。在这些其余情况中，宏的主要附加价值似乎是语法的清晰度。如果是这样的话，那么对于个体程序员来说，似乎不仅是选择使用宏的决定，而且其结构的设计也可能从根本上是特殊的。
这是错误的吗？是否有一般情况概述何时使用宏而不是函数？我说的对吗，语言需要宏的情况通常很少？最后，是否存在宏所期望的通用语法形式，或者它们通常被程序员用作简写？