1. 先搞清楚一件事Racket 凭什么说自己是“可编程的编程语言”“可编程的编程语言”这句话我第一次听是在导师工位上。他随手甩给我一句你去看一个叫 Racket 的东西它号称“可编程的编程语言”。当时我以为是学术圈自嗨的话术直到大三那个周末我在 DrRacket 里写了人生第一段宏代码才真正意识到这句话一点没夸张——你在 Racket 里写程序只是最表层的能力你真正可以做的是“设计一门语言”然后让同事用你设计的语言去写代码。后来我又在几个小工具项目里拿它做了配置 DSL、任务脚本语言越用越觉得这条路值得展开讲清楚。1.1 从 PLT Scheme 到 Racket 的来龙去脉Racket 不是这两年冒出来的网红语言它的根在学术界。前身叫 PLT Scheme1995 年前后由美国东北大学的 PLT 团队启动目标是做程序设计语言的研究和教学。团队后来写了《How to Design Programs》这本教材在美国多所大学的计算机入门课里使用那会儿它的主要用户就是学生和研究者。2010 年项目正式从 PLT Scheme 更名为 Racket。原因是它演进得已经明显偏离标准 Scheme 了模块系统、契约系统、类型系统等一票自成一体的设计让它不再适合继续挂着“Scheme”的招牌。这个更名等于官宣了一件事Racket 的目标不是做一个“兼容某某标准的方言”而是做一门“可以被用户自己继续扩展的语言”。有一点值得注意Racket 和 Python、Java 这类工业主流语言的路线一开始就是反的。后者追求的是在复杂业务里好用、可维护、生态大Racket 追求的是“我可以被扩展成另一种语言”。所以它的核心价值不是自带标准库有多全而是提供了一套让语言“自己长出语法、自己定义语义”的机制。理解了这一点你再看 Racket 的文档时就不会被它那种“语言工厂”气质搞懵了。1.2 “可编程”不是形容词而是一种方法论“可编程编程语言”这个说法绕嘴翻译成人话就两句普通语言是“你写程序给它执行”Racket 是“你可以一边写程序一边把写程序需要的语言工具也造出来”。后者才是它真正的杀手锏。拿办公软件里的“宏录制”来类比。Excel 的宏能录一段操作再回放这已经很方便了但 Racket 的宏激进得多。它不是在固定语法里加一点便捷按钮而是允许你创建全新的语法来刻画你的业务逻辑。相当于你不仅有螺丝刀还能按自己的工位需求造一把专用螺丝刀造完之后作为车间标准工具分发给同事用。两个场景的体验差在抽象层级上一个是“用别人设计的语言组织代码”一个是“语言本身由你重新定义后再组织代码”。这些东西具体对谁有用我自己的判断是三类人。第一正在做编译器、解释器、领域特定语言DSL相关工作的Racket 几乎是为这个场景量身定做的。第二被业务里大量重复样板代码折磨、想从根上消除重复的工程团队。第三想深入理解“编程语言是怎么被设计出来”的学生和爱好者。需要说明的是Racket 不适合用来写高并发服务或者嵌入式驱动那不是它的战场。但在“怎么设计一门好语言”这件事上我还没见过比它更顺手的工具。2. 核心武器宏系统与语言导向编程2.1 宏和函数到底差在哪绝大多数语言里函数就是代码复用的天花板了。Python 里写装饰器Java 里做注解处理器都算向“元编程”靠拢但操作范围依然被既有语法框死了。Racket 的宏不一样它是把“语法本身”当成数据来处理的。先看一段地地道道的 Racket 代码#lang racket (define (factorial n) (if ( n 0) 1 (* n (factorial (- n 1))))) (displayln (factorial 10))这段源码从另一个角度看就是一棵“数据树”最外层括号里装着符号 define、符号 factorial、以及后面那串嵌套结构。Racket 的 reader 会先把源码读成一棵树所有节点都是括号和符号宏就在这棵树上做模式匹配和重写。宏可以在编译期把自己的输入语法替换成另一段语法替换过程中还能调用其他宏、递归、生成新代码片段。函数做不到这一点因为函数参数必须先求值为“值”才能传进去它永远碰不到“源码”。而宏的输入就是源码本身。这正是宏能实现函数实现不了的东西的原因——例如定义一种全新的控制结构。2.2 用宏做一个小型语法改造自定义 when 结构很多语言没有 when 这种“连写多句”的便利结构但 Racket 里有。不过为了展示宏的能力我假装语言里没有 when自己实现一个#lang racket (define-syntax simple-when (syntax-rules () [(_ condition body ...) (if condition (begin body ...) (void))])) (let ([score 85]) (simple-when ( score 60) (displayln 及格了) (displayln 继续加油)))syntax-rules 就是在描述两件事这个宏接受什么形状的语法以及它应被替换成什么。... 表示“任意多个表达式”。运行之后右侧输出两行提示。关键是simple-when 看起来、用起来都和语言自带关键字没有区别但它是我在源码层定义的。程序阅读者看到的只有 simple-when是 if 还是 begin 根本不暴露整个阅读层次就被抬高了一级。这就是“可编程”的现场体验。你不再只是给 Racket 写程序你在给 Racket 写“程序该长什么样的规则”。2.3 语言导向编程一劳永逸的“定义语言”路线宏是颗粒度很小的语言改造工具Racket 真正的大招是“模块化语言”。每个 Racket 文件第一行都是 #lang#lang racket这行声明了这个文件将用什么语言来解析与编译。你也可以写上#lang my-business-language然后这个文件里就可以完全不是你熟悉的 Racket 语法而是你定义的那门语言的语法。这个能力来源于 Racket 的模块系统每个模块可以同时指定自己的 reader负责把文本读成语法树和展开器负责把语法树编译成可执行代码。你设计的业务 DSL 以模块语言的形式发布后同事只需要在文件头写一行 #lang就能直接用你的语法写业务代码。我把这个过程叫做“语言层复用”它比“代码层复用”高一个抽象级。代码层复用的场景是每次写代码时调用一个封装好的函数语言层复用是直接让代码本身的写法变掉把容易写错、容易漏掉的模板结构直接锁死在语法层。去年我帮一个内部配置系统设计过一个只有三四个关键字的配置语言团队配置文件从两百行 XML 缩到四十行左右而且字段几乎不会写错——因为语法里压根只存在那几个合法字段。3. 实操从安装到写出自己的第一个 DSL3.1 环境搭建与 DrRacket 快速上手动手永远比看概念有效。先到 racket-lang.org 下载对应安装包。Windows 直接点 exemacOS 用 pkgLinux 上可以用发行版的包管理器# Ubuntu / Debian sudo apt install racket # macOS 使用 Homebrew brew install --cask racket装完会得到两个关键东西racket 命令行工具和 DrRacket IDE。我对新手的建议是前期只用 DrRacket。它的界面是左编辑区、右交互区点一次 Run 就把左侧代码加载进右侧环境。基于括号的语言非常吃“写一段跑一段”的即时反馈DrRacket 这种交互方式极大减少了“写三百行才跑一次、然后不知道错在哪”的挫败感。新建文件先写一行#lang racket然后输入基本表达式比如 ( 1 2 3)点运行右侧输出 6。到这里环境就通了。有个细节很多人第一次会卡住文件必须包含 #lang 开头否则 Racket 不知道用哪个阅读器来解析你的文件直接给你 read-error。3.2 五步实现一个“命令式小语言”空谈概念没用我拿一个真实的小项目来演示。背景是内部工具需要一个“任务队列”描述语言动作只有三种执行命令、等待若干秒、失败重试。需求方是基本不写代码的同事我想让他们能像写清单一样填写任务。第一步定下语法。我希望目标文件长这样task start run echo-hello wait 2s run echo-world retry 3第二步解析文本。Racket 可以自定义底层 reader 实现真正的语法改造但第一次做时我建议走一条务实的路把整个文件读成文本按read-line逐行解析成结构化表示。第三步把每行翻译成可执行的数据按行解析写一个 match 分支(define (parse-line line) (define parts (string-split line)) (match parts [(list run cmd) (run-command ,cmd)] [(list wait sec) (wait-seconds ,(string-number sec))] [(list retry n) (set-retry-count ,(string-number n))] [_ (error unknown syntax: line)]))第四步写解释器循环。也就是把 parse-line 得出来的表示逐条丢给一个 evaluate-line 执行实现一个典型的“词法解析 - 结构化数据 - 求值”解释器模式。前两步做完骨架就稳了后面加新命令只是加一个 match 分支。第五步封装成 #lang。把这套解析与执行逻辑放进一个模块声明它的 reader 和 expander然后新建文件头写 #lang task-language正文直接写任务。这一步是目前 Racket 里最让我兴奋的部分但初学者不急着一步到位。我很实际地说动手设计 DSL 的头一两个小时会花在语法上但解析和执行骨架一旦稳定扩展速度会飞快。这也是“可编程编程语言”带来的真实开发体验你在用“自己正在设计”的语言写东西而不是弯腰迁就别人已经定死的约束。3.3 模块化封装把 DSL 变成一等公民真正封装成可用的 #lang 需要两个模块reader 模块负责从字符流里读出语法对象language 模块负责提供展开器和运行环境。第一次接触时这些概念容易发懵我建议你别急着写 reader先用宏在 #lang racket 之下把自己的“伪语法”包出来。前面那个 simple-when 本质上已经是一种语言扩展了你在文件里定义一串宏就相当于在搭建“你的 Racket”。等手感熟了再啃官方文档 Creating Languages 那节。我第一次跟做时犯的错误是太想一步到位折腾了三天才跑通一个 Hello 级别的新语言后来摆正心态把“让一个新的 #lang 文件成功打印一行字”当作第一个里程碑一切就顺了。封装时还可以考虑设置 PLTCOLLECTS 环境变量把自定义语言模块放到 collects 目录这样整个项目都能用同一个 #lang 引用团队协作也方便。4. 常见坑与排错实录4.1 括号地狱与括号匹配技巧Racket 里最高频的错误就是括号不匹配报错典型是 “read: expected a )” 或者干脆 “unexpected )”。我踩了无数次之后总结出三条实战经验。第一写码时别裸敲括号盯住 DrRacket 的自动补全和成对高亮。第二养成“缩进就是结构”的习惯。Racket 的缩进规则与括号结构严格对应写乱之后按重排快捷键整理肉眼检查缩进层级就能定位到缺括号的位置。第三报错时不要逐个数括号而是想“当前括号内表达式是否完整”。多数不匹配的根源是某个 if 或 lambda 少了一个右括号导致后续所有代码都串位到这个括号里这时候数再多括号也没用从报错位置往上找最近没闭合的结构才是最快的。4.2 宏展开的意外与卫生宏写宏的经典话题是“变量捕获”。拿 C 语言常见的宏陷阱来说如果宏内部开了临时变量 tmp而调用处的代码也写了一个 tmp展开后就可能悄悄互相覆盖这是个很难排查的 bug。Racket 的 define-syntax-rule 和 syntax-rules 默认都是“卫生宏”编译器会自动把宏内部的临时变量改写成不会和用户代码冲突的名字所以经典捕获问题在 Racket 里基本不会发生。但别高兴太早。当你用 define-syntax 配合 syntax-case 写复杂宏时会遇到另一类问题最常见的报错是 “unbound identifier” 或 “identifier reference is not allowed”。这通常意味着宏展开后引用了一个在你指定的上下文里不存在的标识符。处理这类问题的工具是 DrRacket 的 Macro Stepper它能把宏一步又一步地展开给你看比对着文档猜原因快得多。我的实操心得是复杂宏里的临时变量一律起带前缀的名字比如 tmp/swap-each命名越独特越好宁丑勿险。4.3 运行时错误与模块加载问题速查下面这张表是我在真实项目里踩过的坑建议收藏现象原因解决办法文件第一行没有 #lang报 read-error编译器不知道用哪个 reader文件第一行写上 #lang racket报 contract violation看起来只是“参数不对”实参与形参类型不匹配比如传了 list 而函数期望 vector用 typecheck 或逐步打印参数定位具体类型自定义 #lang 加载失败报 module: no such file语言模块不在收集路径里设置 PLTCOLLECTS 环境变量或把模块放进标准 collects 目录同一个名字 define 多次报 multiple definitions同一作用域内重复定义需要覆盖时改用局部 let 遮蔽保持顶层干净排错思路其实有一条主线先分清问题发生在哪个阶段。Racket 编译路径是“读入 - 展开 - 编译 - 运行”很多让人摸不着头脑的报错是把展开阶段和运行阶段的错误混在一起看自然就乱了。先看报错发生在哪一步再对症下药效率高得多。5. 学习路线与我的几条心得体会5.1 给初学者的四周围路线如果你以前没碰过 Lisp 系语言我建议按四周来推进。第一周装好 DrRacket跟着官方 Quick Introduction 把数字、字符串、列表、函数定义这些基础混熟先别碰宏把 S 表达式用手感打出来。第二周做一个小练习比如写一个把中缀表达式转后缀的计算器体会一次“代码就是数据”的感觉。第三周开始读 Matthew Butterick 的《Beautiful Racket》这本书目前可以在线免费读专门讲怎么用 Racket 造语言从简单宏一路走到完整 DSL。第四周选一个小场景做一个 #lang 模块化语言哪怕只是配置文件解析器也足以把 syntax-case 和 reader 的文档啃透了。正在做语言设计相关工作的建议直接读官方文档 “Creating Languages” 专题再回头翻 SICP 里关于元语言抽象的章节。SICP 是几十年前的书但里面“用语言去解决问题”的思想完全不过时。5.2 我踩过几次坑之后的几条心得第一次用 Racket 做项目时我犯的最大错误是一上来就想造一个“多功能、可扩展、通用”的语言结果 syntax、reader、module 三块一起上两周才勉强把骨架搭稳。后来把目标缩到“只解决我的配置问题”设计成只有三个命令的迷你语言一周就上线了。所以第一条心得是DSL 的范围一定要小覆盖业务场景的 80% 就停手剩下的边角料让用户直接用底层 Racket 写就行。第二条心得和具体工具无关。凡是出现大段结构几乎一样、只是参数不同的代码就说明这个语言层面缺一个抽象。与其复制粘贴更多代码不如把这段结构变成语言的一部分。这个思路放到 Python、Java 里也说得通虽然不能改语法但装饰器、注解和代码生成器同样可以在一定程度上完成这种“语法层抽离”。第三条是教学价值。说实话业务项目不会因为引进了 Racket 就一夜起飞但花时间学它会实打实改变你对自己常用语言的看法。你会慢慢注意到语法糖背后其实是结构编译器不是黑魔法而是一套可以被设计、被替换的规则。我在写 Python 装饰器时明显比学 Racket 之前有底气就是因为理解了宏与展开之后清楚一个装饰器到底工作在哪个抽象层。Racket 不是一门学完就能让简历熠熠生辉的热门框架它更像是编程世界里的“语言工厂”。拿几个周末亲手设计一个小语言体验一次“代码长成我定的样子”真的会改变你写代码的思路。这门语言适合慢慢玩适合深夜自己折腾一个 DSL适合你带着一个问题来然后带走一门语言走。