构建计算器，第 3 部分将 Scala 解析器组合子和 case 类结合起来(scala代码学习第十天)
欢迎勇于探索的读者回到我们的系列文章中！本月继续探索 Scala 的语言和库支持，我们将改造一下计算器 DSL 并最终 “完成它”。DSL 本身有点简单 — 一个简单的计算器，目前为止只支持 4 个基本数学运算符。但要记住，我们的目标是创建一些可扩展的、灵活的对象，并且以后可以轻松增强它们以支持新的功能。

继续上次的讨论……

说明一下，目前我们的 DSL 有点零乱。我们有一个抽象语法树（Abstract Syntax Tree ），它由大量 case 类组成……


清单 1. 后端（AST）

 


……但在进行解析时，由于解析器组合子当前被编写为返回 Parser[Any] 类型，所以会生成 String 和 List 集合，实际上应该让解析器返回它需要的任意类型（我们可以看到，此时是一个 String 和 List 集合）。

要让 DSL 成功，解析器需要返回 AST 中的对象，以便在解析完成时，执行引擎可以捕获该树并对它执行 evaluate()。对于该前端，我们需要更改解析器组合子实现，以便在解析期间生成不同的对象。

清理语法

对解析器做的第一个更改是修改其中一个语法。在原来的解析器中，可以接受像 “5 + 5 + 5” 这样的表达式，因为语法中为表达式（expr）和术语（term）定义了 rep() 组合子。但如果考虑扩展，这可能会引起一些关联性和操作符优先级问题。以后的运算可能会要求使用括号来显式给出优先级，以避免这类问题。因此第一个更改是将语法改为要求在所有表达式中加 “()”。

回想一下，这应该是我一开始就需要做的事情；事实上，放宽限制通常比在以后添加限制容易（如果最后不需要这些限制），但是解决运算符优先级和关联性问题比这要困难得多。如果您不清楚运算符的优先级和关联性；那么让我大致概述一下我们所处的环境将有多复杂。考虑 Java 语言本身和它支持的各种运算符（如 Java 语言规范中所示）或一些关联性难题（来自 Bloch 和 Gafter 提供的 Java Puzzlers），您将发现情况不容乐观。

因此，我们需要逐步解决问题。首先是再次测试语法： 


清单 4. 采用括号

 


我已经将旧的解析器重命名为 OldAnyParser，添加左边的部分是为了便于比较；新的语法由 AnyParser 给出；注意它将 expr 定义为 term + term、term - term，或者一个独立的 term，等等。另一个大的变化是 factor 的定义，现在它使用另一种组合子 ~> 和 <~ 在遇到 ( 和 ) 字符时有效地抛出它们。

因为这只是一个临时步骤，所以我不打算创建一系列单元测试来查看各种可能性。不过我仍然想确保该语法的解析结果符合预期，所以我在这里编写一个不是很正式的测试：


清单 5. 测试解析器的非正式测试

 


请记住，这纯粹是出于教学目的（也许有人会说我不想为产品代码编写测试，但我确实没有在编写产品代码，所以我不需要编写正式的测试。这只是为了方便教学）。但是，运行这个测试后，得到的许多结果与标准单元测试结果文件相符，表明没有括号的表达式（5 + 5 + 5）执行失败，而有括号的表达式则会执行成功。真是不可思议！

不要忘了给解析测试加上注释。更好的方法是将该测试完全删除。这是一个临时编写的测试，而且我们都知道，真正的 Jedi 只在研究或防御时使用这些源代码，而不在这种情况中使用。

清理语法

现在我们需要再次更改各种组合子的定义。回顾一下上一篇文章，expr、term 和 factor 函数中的每一个实际上都是 BNF 语句，但注意每一个函数返回的都是一个解析器泛型，参数为 Any（Scala 类型系统中一个基本的超类型，从其名称就可以知道它的作用：指示可以包含任何对象的潜在类型或引用）；这表明组合子可以根据需要返回任意类型。我们已经看到，在默认情况下，解析器可以返回一个 String，也可以返回一个 List（如果您还不信的话，可以在运行的测试中加入临时测试。这也会看到同样的结果）。

要将它更改为生成 case 类 AST 层次结构的实例（Expr 对象），组合子的返回类型必须更改为 Parser[Expr]。如果让它自行更改，编译将会失败；这三个组合子知道如何获取 String，但不知道如何根据解析的内容生成 Expr 对象。为此，我们使用了另一个组合子，即 ^^ 组合子，它以一个匿名函数为参数，将解析的结果作为一个参数传递给该匿名函数。

如果您和许多 Java 开发人员一样，那么就要花一点时间进行解析，让我们查看一下实际效果：


清单 6. 产品组合子

 


^^ 组合子接收一个匿名函数，其解析结果（例如，假设输入的是 5 + 5，那么解析结果将是 ((5~+)~5)）将会被单独传递并得到一个对象 — 在本例中，是一个适当类型的 BinaryObject。请再次注意模式匹配的强大功能；我将表达式的左边部分与 lhs 实例绑定在一起，将 + 部分与（未使用的）plus 实例绑定在一起，该表达式的右边则与 rhs 绑定，然后我分别使用 lhs 和 rhs 填充 BinaryOp 构造函数的左边和右边。

现在运行代码（记得注释掉临时测试），单元测试集会再次产生所有正确的结果：我们以前尝试的各种表达式不会再失败，因为现在解析器生成了派生 Expr 对象。前面已经说过，不进一步测试解析器是不负责任的，所以让我们添加更多的测试（包括我之前在解析器中使用的非正式测试）：


清单 7. 测试解析器（这次是正式的）

 


当然，我们需要对这个解析器进行一些测试……


清单 13. 再求平方

package com.tedneward.calcdsl.test{  class CalcTest  {    // ...        @Test def square1 =      assertEquals(Calc.evaluate("2 ^ 2"), 4.0)  }}
 


成功啦！