在过去的几年里,我一直从事于各种领域定义语言的设计,包含 unflow、guarding、datum、forming 等。在我刚入门这个领域的时候,我从《领域特定语言》、《编程语言实现模式》 等,一直研究到龙书等。我渐渐掌握了领域特定语言设计的一些技巧,也能快速(相对于过去)设计出一个领域特定语言。
所以,我在想我应该总结一下相关的套路。这样一来,也可以在未来验证现在的思路是否正确:
领域特定语言(英語:domain-specific language、DSL)指的是专注于某个应用程序领域的计算机语言。
本文所写的皆是外部 DSL,即『不同于应用系统主要使用语言』的语言。创建外部 DSL 和创建一种通用目的的编程语言的过程是相似的,它可以是编译型或者解释型的。
通用目的编程语言的源代码和外部 DSL 的源代码之间的主要区别在于,经过编译的 DSL 通常不会直接产生可执行的程序(但是它确实可以)。大多数情况下,外部 DSL 可以转换为一种与核心应用程序的操作环境相兼容的资源,也可以转换为用于构建核心应用的通用目的编程语言。—— Vaughn Vernon
简单场景下的领域特定语言,只是将特定的源码转换为特定的数据结构。如 JSON 便是一种 DSL,在 Java 语言里,需要将它转换为对应的数据类。复杂场景下的领域特定语言,可以直接编译为可执行程序。
外部 DSL 的麻烦点在于:
当然了,它的优点也很明显:
更多的信息,建议去阅读《领域特定语言》一书。
领域特定语言嘛,从需求上就是对于业务呈现的简化。根据不同的呈现模式,去解析源码,得到我们所需要的数据结构。
如下是常见的的领域特定语言的使用模式 [wiki_dsl]:
可以参见维基百科,我就不再去翻译了。
[wikidsl]: https://en.wikipedia.org/wiki/Domain-specificlanguage
从通用语言的编译过程来看:
步骤 1~4,对于通用语言和领域特定语言来说都是极为类似的。唯一拥有区别的是这个中间表示形式,对于领域特定语言来说,我们场景的原因,这里往往是我们所需要的数据结构。
当然了,从某种意义上来说,AST(抽象语法树)也是一种数据结构,只不过它是一种中间的数据结构。所以,有时候在设计的时候,我就偷懒直接输出中间表示了。
这个环节的过程,实现上和 DDD(领域驱动设计)里的提炼问题域以获取领域知识是颇为相似的。同样的这个过程中,通过与领域专家的协作,我们才能获得更好的领域特定语言。
用例,或译使用案例、用况,是软件工程或系统工程中对系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。
在进行领域驱动设计协作时,我们需要与领域专家理解用户在这个过程中,进行的一系列操作,以提炼我们所需要的统一语言。而其中的用例能描述达到目标所需的步骤,包含用户和系统之间的交互。
在创建领域特定语言的时候,这个过程对于我们来说,也是类似的:与领域专家一起协作,从用例开始提炼。它也可以直接由现有的代码中提炼而来。
对于已有系统来说,用例可以由:
在 ArchUnit 中提取架构规划上的设计便是:
classes().that().resideInAPackage("..foo..")
.should().onlyHaveDependentClassesThat().resideInAnyPackage("..source.one..", "..foo..")
对应的,我们在 Guarding 的设计是:
class(resideIn "..foo..") dependent package(resideIn ["..source.one..", "..foo.."])
在 Guarding 中设计的是针对主流的编程语言,所以在语法上会尽量与编程语言无关。
在获得了用例作为输入条件之后,我们就需要从中提取一些关键信息,如关键字、值、属性等等。
如下是我在设计 Guarding DSL 时,从 ArchUnit 提取的一小部分关键信息:
package:
dependOn
class:
implement
annotation
annotatedWith
expression:
and
or
not
equals
only
接着,我们就可以依据这些信息,展开它们的关联设计,进而设计我们的语法。
在设计领域特定语言时,我们主要以实现领域中的用例作为目标:
领域特定语言,所针对的是特定领域。在特定的领域里,都会使用特定的词汇来描述相关之间的关系。这个关系,便是我们设计语法的一个关键。
如在 Java 语言里,使用: implement
、 extends
来表示两个类之间的关系。而为了表示包之间的关系,则会有: dependent
、 resideIn
等等的关系。
实现用例并不是一个复杂的过程,只是要符合人类的思维习惯,并尽可能地简化设计。不过,觉得注意的是,我们应该留下一些证据来告诉未来的自己:我们当时是为什么考虑的。
在设计 DSL 时,我往往会创建一个 sample
文件,以记录过程中,对于不同的要素的思索。如我在设计 Guarding DSL 里,使用了一个 0.0.1.sample
文本文件,来描述早期版本的语法示例:
# 正则表达式
package(match("^/app")) endsWith "Connection";
package("..home..")::name should not contains(matching(""));
# 简化的比较
class::name.len should < 20;
通过一些注释来让自己优化设计。
这一部分的过程,和我们学习编译原理时基本是一致的。不过呢,在编写领域特定语言的时候,我们一般会使用解析器生成器,而不是手写解析器。
设计领域特定语言的时候,在设计语法上的拘束不会像通用语言那么多。所以,自由设计的范围就大一点,有些内容也不一定需要像编程语言麻烦。诸如于:
PS:使用类似于编程语言的写法,对于写 DSL 的非编程人士来说可能会变成一种困扰。
经典的 Lex & Yacc 是你可以考虑的范围,在不同的语言里也有一些相似的实现。
对于我来说,以下是我常用的一些解析器生成器。
我还是比较习惯用 Antlr,支持的语言较多。我与同事以及开源社区的小伙伴们,在下面的项目中都使用过 Antlr:
从使用上它们之间的差距并不大,但是都需要学习成本。
最后,让我们来谈谈一些有意思的东西,虽说是演进吧,但是,和设计暂时没有太大的关系。
经我大量发现,TDD 是非常适合于编程语言的开发与设计。需求是未知的,易于发生变化的,还需要覆盖足够全的场景。
从实践的层面上来说,主要是有两种:
原先这部分的标题是,向下兼容。但是,我一直觉得向下兼容不是一个好主意。所以呢,我就想了想把在其它领域的经验搬了过来,于是呢,内容就变成了自动化语言迁移。
在关于版本的迁移上,我觉得 Angular 语言上关于版本的自动化迁移,是值得我们去借鉴的。当然了,采用这种设计的成本非常高,我们需要有一个专门的团队,使用工具自动化分析旧的系统,并使用工具来自动修改旧的代码。
文中相关 DSL 链接(欢迎加入 Inherd 一起编写 DSL):
Unflow: https://github.com/inherd/unflow
Guarding: https://github.com/inherd/guarding
Forming: https://github.com/inherd/forming