1.5使用代码生成
在迄今为止的讨论中,要处理DSL,组装“语义模型”(第11章),然后执行语义模型,提供我们希望从控制器得到的行为。在语言圈子里,这种方式称为解释(interpretation)。在解释文本时,会先解析文本,然后程序立刻产生结果。(在软件圈子里,解释是个棘手的词语,它承载了太多含义,然而,这里严格限制为立即执行的形式。)
在语言领域里,与解释相对的是编译。在编译(compilation)时,先解析程序文本,产生中间输出,然后单独处理输出,提供预期行为。在DSL的上下文里,编译方式通常指的是代码生成(code generation)。
用状态机解释这个差异有点困难,因此,换用另外一个小例子。想象一下,有某种规则判定人们是否符合某种资格,也许是为了满足保险资格。比如,如图1-5所示,一个规则是年龄在21~40岁。这个规则可以是一个DSL,检查像我这样的候选人是否具备资格。
如果解释,资格判定处理器会解析规则,在执行时加载语义模型,也许是启动时加载。当检查某个候选人时,它会对 这个候选人运行语义模型,获得一个结果。
如图1-6所示,在编译的情况下,解析器会加载语义模型,把它当做资格-判定处理器构建过程的一部分。在构建期间,DSL处理器会产生一些代码,这些代码经过编译、打包,并且纳入资格判定处理器,也可能当做某种共享库。然后,运行这段中间代码,对候选人进行评估。
例子里的状态机使用的是解释:在运行时解析配置代码,并组成语义模型。但其实也可以生成一些代码,以免在烤面包机里出现解析器和模型代码。
代码生成通常很笨拙,因为它常常需要进行额外的编译步骤。为了构建程序,首先需要编译状态框架和解析器,其次运行解析器,为格兰特小姐的控制器生成源代码,然后编译生成的代码。这样做,构建过程就变得复杂许多。
然而,代码生成的一个优势在于,编写解析器和生成代码可以用不同的语言。在这个情况下,如果生成代码用的是动态语言,比如JavaScript或是JRuby,第二个编译步骤就可以省略。
如果所用DSL的语言平台缺乏支持DSL的工具,代码生成的作用也会凸显出来。比如,我们不得不在一些老式的烤面包机上运行这个安全系统,而它们又只能理解编译过的C,那我们可以这样做,实现一个代码生成器,使用组装的语义模型作为输入,产生可以编译为运行在老式烤面包机的C代码。在最近做的一些项目里,我们曾为MathCAD、SQL和 COBOL等生成代码。
许多与DSL相关的作品都会关注代码生成,更有甚者,把代码生成当做这个活动的主要目标。随之而来的就是,涌现了一大批文章和书籍,赞美代码生成的优点。然而,在我看来,代码生成仅仅是一种实现机制,实际上,大多数情况下 都用不到。当然,有很多情况必须要用代码生成,但的确有很多情况确实用不到。
许多人用了代码生成之后,就舍弃了语义模型,他们在解析输入文本之后,就直接产生生成的代码。虽然对于使用代码生成的DSL而言,这也是一种常见的方式,但除非是最简单的情况,否则不推荐任何人这么做。语义模型的存在,可以将解析、执行语义以及代码生成分开。整个活动会因为这个划分变得简单许多。它也给了我们改变自己想法的机会; 比如,无须修改代码生成的例程就可以把内部DSL改成外部DSL。类似地,可以很容易产生多种输出,而无须担心解析器变得复杂。就同一种语义模型而言,既可以用解释模型,也可以选择代码生成。
因此,在本书的大部分内容里,假设存在一个语义模型,它是DSL工作的核心。
常见的代码生成风格有两种。第一种是“第一遍”代码,这种代码是一个模板,之后要手动修改。第二种是确保生成代码绝对不需要手动修改,也许还要排除调试期间所加的追踪信息。我几乎总是倾向于后者,因为这样可以更自由地重 新生成代码。对DSL而言,这点尤其正确,因为我们希望对于DSL所定义的逻辑而言,它是主要的表现形式。这意味着,无论何时,要修改行为,必须能够轻松修改DSL。因此,我们必须保证,任何生成的代码都没有经过手动编辑,虽然它可以调用手写的代码,或者由手写的代码调用。