使用 Raku 正则表达式和 Grammars 进行解析

正则表达式的理论基础来自于计算机科学, 它描述了一种形式语言和自动机或形式机的层次结构, 可以识别这些语言。这些语言中, 最有限的一种语言被称为正则语言。^[1]决定特定字符串是否使用常规语言需要固定的内存量和每个固定数量的计算步骤字符。

正则表达式是一种编写正则语言的形式。随着从理论计算机科学中这些概念的发展, 它们是简约的, 只允许字面量, 替换(|), 括号进行分组, 以及Kleene star^[2](*)表示零次或多次重复。

早期的文本处理工具, 如 grep, sed 和 awk 都接受了正则表达式的概念, 并加入了许多方便的功能, 比如可以编写 [az] 而不是 a|b|c|d|e …​.。他们提供了预定义的*字符类*、字符集、例如字母、数字、空白字符等等。他们还增加了捕获功能, 帮助提取正则表达式匹配的特定部分的字符串。

后来的实现增加了一些超出正则语言所允许的功能, 因此需要一个单独的单词。这些实现也是为了便于使用而不是理论构造的极简主义而进行优化。现在, 我们在谈论到编程语言和库中的实用(而且更强大的)实现时, 倾向于使用正则表达式。

为了继续上一节的历史课程, Perl 是最早将正则表达式纳入其核心功能的通用编程语言之一。它从早期的正则表达式实现中借鉴了语法, 并对其进行了扩展, 使正则表达式变得更加强大和有用。很快, Perl 的特殊版本的正则表达式就成为了事实上的标准。所以很多名为兼容 Perl 的正则表达式(PCRE)的库被创建出来, 这样其他软件可以在他们自己的实现中使用 "Perl 正则表达式"。

遗憾的是, 在使正则表达式如此有用的过程中, Perl 给几乎所有的 ASCII 字符都赋予了特殊的的含义(除了按字面匹配的字符)。并且, 随着更多新的、更强大的正则表达式功能被创造出来, 这就导致了在继续保持与现有的正则表达式语法向后兼容的同时, 还需要使用一些晦涩的字符序列来实现新的功能。(?⇐pattern) 就是一个很好的例子。

Raku 正则表达式清理了这种历史上的语法包袱。它们通过允许无处不在的空白, 引入了关于哪些字符是特殊字符, 哪些不是特殊字符的规则, 以及最重要的是, 它们有一个简单、可扩展的语法, 可以通过名字来调用其他正则表达式, 从而提高来可读性。

虽然大多数语言将正则表达式视为字符串或特殊对象, 但是 Raku 正则表达式是代码; 当正则表达式在 grammar 中组合在一起时, 就像方法一样。这让你可以自由地将所有你在编程语言中习惯你的管理和重用代码的技术应用到正则表达式中: 命名空间、类、角色^[3]、继承等等。

组合正则表达式的能力使得 Raku 不仅仅能解析简单的字符串格式。你可以写出使用许多小的正则表达式来解析复杂的文件格式的 grammar。实际上, Rakudo 编译器本身就使用了 grammar 来解析 Raku 源代码。

Raku 编译器有两种: 编译器本身和 Rakudo Star。后者是一个包含编译器、zef 模块安装程序、文档和一些模块的发行版。

出于我们的目的, 你需要编译器和 zef。安装 Rakudo Star 为你提供了这两样东西, 但如果 Rakudo Star 安装程序不适合你, 或者你更喜欢更精简的安装, 你可以只安装编译器, 并根据文档安装 zef。^[4]

以下是安装 Raku 的一些选项。

你可以通过运行 raku --version 来验证你的 Raku 安装是否正常, 应该打印出类似这样的东西:

如果你自己搞不定, 可以向 Raku 社区^[6]寻求帮助。

一旦成功了, 你可以通过运行不带参数的 raku 启动一个简单的交互式 shell:

在这个 shell 中, 你可以输入几行 Raku 代码, 这些代码会立即被执行。这对于测试正则表达式非常有用:

(如果你还不明白这里到底发生了什么, 不要担心; 下一章会详细解释。)

然而如果提示符返回这样的东西:

你应该按照问候信息中的建议, 安装它提到的一个模块。这样你就能访问和编辑你的命令的历史记录了:

当然, 你也可以使用 raku 来执行脚本文件, 只需在命令行中添加脚本文件即可:

假设你在当前工作目录下有一个文件 greet.p6, 其中包含了 say "Hello, world";。

本书中使用的代码示例的源代码可以在 GitHub 上找到:

如果你没有 git, 你也可以从 https://github.com/apress/perl-6-regexes-and-grammars/archive/master.zip 下载一个包含源代码的压缩包。

我鼓励你运行这些示例脚本, 修改并运行它们。这是比单纯阅读本书更深入学习这些主题的最好方法。

为了有效地使用 Raku 中是正则表达式, 你需要了解一下他们所嵌入的语言。

Raku 是一门自由形式的语言, 所以你可以随意缩进你的代码。然而, 有些情况下, 是否有空格是很重要的: doit(1, 2, 3) 调用带有 3 个参数的函数 doit, 而 doit (1, 2, 3) 只用单个参数来调用同一个函数, 这个参数是一个 3 个值的列表。

语句之间用分号(;)字符隔开, 你也可以在程序的最后一行放一个分号。注释以井号字符(#) 开头, 并一直延伸到行尾:

我们已经看到了几种安装 Raku 编译器的方法。 安装完毕之后, 就可以通过运行不带参数的 raku 启动一个交互式的 Raku shell, 或者 raku script.p6 来执行 Raku 程序。

我们还探索了我们的第一个简单的 Raku 程序。接下来我们将直接开始编写我们的第一个正则表达式。

正则表达式中最简单的元素是字面量: 即完全匹配自己的字符串。例如, 正则表达式 /perl/ 匹配任何包含 p,e,r 和 l 字符的字符串, 它们的顺序正好是这样的。因此, 字符串 "properly" 从第四个字符开始匹配此正则表达式(properly), 但字符串 "superficial" 不匹配, 因为它在 per 和 l 之间包含了其他字符(ficia)。

仅由字母, 下划线 _ 和数字组成的字面量不需要任何特殊的语法。只需将字母和数字写为正则表达式的一部分写成字面量即可。其他字面量必须用引号括起来, 要么使用单引号要么使用双引号: /'2016-12-24'/ 和 /"2016-12-24"/ 类似, 两者都与字符串 2016-12-24 匹配。由于这两个破折号既不是字母也不是数字, 所以需要成为引号字符串的一部分, 才能从字面上匹配。单引号和双引号对儿在插值方面的行为有所不同: 变量和花括号 {…​} 分隔的代码块在双引号中被插值, 所以下面的正则表达式都匹配字符串 "3":

而正则表达式 /'{1 + 2}'/ 只匹配字面字符串 {1 + 2}。

在 Raku 正则表达式中, 默认情况下会忽略空格, 所以 /perl/, /pe rl/, 和 / p e r l/ 都是等价的(尽管后两个产生一个警告), 而且匹配的字符串完全相同。在引号里面, 空格是重要的, 所以 /"pe rl"/ 与字符串 properly 不匹配, 因为该字符串中没有空格字符, 但引号内的字符串有。

正如我们在上一节中看到的那样, 正则表达式中的字母数字字符与它们自身匹配。所有其他字符都可能有一些特殊的含义。 我们已经看到 ' 和 " 是特殊的: 它们包围着被引用的字符串。

我们称这种"特殊"字符为元语法或元字符。 反斜线 \ 使字面量字符变得容易, 反之亦然。例如, /d/ 匹配字面的 d, 但 /\d/ 可以匹配单个数字。另一方面, 正则表达式中的 + 修饰前一个字符, 但是 /\+/ 匹配的是一个加号, 也就是 +。唯一的例外是 # 字符, 它不能通过反斜线前缀来匹配字面意思, 必须用引号代替。

并非所有元字符都有特殊的语义含义。例如, 感叹号(!)没有元语义, 并且 Raku 产生一个适当的错误信息:

正则表达式会搜索整个字符串以查找匹配项。有时这不是你想要的。锚点只在字符串中的某些位置进行匹配, 从而将正则表达式匹配锚定在该位置。

最常见的锚点是 ^ 和 $。它们分别匹配字符串的开头和结尾。正则表达式 /^go/ 匹配以字母 g 开头的字符串 , 例如 gown。相比之下, /go$/ 匹配所有以字母 o 结尾, 其前面由 g 开头的字符串, 例如 tango。 最后, 同时使用这两个锚点的正则表达式, /^go$/ 只匹配字符串 go。

由于空格通常被忽略, 我们可以将这些正则表达式写为 / ^ go /, / go $ / , 或 / ^ go $ /。

但是 / g ^ / 和 / $ g / 这两个正则表达式无法匹配任何字符串, 因为没有一个字符串在其开始之前或结束之后都有一个字符。一般来说, 如果你写出这样的正则表达, Raku 不会发出警告或抱怨, 尽管未来的版本可能会产生警告。如果你需要一个永远不可能匹配的正则表达式, 可以使用 <!>, 它可以达到同样的效果, 但更加明确。

字符串可以由多行组成; 锚点 ^^ 和 $$ 分别匹配行的开头和结尾。$$ 锚的特殊之处在于, 它匹配换行符之前, 如果没有尾随换行符, 则匹配字符串的末尾:

锚点是零宽度的正则表达式元素。因此他们不会"消耗"输入字符串中的字符, 也就是说, 它们不会推进正则表达式引擎尝试匹配的当前位置。一个好的心理模型是, 它们在输入字符串的两个字符之间(或在输入字符串的第一个字符之前, 或在输入字符串的最后一个字符之后)进行匹配。

Raku 中内置了更多的锚(表 3-1)。

单词边界是字母数字字符组和下划线(_)以及任何其他字符之间的边界。例如, 字符串 "some-words_here" 就包含这些单词边界: "⏏some⏏-⏏words_here⏏"。注意, 在这种情况下 _ 字符的周围没有边界。它被当作一个字符来处理。

如果你必须拼写出每个要匹配的字符, 那么正则表达式就非常受限了。而字符类则放宽了这一要求。例如, 点(.) 代表任何一个字符。

你可以使用它来解决填字游戏, 效果非常好。假设你正搜索一个五个字母的单词, 你知道第二个字母是 e, 最后两个是 rl。这几乎可以是任何字符串, 对吧?

一旦有了单词列表, 你就可以用正则表达式 / ^ .e.rl $ / 来测试每个单词, 这样可以大大减少需要考虑的单词数量。

有些 Linux 发行版会自带一个文件 /usr/share/dict/words, 其中包含一个英文单词表, 每行一个单词。搜索这样一个单词列表只需一个非常短的脚本:

在我的系统(Ubuntu 16.04)上, 这只产生两行输出:

它们只是在大小写上有区别, 所以对于填字游戏, 它们是一样的。

这个脚本是如何工作的? 代码 '/usr/share/dict/words'.IO 创建了一个 IO::Path 对象, 并在其上调用 .lines 方法返回文件中的一系列行。for 循环会在这些行上进行迭代, 这些行也正好是单词。

命令 say $word 打印单词, 然后跟着一个换行符, 但是只有满足 if 后缀的条件才打印。lc($word) 返回小写的 $word, 最后一行的其余部分检查小写单词是否与正则表达式 / ^ .e.rl $ / 匹配。

由于字符类非常有用, 所以 Raku 有很多字符类。有些字符类由反斜线和一个小写字母组成。在这些情况下, 大写版本是否定意义的(表 3-2)。

所有这些分类都考虑了完整的 Unicode 字符序列; 所以 \d 不只是匹配 0 到 9 的数字, 还匹配所有脚标和变体的数字, 例如 ٤ - ARABIC-INDIC DIGIT FOUR。在支持 Unicode 9 版本的 Rakudo 2017.05 中, 有 580 个不同的字符与 \d 字符类匹配。

如果要找出所有匹配某个字符类的字符, 你可以迭代所有 Unicode 字符。下面是一个例子, 它列出了所有匹配 \n 的字符:

这会产生如下输出:

chr($c)^[10] 将代码点编号 $c 转换为它背后的实际字符。printf^[11] 是一个例程, 用于打印根据模板格式化的输出, uniname^[12] 返回 Unicode 字符数据库中字符的名称。

到目前为止, 我们看到的正则表达式都匹配固定数量的字符。这种情况即将改变。量词控制其前面的正则表达式元素(原子)的匹配频次, 因此允许可选和重复的元素。

+ 量词匹配它前面的原子一次或多次。例如, / ^ a+ $ / 匹配字符串 a, aa, aaa, aaaa, 等等。

量词的绑定非常紧密, 比正则表达式元素的连接更紧密 , 因此 / ab+ / 匹配 ab, abb, abbb 等。你可以把它写成 / a [b+] / 以消除任何歧义。

如果你想匹配 ab, abab, ababab, 你可以使用引号或括号来强制 + 应用于多个字符: / [ab]+ / 和 / 'ab'+ / 都匹配这些字符串。前者比较通用, 因为它不仅适用于字面量, 也适用于其他的正则表达式。/ [\d+ ',']+ / 匹配一个数字列表, 每个数字后面跟一个逗号。

还有更多的量词, 如表 3-4 所示。

最一般的形式是 ** RANGE 量词, 其中 RANGE 可以是 MIN..MAX, 表示有上限的范围, 或者 MIN .. * 表示没有上限的重复:

"Hi," "Hello," 和 "Hey" 可能都是英语中被普遍接受的问候语。 匹配这种问候语的正则表达式必须接受这三个选项中的任何一个:

竖条 | 分割分词中的备选项或分支。在这个例子中, 这些分支不一定要像这个例子中的字面意思; 他们可以是任何一个正则表达式。

Raku 就是这样, 正则表达式分词有两种形式。单个垂直条形式与产生较长匹配的分支相匹配。如果两个或多个匹配的长度相同, 那么以字面量开始的分支就会获胜, 所以对于正则表达式 /a.|../ 匹配字符串 ab, 第一个备选项比第二个备选项更符合。

如果你将垂直条加倍, 则从左到右依次进行选择, 并且, 第一个匹配的备选项胜出:

在前面的示例中, a+ 匹配 aa, 而 \w+ 可以匹配整个字符串 aab。在 | 的情况下, | 作为析取运算符, 更长的匹配胜出, 因此该正则表达式匹配整个字符串。对于 ||, 第一部分, a+ 匹配成功, 所以甚至不需要尝试第二个分支。

当你编写备选项时, 你可以让第一个分支留白, Raku 会忽略这个空的分支。这纯粹是出于审美的原因, 所以你可以这样写:

而不是在视觉上有点不太平衡的这种写法:

你可以把 | 和 || 看作逻辑或。但是 AND 运算符呢? 大多数的正则表达式实现都会省略它, 但 Raku 却没有。它被拼写成了 &, 就像分词一样, 有一个顺序变体 &&。当我们在后面的章节中讨论你正则表达式的副作用时, & 和 && 之间的区别就会很明显。

当你有一个正则表达式并想要进一步地约束它时, & 运算符很有用。举例来说, 你可能正在文本文档中搜索电话号码, 而你已经有一个电话号码的正则表达式了, 但你记得你要查找的号码中, 有一个 17 的序列。你可以使用此正则表达式搜索这样的号码:

& 连词的分支必须匹配字符串的同一部分 , 所以这里 17 用 .* 拉伸右分支的匹配到左分支的匹配来填充。

你可以使用同样的技巧来排除某些字符的匹配。例如, 一个不包含数字 9 的电话号码可写为:

你怎么能实现自己的锚点呢?

到目前为止, 我们讨论过的正则表达式结构不允许你这样做, 因为他们都需要消耗字符来决定是否匹配。

零宽度断言将另一个正则表达式变为锚点, 使它们不消耗输入字符串中的任何字符。它们有两种变体: 向前查看和向后查看断言。^[14]

向前查看断言被拼写为 <?before regex>, 它将正则表达式转换为锚点。因此, 如果你想匹配数字后跟一个单位 (例如 KB 表示千字节或 MB 表示兆字节), 但不匹配单位本身, 你可以用这样的正则表达式来匹配:

在这里, 正则表达式 \s* <[kMGT]>? B 匹配可选的空格, 然后是单位 B、KB、MB、GB 或 TB。周围的 <?before …​> 使只有当单位的正则表达式匹配时, 匹配才会成功。请注意, 这个断言没有推进字符串中正则表达式的位置, 因此匹配单元的字符串不包含在整个正则表达式所匹配的字符串中。^[15]

你可以使用 ! 代替 ? 来否定向前查看。所以要匹配一个数字, 其后面不是单位, 你可以使用正则表达式:

在这种情况下, 正则表达式只匹配字符串 20, 因为它是一个后面不直接跟随单位的数字。如果你根本不想让它匹配这个输入字符串, 你可以在这个数字周围使用单词边界断言:

我们也可以编写从当前位置向后查看的正则表达式, 而不是向前看字符串。匹配一个后面跟随逗号的数字, 你可以这样写:

使用正向和反向向前查看和向后查看断言, 你可以重新实现内置的锚点,^[16] 你也可以编写自己的锚点。例如, ^ 匹配字符串的开头, 也可以写成 <!after .>; 只有在没有字符出现在它之前时才匹配。同样地, 左单词边界 «, 可以写成 <!after \w> <?before \w>。左单词边界就可以写成 <!after \d> <?before \d>。

需要注意的是, <!after \w> 和 <?after \W> 虽然相似, 但不尽相同。不同之处在于, <!after \w> 匹配字符串的开头, 而 <?after \W> 不是, 因为它需要匹配一个非单词字符。

正则表达式的基本构建块是字面值、字符类、锚点、量词、分词(备选项)和连词(重叠)。他们构成了使用 Raku 正则表达式进行检索、验证和解析的基础。

智能匹配操作符 ~~ 是一个通用的比较运算符, 它右侧的对象决定了比较的语义。 例如, 如果右侧的对象是数字, 则 ~~ 就会进行数值比较。如果右侧的对象是一个类型, 则检查左侧的对象是否为该类型(或其子类型)。

我们特别感兴趣的是, 右侧是正则表达式的情况。 在这种情况下, 智能匹配操作符将左侧解释为字符串, 并使用该正则表达式搜索匹配:

如果匹配失败, 则匹配的返回值为 Nil, 或者如果匹配成功则返回一个匹配对象。^[17]如果在布尔值上下文中使用匹配对象 (比如 if 语句的条件), 则它的计算结果为 True (而 Nil 计算为 False); 在字符串上下文中(或通过调用 .Str 方法将其强制转换为字符串上下文时), 它计算为与正则表达式匹配到的字符串部分。从 say 输出的角括号( ⌜ 和 ⌟ ) 表示匹配对象。

除了智能匹配之外, 你还可以使用 .match^[18] 方法在字符串中搜索匹配项:

到目前为止, 我们已经看到由两个斜杠 /…​/ 分隔的正则表达式, 但是还有其他的方法来编写正则表达式。这些都是等价的:

如果你使用 rx 编写正则表达式, 则可以使用几乎所有的非单词字符作为分隔符(除了空格、冒号(:)和井号(#)之外)。

前面介绍的形式返回一个 regex 类型的对象, 你可以将其存储在变量中, 或者在智能匹配操作中使用。

此外, 还有一个使用 m(意为 match)而不是 rx 的形式。 它不是返回正则表达式对象, 而是立即将正则表达式与特殊变量 $_ 匹配:

由于智能匹配运算符 ~~ 自动将 $_ 设置为表达式的左侧, 所以在智能匹配中可以使用 m/…​/:

修饰符改变了正则表达式的工作方式。它们分为两类。如果你把正则表达式看作是被编译为字节码^[19]的小程序, 那么有些修饰符会影响编译, 有些修饰符则会影响你调用程序的方式。

例如, :global 修饰符(短形式 :g)属于后一类; 它指示正则表达式搜索字符串中所有不重叠的匹配:

第一种类别的一个例子是 :ignorecase(简称 :i), 它指示正则表达式引擎忽略大小写, 因此正则表达式中的大写字符可以与小写的等效字符匹配, 反之亦然^[20]:

如前文所示, 影响到正则表达式编译的修饰符可以在正则表达式本身内部使用。影响编译后的正则表达式行为的修饰符总是在外部使用。

由于 m/…​/ 形式是立即匹配的, 所以你也可以给它添加会影响正则表达式的运行时行为的修饰符:

这里 m:g/./ 返回一个含有三个匹配项的列表, 所以 .elems 方法返回数字 3。(见表 4-1。)

:ignoremark 或 :m 修饰符允许你只用基本字符进行匹配, 而忽略变音符号和其他装饰字符的标记。在 :m 的作用下, /a/ 可以匹配 a, à, á, â, ã, ä, å, ā 和其他 22 个字符。

:sigspace 修饰符使 grammar 匹配中的空格与字符串中的空格匹配, 尽管不一定是一对一的映射。:ratchet 修饰符禁用回溯, 所以如果正则表达式引擎成功地以一种方式匹配字符串, 它不会再尝试以另一种不同的方式匹配。我们稍后将更详细地讨论这两个修饰符。

这些修饰符也可以放在正则表达式的中间, 或者通过方括号组 […​] 组来限制正则表达式的一部分:

你还可以通过在冒号后面添加感叹号来禁用修饰符。所以最后一个正则表达式可以写成 /:i ab :!i cd/。 (见表4-2。)

所有接收参数的形式(此处为 5)也可以接受变量作为他们的参数。从字符串的开头位置从零开始计数, 就像使用 substr^[21] 进行字符串索引一样。

如果你用 :global 搜索多个匹配项, 则第二个匹配的搜索从第一个匹配结束的地方开始。使用 :overlap, 第二个匹配的搜索从第一个匹配的下一个字符开始, 因此这两个匹配的匹配字符串可以重叠。:exhaustive 修饰符找到所有可能的匹配, 即使有几个匹配都从同一个位置开始。

如果你使用不带参数的 :continue 和 :pos 修饰符, 它们将默认为上一个匹配离开时的位置。

如果你想在一个字符串中找到正则表达式出现的所有次数, 但你只是对结果字符串感兴趣(而不是对匹配对象感兴趣), 你可以使用 comb^[22] 方法找出它们:

相反, 如果你只对字符串中不匹配正则表达式的部分感兴趣 , 那么 split^[23] 方法适合你:

在这里, 正则表达式只包含一个字面量; 在这种情况下, 你可以直接将字面字符串传递给 split, 就像 'Berlin; 891.8; 3671000'.split(';'); 那样。

comb 和 split 方法都接收第二个可选的参数 limit:

split 方法对于解析简单文件格式很有用, 例如逗号分隔的不带引号的文件。

你不仅可以用正则表达式来匹配文本, 还可以用正则表达式来转换文本。

subst^[24] 方法可以用另一个字符串替换正则表达式所匹配的字符串部分。在最简单的情况下, 替代者是一个字符串常量:

如果替代者是空字符串, 则替换将删除匹配的字符串:

与正则表达式匹配一样, 修饰符和替换可以一块儿用。例如, :global 替换正则表达式匹配的所有出现过的字符串(而不仅仅是第一个, 即没有修饰符时):

如果你希望替换的字符串取决于匹配到的值, 你可以传递子程序或块作为替换部分, 它接收匹配对象作为其参数:

在这种替换块中, 像 $0, $1 等匹配变量(下一章会有更多介绍)都不起作用, 除非你明确声明匹配变量 $/ 作为这个块的参数:

还有一种语法上的变体, 用于原地修改变量的替换。

注意, 在这种情况下, 第一个斜线和第二个斜线(/)之间的部分是一个正则表达式, 但第二个斜线和第三个斜线之间的部分是一个字符串。这意味着在第一部分中, 空格被忽略, 但在第二部分中空格是有关的。在替换字符串内部, 你可以使用 $0、$1、$2 等等, 用于引用捕获(有关捕获的更多信息, 请参阅下一章):

如果你使用 […​] 或 {…​} 来分隔正则表达式, 那么替换部分也可以是 Raku 表达式:

其中 $/ 指的是匹配对象。注意, 在这种情况下, 赋值运算符是在右侧之前使用的。

这会产生如下输出:

当你替换零宽度匹配时, 替换就变成了插入操作:

这里的 <?before …​> 和 <?after …​> 将它们内部的正则表达式变成零宽度的正则表达式, 所以替换命令并不会替换匹配的文本(如 "jump"), 而是在匹配之前或之后插入替换部分 :

你可以把普通匹配和零宽度匹配结合起来。例如, 这个语句将后面跟着单位 MB 或 GB 的所有数字都替换为 500:

正则表达式和普通的 Raku 代码编译成相同的字节码, 而你可以将 Raku 代码和正则表达式混合使用。

最明显的交互方式是将 regex 对象存储在变量, 然后在普通代码中使用它们:

这样, 你可以为正则表达式起个名字, 同时也可以做所有其他可以用变量做的事情: 把它们放到数据结构中, 然后从函数中返回, 等等。

反过来也可以。变量可以成为正则表达式的一部分:

如果一个变量包含一个字符串, 它总是按字面意思匹配; 如果它包含正则表达式, 则作为正则表达式匹配。

如果要把变量的内容解释为正则表达式, 你必须将它包含在尖括号中:

此示例还演示了反斜杠必须在引用的字符串中加倍 - 本例中是赋值给变量 $audience - 但不是正则表达式。在双引号字符串中, 反斜杠引入了一个转义序列(例如 \n 表示换行符, \t 表示制表符)。使用语法 <$audience> 可以将变量 $audience 的内容解释为正则表达式。

在正则表达式中使用数组变量相当于将数组中的每个元素作为备选项进行匹配; 因此

等价于这样写:

除了一点, 使用数组变量时, 用程序化的方式提供值比较容易。

最后, 你可以在正则表达式中包含 Raku 代码块, 只需将其嵌入到花括号中即可。这对于在执行正则表达式时建立数据结构(如符号表)很有用 。

例如, 我们可以计算字符串中数字出现的次数:

这里块 { $count++ }, 它将变量 $count 增量 1, 在正则表达式的 \d+ 部分之后执行。虽然这是一个有点构造化的用例, 我们将在后面的章节中看到正则表达式代码块的实际应用。

正则表达式中代码块的另一个很好的用例是添加 print 语句用于调试, 以查看正则表达式是如何匹配的。

这里我们尝试将浮点数与正则表达式匹配:

这个正则表达式匹配失败了, 要看这个正则表达式匹配到什么程度, 你可以删除使片段可选的问号, 然后添加一些代码块来显示增量进度:

这产生如下输出:

我们可以看到这个正则表达式的最后一部分只匹配了 e, 而不是 e42。 仔细观察就会发现 [e|E \d+] 中的备选项延伸到了 \d+, 而这并不是本意。添加一个分组级别, [ [e|E] \d+ ], 修复该正则表达式。

这些代码块使用了特殊变量 $/, 它包含了匹配(或者至少是部分匹配, 就其进展而言)。

这些代码块的执行纯粹是为了它们的副作用。你可以使用 <?{…​}> 形式来影响正则表达式匹配。如果该代码块中的代码返回 false 值, 则匹配失败^[25]:

此示例的正则表达式匹配 0 到 255 之间的数字(例如, 可能用于验证 IPv4 地址), 并且只打印 0、100 和 255 这些数字。

$/.Int 调用将匹配的字符串转换为整数, 并且当且仅当该数字最多为 255 时比较 ⇐ 255 才返回 True。

在本章中, 我们已经看到了如何在 Raku 代码中使用正则表达式, 反之亦然。你可以将正则表达式存储在变量中, 也可以在正则表达式中使用变量。

在下一章中, 我们将探讨如何从正则表达式匹配中提取信息或其中的部分信息。

你可以通过指示一个正则表达式来捕获一些数据, 通过在正则表达式的一部分的周围加上一对圆括号来提取相关数据。然后, 这部分正则表达式匹配的字符串就会被单独提供:

捕获从左到右, 从零开始编号。 第一对括号中的正则表达式匹配的字符串可以保存在特殊变量 $0 中, 第二对括号中的正则表达式匹配的字符串可保存在特殊变量 $1 中, 以此类推。

由于这些捕获的编号取决于它们在正则表达式中的相对位置, 我们称它们为位置捕获。

每个成功的正则表达式匹配的结果是一个 Match^[26] 类型的对象。 当你用智能匹配运算符 ~~ 匹配一个正则表达式时, 这个正则表达式对象也可以在特殊变量 $/ 中使用。

匹配对象提供了大量关于正则表达式匹配的信息: $/.orig 包含了正则表达式匹配的字符串, $/.from 和 $/.to 包含了匹配的开始和结束位置, 在字符串上下文中使用它(或通过在它身上显式调用 .Str 方法)返回匹配的字符串。

但还有更多: 当你像使用数组一样使用匹配对象时, 你可以从捕获中访问匹配项。$0 实际上是 $/[0] 的别名 , $1 实际上是 $/[1] 的别名, 等等。

捕获本身也是 Match 对象:

当你有超过两个或三个以上的捕获时, 你可能会忘记哪个编号指向哪个捕获组。为了减轻这种负担, 并使代码在重构时更加健壮, 你可以使用命名捕获来代替:

$<thename> 在正则表达式内部和外部都指向命名捕获。在正则表达式内部, 你可以给它分配一个名字, 然后在正则表达式外面你可以访问相应的匹配对象。在正则表达式外部, $<thename> 实际上是对匹配对象的命名访问的快捷方式, $/<thename> 或 $/{'thename'}。这种访问命名捕获的模式与访问哈希元素的语法相同。

如果在同一个正则表达式中使用了两次(或更频繁地)相同的名字, 那么捕获再次成为一个数组。

在后面的章节中, 我们将更详细地讨论命名正则表达式。对于现在, 创建命名捕获的更简单方法就是按名称调用正则表达式就足够了:

这里 <byte> 调用命名正则表达式 byte, 并自动捕获由此同名子规则 byte 所匹配到的字符串。你可以使用语法 <alias=originalname> 来重命名捕获:

反向引用允许你访问正则表达式内部的捕获, 匹配正则表达式的前一部分捕获的字符串。这里有几个可能有用的案例, 比如在文本中搜索意外重复的单词时。第一次尝试将是这样的正则表达式: / (\w+) \s+ $0 / 这个正则表达式匹配一个单词(\w+)并将其捕获到 $0 中, 后面是空格(\s+), 然后再跟着原始单词($0)。然而这不符合预期。用它来匹配字符串 the next thing, 它会匹配 t t, 因为 \w+ 很乐意只匹配一个字符。

为了使它工作, 我们可以通过包括单词字边界断言: / « (\w+) \s+ $0 » / (记住 « 匹配左单词边界而 » 匹配右单词边界)来限制匹配整个单词。

现在, 如果你把它与字符串 "the quick brown fox jumps over the the lazy black dog" 进行测试, 它就会正确地匹配两个 "the"。

反向引用也适用于命名捕获; 前面的例子可以写成 /« $<word>=\w+ \s+ $<word> »/。

反向引用的另一个常见用例是查找类似于引号的字符串, 只要两端都是一样的, 你不用关心实际的引用字符。

请注意, 反向引用绝对超出了常规计算机科学中定义的语言的范畴; 你需要更强大的形式主义来实现。

如前所述, 成功的正则表达式匹配会返回匹配对象。除了匹配的子字符串的位置和长度之外, 匹配对象还存储了所有位置捕获和命名捕获。要获取所有的位置捕获的列表, 可以调用 .list`方法。同样的, `.hash 方法也会将命名捕获作为一个散列返回。散列是一种数据结构, 具有从名称或键到值的映射; Python 称它为 dict 或字典, JavaScript 称之为对象。

当使用 say 函数打印匹配对象时, 输出的是以 ⌜⌟ 分割的匹配字符串:

如果正则表达式包含了捕获, 则会在单独的行中打印出来, 并缩进一个空格。因此

产生输出:

其中 0 和 1 是捕获的索引。嵌套捕获会产生更多的缩进, 所以 "abc" ∼∼ /.(.(.))/ 打印出:

因此, 命名捕获仅以其名称来区分:

打印:

捕获允许你从成功的正则表达式匹配中提取数据。你可以通过在正则表达式的一部分的周围添加一对圆括号, 使用 $<name>=[…​] 语法, 或者通过调用一个命名的正则表达式, 来指示正则表达式引擎捕获数据: <name>。

正则表达式匹配和捕获都产生匹配对象; 最上面的匹配对象会变成一棵子匹配树。反向引用允许你精确地匹配一个正则表达式的前一部分的匹配对象, 你可以滥用该功能来构建一个简单的质数测试。

当计算机科学家谈论正则语言时, 他们还描述了一种有效识别特定字符串是否属于正则语言的机制。在 Raku 中, 如果字符串与正则表达式匹配, 那么这只是简单地表示。

在正则表达式引擎无法使用 NFA 的情况下, 或者理解 NFA 并不能提供很多关于正则表达式如何匹配的见解, 那么理解一般正则表达式的控制流程是有用的。

第一条规则是正则表达式引擎总是从字符串的开头开始, 并优先选择最左边的匹配。

第二条规则是贪婪规则: 正则表达式是从左到右进行计算的, 每一个匹配到可变字符数的部分都会尝试匹配它能匹配到的最长子串。^[32]

因此, 如果你有一个正则表达式 / \w+ .* / 并将其与字符串 abcd 匹配, 那么 \w+ 会匹配整个字符串, 使 .* 成功匹配空字符串。\w+ 只匹配第一个字符, 剩余的 .* 同样允许匹配, 但不会发生, 因为这违反了正则表达式最左边的部分尽量匹配的规则。

如果你试图用一个简单的正则表达式 / \" .* \"/ 来匹配一个带引号的字符串, 那么它可能比你预期的要匹配的多:

这产生如下输出:

因为 * 并不在意你不没有打算在第一个引号的边界之外匹配; 它只是尽可能多地匹配, 同时使使整个匹配成功。

贪婪规则并不总是在第一次尝试时就会产生匹配。 在前面的例子中, .* 首先匹配了所有能匹配的东西, 包括输入字符串中的最后一个引号。但是在正则表达式中的最后一个引号没有匹配到, 导致了失败。

正则表达式引擎没有放弃, 而是开始回溯: 它回到了之前的量词(. 中的 ), 并使其少重复一次匹配。只有这样, 正则表达式中的引号才能找到输入字符串中的引号, 使整个正则表达式匹配成功。

如果有多个正则表达式元素可以以不同的方式匹配, 那么回溯会尝试从最后一个元素开始尝试所有的选项, 如果它们全部都失败了, 那么回溯就会从倒数第二个元素尝试另外一个选项。然后探索该配置中最后一个元素的所有变体, 并继续尝试从之前的元素中搜索匹配。如果你把它看成是搜索树, 那就是深度优先搜索。

让我们考虑一个带有两个可变部分的正则表达式, 结合搜索, 让我们一块儿看看:

这开始时, 第一组 (.+ a) 匹配完整的字符串; 第二组 (.) 匹配空的字符串; 最后一部分, $0 匹配失败。因此, 回溯开始了, 它要求第二组匹配更少的字符, 但它不能; 所以它又回到了第一组, 要求它匹配更少的字符。现在, 第一组匹配了 mabracada, . 匹配了剩下的三个字符。但是, 最后一组仍然没有匹配成功, 所以 .* 放弃了另一个字符, 最后一组继续失败。如此循环, 直到第一组只匹配了两个字符, ma。 即使在这种配置下, 其余的正则表达式也无法成功匹配。正则表达式引擎没有选项了, 所以它采用了最后的机制: 它尝试在第二个字符的左边一个位置开始匹配。

从第二个字符开始, 第一个组再次尝试匹配整个剩余的字符串, abracadabra。我们可以通过添加在正则表达式的第二部分后面添加一个代码块来直观的说明:

在尝试了 46 种不同的配置后, 它找到了一个匹配项: 从第二个字符开始, (.+ a) 匹配 abra, (.*) 匹配 cad, $0 再次匹配 abra。

从它们匹配的内容来看, 你可以清楚地看到, 正则表达式后面的部分比前面的部分变化更快。该正则表达式的起始位置的推进速度更慢, 事实上是最缓慢的变化。

正则表达式引擎永远不会回溯到零宽度断言(向前查看和向后查看的断言)。对于这些, 只看它们是否匹配, 而不看它们是如何匹配的, 因为成功的匹配从来不会消耗输入字符串中的任何字符(它匹配空字符串)。

回溯是使正则表达式起作用的秘密魔力。它可以让计算机代表你努力工作, 并在输入字符串中找到匹配项。

但, 在某些情况下, 回溯会代码更大的伤害; 因此, Raku(以及其他一些正则表达式实现)提供了禁用回溯的方法, 或者减少回溯的工作量。

正如前面一章中提到的, 有节俭量词或惰性量词, 尝试尽可能少地匹配。这些量词总是会回溯, 即使是在启用了 ratchet 修饰符的情况下也是如此。

当一个贪婪的量词试图尽可能多地匹配时, 即使不回溯, 也会通过应用量化的正则表达式元素, 看看是否匹配。另一方面, 节俭量词总是从以最小的匹配数量开始, 只有回溯才能让它匹配更多的元素。因此, 如果不进行回溯, / a ?? / 或 / a *?/ 只匹配空字符串, / a +?/ 只匹配单个 a, 以此类推。

带 | 的离散项或替代项更喜欢与最长的字符串匹配的分支。我们称之为最长的令牌匹配。

这在解析时非常重要, 因为它与我们自己直觉上识别文本的方式是一致的。例如, Raku 的表达式 $var` 可以被解析为前缀运算符 ` (将后面的变量增量1), 后面是变量 $var。或者, 它可以解析为 +(+$var), 将前缀 + 运算符(将其参数转换为数字)应用到 $var, 然后再将相同的运算符应用到结果中。Raku 语法是基于 regexes, 它知道更喜欢第一个变体（单个 ` 运算子）, 因为当试图解析前缀运算符时, 它产生的匹配时间最长。footnote:[这是另一种你不希望回溯的情况：一旦解析器识别了 ` 运算符, 你不希望它改变主意, 把这两个字符解释为不同的运算符。]

为了能够有效地匹配最长的替代变量, Raku 会确定一个 regex 的哪些部分构成了声明性前缀。然后构造一个 NFA 来匹配这个声明性前缀。一旦完成后, 一般的正则表达式引擎的其他部分就会启动并继续进行, 直到找到下一个声明式前缀。

声明性前缀被限制在NFA可以建模的元素中：字元、字符类、分词、连词、连接词和贪婪量化器。在命名的regex调用的情况下, 命名的regex的声明性前缀会被合并到调用的regex中, 除非它会导致递归。

我们可以通过插入一个代码块 {}（它不是声明性的）来限制替代的长度来说明这一点（图6-9）。

这里是正则表达式ab | a。*, 第二个分支匹配整体 string, 比第一个分支匹配的长。

通过插入空块 {}, 最长的令牌匹配是 有效地限于正则表达式ab | 一个。现在第一个分支ab产生了 较长的匹配(因为第二个分支的声明部分 只匹配“a”), 正则表达式引擎承诺做出这个决定, 只匹配“ab”。仅当后来的正则表达式元素无法匹配时(和 启用了回溯)正则表达式引擎会重新考虑这个决定。

计算机科学为我们提供了有效匹配常规语言的工具通过有限自动机。即便如此, 常规语言只是其中的一部分正则表达式可以描述什么。其余的是使用回溯处理, 它最喜欢最左边的匹配, 而不是更长的匹配匹配较短的匹配。

这可能是显而易见的, 但还是经常被忽视。为了能够为某些数据格式编写正则表达式, 你需要知道它的规则。也就是说, 如果有规则的话。如果没有, 你可能需要足够多的输入数据来制定规则。并对数据进行测试。然后, 你需要知道验证的背景。

当你编写正则表达式时, 不要只考虑那些正则表达式应该匹配的字符串。对他们不应该匹配的字符串要同等重视。一般来说, 正则表达式应该拒绝的字符串比正则表达式应该接受的字符串多, 这使得这些字符串既重要又难于思考。

你可以做的一件事是写否定测试; 也就是说, 用不应该匹配的输入进行测试。另一个是当你看到 .* 或 .+ 这样的项时, 要停下来, 多想一想。这些词太宽泛了, 以至于大多数时候都是错误的。大多数数据格式都不包含"然后, 无论如何"这样的子句。 例如, 如果你解析到行尾的注释, /'#' .*/ 是错的, 因为它可以通过断行来匹配; /'#' \N* \n? / 是比较好的正则表达式。如果你解析类似于 C 的注释, / * ... * /, 正则表达式 / '/*' .* '*/' 也匹配整个字符串 /* abc */ de */, 因为 .* 贪婪地匹配了字符串中间的结尾注释标记 */。

如果你写的正则表达式是为了匹配整个字符串, 请记住锚定 ^ 和 $ 以确保它确实匹配整个字符串。如果不是的话, 请考虑一下正则表达式匹配的边界。如果你试图匹配一个单词, 后面不跟着一个点(.), 那么正则表达式 /\w+ <!before '.'> / 可以匹配一个部分单词:

这里的 \w+ 实际上匹配的字符是比实际的单词少一个, 所以 <!before '.'> 可以成功匹配。

如果这样的行为不是你想要的, 你可以添加一个断言, 比如单词边界, / \w+ » <!before '.'> /。 因为 \w+ 暗示单词的一部分已经被匹配了, 所以你也可以写 / \w+ <!before \w> <!before '.'> /。

断言的内容是一个正则表达式, 所以在这里我们必须引用点(或转义为 <!before \.>), 否则这个点会展开它的特殊含义, 以匹配任何字符。

许多数据格式包括带引号的字符串。他们的定义特征是, 在两个(或更多的)分隔字符 - 引号之间允许更多的(通常几乎所有的)字符。

我们已经在 Raku 中看到过引用的字符串, 在 Raku 的正则表达式本身中, 可能会出现一些非单词字符, 而这些字符在正则表达式中是保留的。 常见的数据交换格式, 如 CSV、JSON 和 YAML 也包含引号。CSV-逗号分隔的值格式 - 有一个分隔符(默认为逗号(,); 因此而得名), 在类似于表格的结构中分隔列。如果列值本身包含逗号, 你必须能够将逗号与分隔符区分开来, 这通常是通过引号来实现的。

一个 CSV 文件, 包含列 a, 然后是 b, c, 最后是 d 列(即三列), 可以写成:

其中 "b, c" 是带引号的字符串。

如前所述, / \" .* \" / 不是解析引号字符串的有效方法 , 因为 .* 可以匹配断开的结尾引号。如果输入的内容是:

那么被引用的字符串的正则表达式实际上会与输入中的两个被引用的字符串以及中间的列匹配。

一个不那么幼稚的方法是写成 / \" .*? \" /, 这样可以将引用的字符串限制在最短的匹配范围内。这个方法是可行的, 但前提是没有任何东西迫使正则表达式以不同的方式回溯和匹配:

这里的输入是一个不平衡的引号字符串, 中间有第三个引号字符。第一次尝试只匹配了字符串中的 "a, b" 部分, $anchor 没有匹配, 因此回溯开始, 下一次尝试匹配整个字符串。

这通常不是理想的行为。一种更稳健的方法是放弃正则表达式中的点, 并更努力地思考引号字符串中允许的内容: 这很容易用否定的字符类来实现:

现在这只匹配一个平衡的引号字符串。

正则表达式是一种代码。它们是声明性, 而不是程序性的, 这意味着在编写正则表达式时, 你要指定它匹配的是什么文本, 而通常不是如何匹配。但是, 它们仍然是代码, 你应该为代码编写测试, 以获得对他们按预期工作的信心, 并且能够改变他们而不用担心破坏其他使用它们的代码。

Raku 自带了一个测试模块, 可以很容易地编写这样的测试。 下面是上一节中的正则表达式的小测试套件:

让我们来详细探讨一下。一开始是我们熟悉的正则表达式声明。然后代码声明并初始化两个数组变量, @should-match 和 @should-not-match。

第一个包含了我们希望正则表达式匹配的字符串; 第二个变量包含了正则表达式不应该匹配的字符串的例子。

然后, 测试开始了。use Test; 导入测试模块,^[36] 它提供了一些在脚本中进一步使用的函数。plan 是其中之一, plan 6; 告诉测试模块即将有六个测试用例。

接下来是两个 for 循环, 用于检查示例字符串。ok 是一个测试函数, 当使用真值作为其第一个参数时, 它可以使测试成功; 而假值则使测试失败。这里的第一个参数是锚定的正则表达式匹配的结果, $s ~~ / ^<quoted>$ /。第二个参数是测试的标签。在第二个循环中, 使用了测试函数 nok 来代替, 它的逻辑和 ok 相反: 它期望第一个参数是假值(如正则表达式匹配失败)。

当你运行这个脚本时, 它会产生这样的输出:

如果你改变了前三个示例字符串中的一个使正则表达式匹配失败, 你就会得到一个像这样的失败测试输出:

对于文件中的许多测试, 甚至是许多测试文件, 有一个所有测试输出的总结是很有帮助的。通常与 Perl 5 捆绑在一起的 prove 程序可以理解测试的输出(以测试任何协议格式^[37])并打印出一个简短的摘要:

如果测试失败, 它将重点放在失败的测试上, 这样更容易修复:

prove 甚至在终端输出中增加了颜色, 绿色表示"所有测试成功", 红色表示"测试失败", 让状态一目了然。

在最初开发完你的正则表达式之后, 你很可能想用它们来做一些测试以外的事情。在这种情况下, 你可以将测试提取到一个子程序中, 只有当你用一个特殊命令行参数调用你的脚本时才会运行它们, 比如 --test:

在这个例子中, multi sub MAIN 引入了一个名为 MAIN 的子例程。Raku 会自动为你调用子程序 MAIN, 并将命令行参数转换为这个函数的参数。multi 意味着可以有一个以上的子例程。Raku 会调用参数中最适合的候选参数。:$test! 是一个命名参数, 因为前面的冒号(:)和后面的感叹号(!)使它成为必需的。

只有通过命名参数测试, 才能调用这个候选参数。这是它在命令行中的样子:

或者，如果你想使用 prove 测试套件。

第二个候选程序, 用 multi MAIN($input) 声明, 是程序的"正常"执行路径。它需要一个位置参数, 在命令行中是一个不是选项的字符串(所以不以减号(-)字符开头)。它检查参数是否是一个引号字符串, 并打印出相应的信息:

shell 使用了一层引号, 这就是为什么在第一次调用时, 我在双引号字符串周围使用了单引号。这在标准的 POSIX shell 和 bash 中都可以使用; 其他的 shell 可能需要你使用不同的引号来运行这个例子。

当我们在为一个数据格式编写正则表达式时, 经常会发现我们对这个数据格式的了解比我们原先想象的要少。我们可以尝试找到一个正式规范来回答我们问题, 或者我们可以使用实验的方法, 结合我们对数据格式的问题目录, 来进行实验。

我们还讨论了在哪些正则表达式应该匹配的边界上使用断言, 以及巧妙地使用否定字符类来可靠地解析引用的字符串, 即使是在有转义字符的情况下也是如此。

测试可以让我们确信, 我们编写的正则表达式的匹配度不会超过也不会低于我们的期望, 我们探索了一种简单的方法来编写自动测试。

给正则起名字, 并能够通过名称来引用这些正则, 是实现可组合性和重用正则表达式的第一步。

正如我们之前在一些例子中看到的那样, 你可以给正则表达式起名字, 就像你给变量、子程序等起名字一样。这就把正则表达式提升到了和语言中其他构造一样的高度, 使抽象化成为可能。

这里的 my regex byte { …​ } 声明了一个名为 byte 的正则表达式。regex 前面的关键字决定了作用域: my 是词法作用域的。 如果省略 my 关键字, 则声明一个附加到 grammar 上的正则表达式。稍后会有更多介绍。

Raku 中的正则表达式是代码对象, 就像子例程或方法一样。就像例程一样, 你可以通过在正则表达式的名字前加上一个 & 符号来引用正则表达式^[38]:

与一般的子例程不同, 你不能直接调用正则表达式; 它需要一个游标对象用于跟踪其进度。这就是你尝试之后得到的结果:

相反, 你可以使用智能匹配来调用正则表达式, 就像使用匿名正则表达式那样:

当然也可以从一个匿名的正则表达式内部调用它:

通过尖括号语法 <a> 来调用一个命名正则表达式, 会创建一个和被调用的正则表达式同名的命名捕获, 这里是 a。如果你想避免捕获, 你可以将其写为 <&a>。

如果你想让捕获的名字不同, 则可以将其写为 <b=&a>。 这会生成一个命名捕获 b, 但会调用名为 a 的正则表达式。如果你写的是 <b=a>, 那么同一个捕获在名字 a 和名字 b 下都可用。还有更多方法可以调用命名正则表达式(表 8-1)。

如果开口 < 后的第一个字符是一个单词字符, 那么就会产生一个与该单词同名的命名捕获。任何形式的标点符号 - 不管是用于向前查看的 ? 还是用于普通调用的 &, 都会抑制捕获。

回到标记化一个简单的数学表达式的例子, 我们忽略了一个重要的细节：输入中包含了 token 之间的空白, 而 token 流之间不包含空白。词法分析通常会丢弃无关紧要的空白。

并非所有的空白都是无关紧要的。 你不希望写出 "Hello, World", 并让它变成 Hello, World。 许多语言对空白做了区分, 即 token 之间的空白在 token 之间是无关紧要的, 但 token 内的空白(如引号字符串)是重要的。

然而, 它比这更微妙：在 SQL, Perl, Python, JavaScript 等语言中, 当一个类似于单词的 token 后跟着一个非单词的 token 时, 你可以省略空白, 或者反过来（例如 a+b 和 a + b 是相同的）。 然而, 禁止将两个类似于单词的 token 连接在一起而不留任何空白。 相反, 如果两个 token 之间存在空白, 那么空白的数量就无所谓了。^[39]

例如, 下面这两个 SQL 语句生成相同的解析树：

相反, 下面是一个语法错误, 因为它连接了类似于单词的 token 而不带任何空格：

Raku 定义了一个名为 ws 的正则表达式, 它是 whitespace 的缩写, 它按照前面的规则解析空白：任意数量的空白(空格、制表符、换行符, …​…​), 但至少有一个空白, 除非它位于单词边界。或者用代码表示, regex ws { <!ww> \s* }(其中 <!ww> 匹配除了单词内之外的任何地方)^[40]。

还有一个快捷方式可以帮助你避免在代码中到处使用显式的 <ws> 或 <.ws> 调用。^[41] 如果使用关键字 rule 而不是 regex 或 token 来声明正则表达式, 那么 Raku 会在你的正则表达式中使用空格的地方插入隐式的 <.ws> 调用。这与在正则表达式中使用 :sigspace 或 :s 修饰符具有相同的效果。

由于 ws 的定义使用了术语 \s*, 所以正则表达式中的单个空白可以匹配字符串中的任何数量的空白, 包括制表符、空格、垂直制表符等。

再次考虑我们的数学表达式, 我们可以编写以下正则表达式来匹配两个数字之和的最简单情况：

第二行相当于写为:

但可读性更强。最后两行都匹配成功了, 唯一的区别是它们匹配的空白:

插入的隐式的 <.ws> 调用并不完全适用于正则表达式中每一个空白的出现。特别是正则表达式开头的空白, 像在 :r 或 :s 这样的修饰符之后的空白,或者在开口花括号或开口圆括号之后的空白, 还有 &, && 和 || 之后的空白, 不会被替换为隐式 <.ws> 调用。一般的概念是, 规则解析匹配内部和匹配结尾的空白, 但不解析匹配开头的空白。

如果你使用 rule, 你必须意识到空白是重要的, 并且原子和它的量词之间的空白也有影响:

第一行打印的是「a」,而第二行打印的是「a a], 包括了最后一个 a。a 和 + 之间的空白被解释为 <.ws> 调用, 所以第二个 rule 等同于:

最后, 你需要注意的是, 就像正则表达式中的任何部分一样 隐式调用 ws 也会使你的匹配失败:

这里 a 和 b 之间的隐式 <.ws> 调用不匹配, 所以规则 a 作为整体也不匹配。

命名正则表达式提供了第一层抽象, 但我们往往需要更多层的抽象。大多数高级编程语言都有模块、命名空间、类, 甚至三者都有, 以管理函数和方法的重用。

Raku 也提供了这些更高级别的抽象, 并使它们可用于正则表达式中。Grammar 是一个类, 它提供了一些调用正则表达式的工具。那么正则表达式是这个 grammar 中的方法:

第一个 grammar 是用 grammar 关键字声明的, 后面是 grammar 的名称 IPv4Address。grammar 是一种自动添加类型为 Grammar^[42] 的父类, 并提供了一些方法, 如 parse 和 subparse 等。

grammar 的主体由花括号分割。 在主体里面, 我们使用 regex 或 token 关键字声明正则表达式。请注意, 我们省略了声明前面的 my 声明符, 因为现在正则表达式是作用域属于 grammar 的方法。

parse 方法调用名为 TOP 的正则表达式, 并隐式将其锚定到字符串的开头和结尾。相比之下, subparse 方法仅锚定到字符串的开头。parse 和 subparse 方法都接收一个可选的, 命名参数规则, 你可以用它来调用 TOP 以外的正则表达式:

这里 IPv4Address.parse($str, :rule<byte>) 失败了, 因为正则表达式 <byte> 不能匹配整个输入字符串, 并且 parse 隐式将正则表达式的结尾锚定到字符串的末尾。相反, subparse 匹配输入字符串的第一个数字。

在 grammar 内部, 调用同一 grammar 的另一个正则表达式, 其作用和外部一样; 带尖括号 :<byte>。但如果你想抑制捕获, 你必须使用一个点代替 & 符号: <.byte>。重命名也是一样, 因此 <octect=.byte> 会调用正则表达式 byte, 但产生一个名为 octect 的捕获。点(.)的使用类似于方法调用语法, 它也使用点号。

Raku 提供了两种重用面向对象代码的方法:继承和角色组合。因为 grammar 实际上是类, 所以这两种机制也适用于 grammar。

假设你想为 JSON^[44](也称为 JavaScript 对象表示法) 编写一个 grammar。json.org 的主页肯定会告诉你, 当解析一个值时, 你期望的是一个字符串、数字、对象、数组或字面量字符串、true、false 或 null。没问题, 你可以这样写:

这很管用, 但它的可扩展性并不是很好。假设你想解析一个扩展的 JSON 方言, 例如添加 2015-12-24 这样的无引号字符串形式的日期类型。你可以通过继承上一个例子中暗示的 JSON grammar 来实现, 编写一个 token date 来解析日期, 然后你必须覆盖 token value, 把父 grammar 中的所有备选项都列出来, 然后再列出你自己的。

这种重复不仅烦人, 容易出错, 而且还会使得同一个 grammar 无法进行多次修改。如果别人想编写另一个扩展, 添加不同类型的新值(比如说引用类型), 他们的扩展不会意识到你的扩展, 所以用户不能轻易地将它们混合在一起。

Raku 提供了一个解决这个问题的方法: proto regexes。原型正则表达式是一个正则表达式的集合, 它们一起构成了一个很大的备选项, 就像每个备选项都是由一个 | 来分隔一样。下面是我们将 JSON grammar 的一部分写成了原型正则表达式:

行 proto token {*} 引入一个带有名称 value 的原型正则表达式(或 token)。这就指示 Raku 将有更多的名称为 value 的正则表达式, 并加上一些小的补充。这些小的补充的形式是: sym <SOMETHING>, 帮助你和编译器将这些正则表达式分开。这种正则表达式的主体可以是你所知道的任何东西, 所以我们可以在这里实现, 而不是在 token value:sym<number> 里面调用 token number:

在每个单独候选项中, :sym<…​> 里面的名字可用作特殊符号 <sym> 使用。所以不要写成:

我们可以这样写:

以避免名称的重复。

让我们把这个例子稍作删减, 变成可运行的代码:

这是一个非常简约的 grammar, 只解析 JSON 值 true、false 和 null。我们的扩展使其解析 ISO 8601 格式的日期, 可以是一个添加了候选 token 的简单角色:

我们不需要在角色中声明 proto token value, 因为它会被混合到包含此声明的 grammar 中。

为了使用 DateValue 扩展, 我们可以基于 JSONValue 和角色生成一个 grammar:

这使用了 JSONValue 的继承, 也使用了 DateValue 的角色组合来生成一个新的 grammar, 现在可以解析 true、false、null 和 date 值。它产生了这样的输出:

正则表达式外的 ? 运算符强制使用布尔上下文, 这就是为什么我们在输出中看到 True 和 False, 而不是 Match 对象和 Nil。

我们可以避免显式地创建 grammar JSONValueWithDate, 而只需使用 but 操作符就地组合一个匿名的 grammar:

but 操作符在左侧创建一个类型或对象的副本, 对其应用角色, 并返回结果。

这两种方法都可以用来给 grammar 添加多个扩展:

现在, 由 JSONValue、DateValue 和 IntegerValue 组成的 grammar 可以解析所有四个示例输入字符串。扩展角色不需要考虑其他角色; 它们是可以自由组合的。

解析 JSON 子集的例子来自 JSON::Tiny^[45] 模块, 该模块使用可管理的 Raku grammar^[46] 解析 JSON。我们越来越接近于能够创建具有许多实际应用的可扩展 grammar。

Raku 提供了命名正则表达式以方便重用。为了简化词法分析, token 和 rule 关键字禁用了回溯, rule 关键字还会隐式解析空白。

由于正则表达式可以用作方法, 所以可以用面向对象编程中的强大技术来管理和重用正则表达式。Grammar 对正则表达式进行分组、继承和角色组合使它们可以被重用。

最后, proto regexes 确保了扩展可以以自然的方式进行, 而不会干扰 grammar 中相同位置的其他潜在扩展。

Grammar 实现了一种自上而下的解析方法。解析的入口点, 通常是正则表达式 TOP, 了解粗粒度结构和调用更多的正则表达式, 从而进入血淋淋的细节。递归也会涉及其中。例如, 如果你解析一个数学表达式, 则项可以是一对括号内的任意表达式。

这是一种自上而下的结构, 或者更准确地说是一种递归下降解析器^[48]。如果不涉及回溯, 我们将其称为预测性解析器, 因为在字符串中的每个位置, 我们都知道我们要找的是什么 - 我们可以预测下一个 token 是什么(即使我们只能预测它可能是一组候选者之一)。

所得到的匹配树在结构上完全对应于 grammar 中的正则表达式的调用结构。让我们考虑一下解析一个数学表达式, 它只包含运算符 *, + 和用于分组的括号:

从 grammar 本身来看, 你已经可以看到递归的潜力: sum 调用 product, product 调用 term, term 调用 group, term 再调用 sum。这样就可以对任意深度的嵌套表达式进行解析。

运行前面的示例, 会产生以下匹配对象:

如果你想知道某个特定的数字是如何解析的, 可以按照路径回溯, 查找当前行上面少缩进的行, 比如说, 数字 1 是通过 token number 解析的, 从 term 调用, 从 product 调用, 以此类推。

我们可以通过从 token number 中引发异常来验证:

这确实显示了回溯中的调用链, 最直接的上下文在最上面:

这个 grammar 只使用 token 和 rule, 所以没有涉及回溯, 而且这个 grammar 是一个预测性解析器。这是相当典型的。许多 grammar 在不涉及回溯的情况下, 或者只涉及到几个地方的回溯, 都能正常工作。

即使 grammar 是从上而下地工作, 但开发一个 grammar 也是自下而上地工作。Grammar 的整体结构通常从一开始并不明显, 但你通常对终端 token 有一个很好的想法: 那些直接匹配文本而不调用子规则的 token。在前面解析数学表达式的例子中, 你可能从一开始就不知道如何安排解析 sum 和 product 的规则, 但很可能你知道你在某个时候必须解析一个数字, 所以你可以从写作开始:

这样做虽然不多, 但也不是很复杂, 这也是克服程序员在遇到新问题领域的挑战时有时会遇到的写作障碍的好方法。当然, 只要你有了 token, 就可以开始写一些测试了:

现在, 你可以开始构建更复杂的表达式:

在测试的早期就加入空格是值得的。前面的例子看起来很无辜, 但最后的测试实际上是失败的。在 1 和 * 之间没有匹配空格的规则。在 <number> 和 + 量词之间的正则表达式中添加一个空格, 会使测试再次通过, 因为空格插入了一个隐式的 <.ws> 调用。

如果你开始时真的很简单, 并尽快抓住它们, 这些细微之处就很容易被抓住。相反, 如果你屈服于从上到下写下整个 grammar 的诱惑, 你可能会花很多时间来调试为什么一些看似简单的东西, 比如一个额外的空格会导致解析失败。

一旦你写出了基本的用于词法分析的 token, 你就可以进展到组合 token 了。通常, token 不会在其匹配的边界处解析空格, 所以组合它们的规则就是这样做的。

在上一节中的 MathExpression 例子中, 规则 product 直接调用 number, 尽管我们现在知道最终版本使用了一个中间步骤 - 规则术语, 它也可以解析括号中的表达式。引入这个额外的步骤并不会使测试无效。

我们已经编写了 product, 因为它在早期版本中匹配的字符串仍然匹配。当你开始使用一个处理语言的子集的 grammar 时, 引入更多的层数就会自然而然地发生, 而这个子集是你后来来扩展的。

正则表达式或 grammar 有两种失败模式: 当它不应该匹配时, 它匹配了(误报), 或者当它应该匹配时, 它没有匹配(漏报)。通常, 误报模式比较容易理解, 因为你可以检查结果的匹配对象, 看看哪一个正则表达式匹配了字符串的哪一部分。

有一个方便的工具来调试漏报: Grammar::Tracer 模块。如果你在一个包含 grammar 的文件中加载该模块, 运行该 grammar 会产生诊断信息, 可以帮助你找出匹配出错的地方。

请注意, 这只是为开发者提供的诊断工具; 如果你想给终端用户提供更好的错误信息, 请阅读第十一章的改进建议。

你需要安装 Raku 模块 Grammar::Debugger, 其中也包含 Grammar::Tracer。如果你使用的是 moritzlenz/raku-regex-alpine docker 镜像, 这已经为你完成了。如果你通过其它方式安装了 Raku, 你需要在命令行上运行:

如果尚未安装 zef, 请按照 zef 在 GitHub 页面的安装说明进行安装^[50]。

让我们来看看 Tadeusz Sośnierz 所编写的 Raku 模块 Config::INI^[51]。它包含以下 grammar^[52](这里稍作修改):

假设我们想了解为什么它不能解析下面这段输入文本:

所以, 在 grammar 之前, 我们插入一行:

然后, 添加一小段代码, 调用该 grammar 的 .parse 方法:

这样会产生一个相当大但信息量很大的输出。

每个条目都由一个正则表达式的名称组成, 比如 TOP 或 eol(表示行的尽头), 然后是它所调用的正则表达式的缩进输出。在每一个正则表达式后面都有一个星号(*)和 MATCH(匹配), 后面跟着正则表达式匹配的字符串片段, 如果正则表达式失败则为 FAIL。

让我们逐条看一下输出, 即使它是以一个大块的形式出现。

这告诉我们, TOP 调用了 eol, 但匹配失败了。对 eol 的调用使用 * 来量词化, 这不会导致 TOP 的匹配失败。 然后 TOP 调用 key, 匹配文本 "a" value 匹配文本 "b"。然后 eol 正则表达式继续匹配换行符, 第二次尝试失败(因为一行中没有两个换行符)。这会导致初始的 keyval token 匹配成功。第二次调用 keyval 匹配很快就成功了(在调用 key 的时候)。然后, token toplevel 的匹配成功进行, 消耗了字符串 "a = b\n"。

到目前为止, 这一切看起来都和预期的一样。现在我们来看看第二大块的输出:

TOP 接下来调用 section, 其中 token header 成功匹配了字符串 "[foo]\n"。然后, keyval 调用 key, 匹配了整行 "c:d\n"。等等, 这不对劲吧, 我们可能会期望 key 只匹配 c。我当然不会想到它会匹配结尾的换行符。因为输入中没有等号, 导致正则表达式引擎根本不会调用正则表达式 value。但由于 keyval 又是用星 * 量词进行量化, 所提调用的正则表达式部分的匹配成功只是匹配到了标题 "[foo]\n"。

下面是 Grammar::Tracer 输出的最后一部分:

从这里开始就是 FAILs。第二次调用 section 再次尝试解析一个标题, 但它的下一个输入仍然是 "c:d\n", 所以它失败了, 就像 token TOP 中的字符串末尾锚点 $ 一样, 方法解析中的整体匹配失败。

所以我们已经知道正则表达式 key 匹配了整行 c:d\n, 但是由于后面没有等号(=), token keyval 无法解析这一行。由于没有其他的正则表达式(特别是没有 header)与之匹配, 这就是匹配失败的地方。

从这个例子中我们可以看到, 尽管我们必须仔细查看它的输出来定位, 但 Grammar::Tracer 可以让我们确定解析失败的位置。当你在终端上运行它时, 你会自动得到彩色的输出, FAIL 是红色的, MATCH 是绿色的, 而 token 名则是白色的(而不是通常的灰色)输出。这使得从底部(失败的匹配通常会留下红色的 FAIL)到后面的成功匹配, 然后在匹配和失败之间的边界附近寻找。

由于调试会带来很大的心理负担, 而且 Grammar::Tracer 的输出往往会迅速增长, 所以一般建议将失败的输入减少到最小的样本。在前面描述的案例中, 我们可以删除输入字符串的第一行, 并保存十行 Grammar::Tracer 的输出来查看。

如前所述, 解析不重要的空白的常用方法是调用 <.ws>, 通常是通过在规则中使用空白处来隐式地解析。默认的 ws 实现, <!ww>s*, 适用于多种语言, 但它有其局限性。

在很多文件格式和计算机语言中, 有大量的空白空间会被 <.ws> 占据。这些文件包括 INI 文件(其中换行通常表示一个新的键/值对)、Python 和 YAML(其中缩进用于分组)、CSV(其中换行表示新的记录)和 Makefile(其中缩进需要使用制表符)。

在这些情况下, 最好的做法是在自己的 grammar 中覆盖 ws, 只匹配不重要的空白。让我们来看看第二个最小化的 INI 解析器, 它是在上一节中描述的基础上独立开发的。

这个解析器可以解析像这样的简单的 INI 配置文件:

请注意这个 grammar 是如何使用两个路径来解析空白的: 一个自定义的 ws token, 它只匹配水平的空白和制表符, 另一个单独的 token eol, 它匹配(重要的)断行符。eol token 也会吞噬其他仅由空格组成的行。

如果一种语言支持注释, 而你不希望它们出现在你的解析树中, 你可以在你的 ws 标记中, 或者在 eol(或你的等价物)中解析它们。具体是哪一种, 要看注释在什么地方被允许。在 INI 文件中, 它们只允许在键/值对之后或单独的一行中出现, 所以 eol 是最合适的地方。相比之下, SQL 允许在每一个允许空格的地方都有注释, 所以在 ws 中解析它们是很自然的。

一些比较有趣的数据格式和语言需要解析器来存储东西（至少是暂时的）, 以便能够正确解析它们。C 语言和其他受其语法启发的语言(如 C++ 和 Java)就是一个例子。这些语言允许变量声明的形式为变量=初始值, 就像这样。

这是有效的语法, 但前提是第一个单词是类型名。相反, 这将是无效的, 因为 x 不是一个类型:

从这些例子中可以清楚地看出, 解析器必须有一个它所知道的所有类型的记录。因为用户也可以在代码文件中声明类型, 所以解析器必须能够更新这个记录。

许多语言还要求在引用符号(变量、类型和函数)之前必须声明这些符号。这也需要 grammar 来记录哪些符号已经声明了, 哪些没有声明。这条记录了什么已经声明了什么（以及什么是类型或不是类型, 可能还有其他的元信息）的记录被称为符号表。

与其解析完整的 C 语言编程语言, 不如让我们考虑一个最小化的语言, 它只允许对数字列表和变量进行赋值。

如果我们不强加声明规则, 那么写一个 grammar 就相当容易了:

现在我们要求只有在变量被赋值后才能使用, 那么下面的输入将是无效的, 因为 b 在第二行中没有声明, 但在第二行中使用了 b。

为了维护一个符号表, 我们需要三个新的元素: 符号表的声明, 一些代码, 当赋值被解析后, 将变量名添加到符号表中, 最后是检查我们在术语表中遇到变量时, 是否已经声明了变量。

在 token TOP 中, :my %SYMBOLS 声明了一个变量。正则表达式中的声明以冒号(:)开始, 以分号(;)结束。在这之间, 它们看起来就像 Raku 中的普通声明一样。%sigil 表示变量是一个散列 - 字符串键与值之间的映射。而 使它成为一个动态变量 - 一个不限于当前作用域的变量, 也可以被当前作用域中调用的代码(或者是正则表达式, 也是代码)看到。因为这是一个非常大的作用域, 所以习惯上选择大写字母的变量。

第二部分, 将符号添加到符号表中, 在规则语句中发生。

在花括号里面是普通(非正则表达式)的 Raku 代码, 所以我们可以用它来处理 %*SYMBOLS 这个散列。表达式 $<identifier> 访问变量名称的捕获^[53]。因此, 如果这条规则解析了变量 a, 那么这条语句将 %*SYMBOLS{'a'} 设置为 %*SYMBOLS{'a'}。= True。

代码块的位置是相关的。把它放在 termlist 调用之前, 意味着在解析 termlist 时已经知道这个变量, 所以它接受像 a = 2, a 这样的输入, 如果我们先调用 termlist, 这样的输入会被拒绝。

说到拒绝, 这部分发生在 token variable 中, term 现在调用新的 token variable(之前直接调用 identifier), 变量验证之前已经声明了标识符。

你可能还记得在前面的例子中, <?{…​}> 执行了一段 Raku 代码, 如果返回的值为 false, 则解析失败。如果 $<identifier> 不在 %*SYMBOLS 中, 就会出现这种情况。这时, token 的非回溯性就很重要了。如果被解析的变量是 abc, 而变量 a 在 %*SYMBOLS 中, 那么回溯将尝试对 <identifier> 进行更短的匹配, 直到匹配到 a, 然后成功。^[54]

因为 %*SYMBOLS 是在 token TOP 中声明的, 所以当你尝试从 grammar 之外调用 TOP 以外的规则时, 你必须重复这个声明。如果没有像 my %*SYMBOLS; 这样的声明, 那么像:

死于:

Raku 的 grammar 是一种声明性的方式, 可以写出递归下降的解析器。在没有回溯的情况下, 它们是预测性的；在每一个点上, 我们都知道该期待什么样的 token 表。

Grammar 的递归性质带来了左递归的风险, 这种情况下, 递归路径不消耗任何字符, 因此会导致无限循环。

尽管 grammar 的自上而下的性质, 但编写 grammar 通常是自下而上: 从词法分析开始, 然后再往上解析更大的结构。

复杂的语言需要额外的状态来实现成功和精确的解析。我们已经看到了如何使用动态变量来保存状态。

在 grammar 中, 它们的作用域如何与输入中的词法作用域相对应, 以及如何编写符号表并将其集成到 grammar 中。

Grammar 和匹配对象自带两个特性, 为提取数据提供了更有弹性和可扩展性的方法。第一个比较简单是, 是你可以将任意数据结构附加到 Match^[56] 对象上, 随后通过 .made 属性访问它:

如果匹配对象在特殊变量 $/ 中, 也可以调用 make DATA:

你大概可以看到这一点: 你可以构建一个数据结构, 它将成为最终 AST 的一部分, 然后用 make 将其附加到匹配对象上。

你要在哪里做呢? 一个选择是内联代码对象, { …​ }, 但这将 grammar 与 AST 生成代码紧密地耦合在一起。这就是第二个特性的用武之地: action 对象。

action 对象是你传递给 grammar 上的 .parse 或 .subparse 调用的对象。从此以后, 每当一个命名正则表达式成功匹配时, 正则表达式引擎为你调用一个方法; 它搜索和该正则表达式同名的方法, 如果存在同名方法, 就用匹配对象作为参数调用它。 如果这样的方法不存在, 则不会发生任何事情, 也不会产生错误。

下面是是一个在解析数学表达式时对其进行求值的 action 示例:

你应该已经从上一章中熟悉了 MathExpression grammar 了; 新的东西是另一个类 MathEvalAction, 对于 grammar 中的每个正则表达式, 它都有一个方法与之对应。每个方法都以 $/ 作为唯一参数, 将匹配对象绑定到 $/。它调用 make 来附加内容到这个匹配对象上。

这个类的想法是, 每个方法都会给当前匹配对象附加一个与当前匹配对象对应的数字。因此, 如果它解析字符串 2 *(1 + 4), 它就会将数字 2 附加到解析了 2 的匹配对象上。它对数字 1 和 4 做同样的操作, 然后将 sum 的结果 5 附加到解析了 1 + 4 的匹配对象上, 然后再次将数字 5 附加到解析了 (1 + 4) 的匹配对象上, 最后它对 product 进行求值, 并将数字 10 附加到最上面的匹配对象上。

从下往上读, number 方法通过调用匹配对象上的 Int 方法将字符串转换为数字。它将得到的整数附加到匹配对象上。匹配 group 只需从 $<sum> 中获取匹配对象中的附加值, 并将其附加到自己的匹配对象上。

术语 rule 与两个备选项中的一个匹配。$/.values 返回一个所有匹配对象的列表, 它总是一个元素。make $/.values[0].made 因此将从任何一个匹配中的附加值传播, 并将其附加到自己的匹配对象上。

规则 product 解析由星号分隔的项的列表。同名的 action 方法取每个项的附加值, 并将它们相乘。$<term>».made 中的 ». 语法在列表 $<term> 的每个元素上调用 made 方法, 并返回一个包含所有结果的列表。如果你无法用键盘打出 » 字符, 可以改用 >>, 这样这就变成了 $<term>>>.made。

[] LIST 在 LIST 的每个元素之间插入 运算符, 从而计算出所有这些值的乘积。

由于规则 sum 和 product 具有相同的结构, 所以它们的 action 方法也是如此。sum 使用 [+] 来创建下一级的匹配对象的所有数字之和。

最后, token TOP 只是调用 sum, 所以 action 类中的方法 TOP 只是传递附加在 $<sum> 上的值。

下面是一个匹配树, 在右边的列中注解了每个 .made 的值:

在每个分支中, 缩进最多的匹配是那些 action 方法先被调用的匹配, 所以 number 在 term 之前调用, term 在 product 之前调用, product 在 sum 之前调用。 这种排序保证了每个 action 方法都可以依赖于子匹配上的 .made 属性的存在。

编写 action 方法只需要知道相应的正则表达式捕获的内容以及它们的 .made 属性包含的内容就可以了。在 action 中, 我们不需要深入研究匹配树的嵌套结构。如果以这种方式构建 action, 则可灵活应对 grammar 的变更。每当你修改正则表达式时, 你都可以放心, 你只需要触及与之相对应的 action 方法就可以了, 你永远不必担心另一个 action 方法会依赖于你刚才触及的正则表达式。

当你为 proto token 编写 action 方法时, 你应该注意, action 方法是针对成功匹配的候选者调用的, 但不是针对整个 proto 的。所以, 如果你的 grammar 包含了如下行:

那么 grammar 引擎可能会为你调用一个名为 value:sym<string> 或 value:sym<number> 的方法, 但不是 value 方法。

上一节说明了 action 对象和方法的机制, 它构建一个类似于 AST 的东西, 但它不是树。因为树是解析成功后的最常见结果, 所以我想介绍另一个 action 类, 在解析过程中创建一个抽象的语法树, 同样的 grammar 类在解析过程中会创建一个抽象的语法树。

为了省去单独编写一个树类的麻烦, 我们将使用一个嵌套数组来表示树。树的第一个元素是运算符; 其他元素是操作数。因此, 对于表达式 1 + 2 + 3, 结果是 ['+', 1, 2, 3]。由于嵌套表达式用嵌套括号表示, 所以我们不需要运算符来表示一组圆括号: 因此, 表达式 2 (3 + 4) 被表示为 ['', 2, ['+', 3, 4]]。

让我们来看看 action 类, 以及如何使用它:

这段代码(连同上一节中的 grammar 定义)产生的输出是:

TOP、term、group 和 number 的 action 方法与前面讨论的 action 类中的 action 方法相同。有趣的部分是 sum 和 product 的 action 方法。我们来看看后者, 这两个方法的代表:

如果我们只使用 make ['', |$<term>».made] 作为 product 方法的主体, 那么 1 + 2 的 AST 会以 ['+', ['', 1], ['*', 2]] 的形式出现, 因为每个 sum 都解析一个 product 表达式。我们不希望出现额外的单元素乘法, 所以我们做了一个特殊情况。如果只解析了一个项, 那么只返回该项。否则, 返回一个由运算符组成的数组, 然后返回所有项的 AST。

由于这种特殊情况使用了两次(对于 sum 和 product), 所以将其分解成一个方法是有意义的, 我称这个方法为 reduce。reduce 方法使用语法 [$op, |@list] 来创建一个数组 $op 与 @list 的元素相连接。| 扁平化 @list; 如果我们不使用它, 结果将是 ['+', [1, 2]] 而不是 ['+', 1, 2]。

上一节中的 action 类是一个方法的集合, 但他们并不保留任何状态。可以说, 它们不是"真正的"对象。实际上, 我们可以把 action 类上的 .new 调用移除, 直接把类传递给 grammar, 这样例子就可以像以前一样工作了。状态是正在构建的 AST, 它存储在匹配对象的 .made 属性中。

这是一种常见的模式, 但不一定要这么做。作为 action 对象的对象是普通的 Raku 对象, 你可以用它做任何你想做的事情。你可以在它们中存储数据, 甚至可以在多次调用 grammar 的 .parse 方法时重用同一个 action 对象。

读到这里, 你可能会想知道我们为什么要费尽心思地去做这些事情。在前面的例子中, 在动态变量中保存符号表, 而不是使用 action 对象。这里的区别在于, 符号表影响了解析的结果; 引用一个未声明的变量使匹配失败。Grammar 是要独立于 action 对象的, 所以你可以修改甚至交换 action 类而不影响 grammar。

下面是 grammar 的一个例子, 它解析单个变量赋值, 并将这些变量收集到一个散列中:

在这里例子中, has %.define 定义了一个公共属性; 一个附加在对象上的状态, 可以从外部访问。语法: $actions 是 actions ⇒ $actions 的简写。

这种使用有状态的 action 对象和一次一项地解析部分输入的模式对流处理非常有用; 如果你在接收数据时, 需要在收到完整的输入之前访问结果, 或者如果你的系统连续运行, 并且有一个不断的输入流, 那么这种模式非常有用。

如果你为你的 grammar 的 parse 调用提供一个 action 对象, 那么就会调用与正则表达式同名的方法。你可以用它来从你的 grammar 中构建一个抽象语法树。此外, 你可以在这个 action 对象中保留状态, 并使用这种机制来解析零散但相关的输入。

在 Raku 中, 没有一个通用的机制可以产生良好的解析错误信息, 我不知道怎么会有这样的机制。原因是, 即使是在成功的解析运行中, 个别的正则表达式和 token 失败也是很正常的。

让我们只考虑一下早期的 grammar VariableLists 中的两行:

假设这与字符串 1,a 相匹配, token term 首先尝试将 identifier 和 number 与字符串匹配。identifier 正则表达式匹配失败了, 但是 number 匹配成功了。然后, termlist 本身匹配了逗号, 再次轮到 term。这一次, identifier 分支成功匹配了字符串 a, number 匹配失败了。最后, termlist 尝试匹配下一个逗号, 也失败了, 但整个 termlist 匹配成功。

在这个例子中, 我们已经看到了三个失败的匹配作为成功匹配的一部分。那么这样的"正常"失败的匹配与致命性地导致整个解析失败的匹配有什么区别呢？

从技术上讲, 一个致命的失败的正则表达式是指失败后一直向上传播到 TOP 的正则表达式。但这并不能帮助我们创建出好的错误信息。当它失败时, 我们还不知道它是否会一直向上传播。而一旦它传播到 regex TOP, 就来不及从失败的匹配中提取有用的信息了。

对匹配失败的不同视角可以提供更多的启示。基本上有两种情况下, 匹配会出错。一种情况是当我们开始解析某个东西时, 我们只能匹配到它的第一部分, 而不能匹配到其他部分。在数学表达式的情况下, 这可能是一个开头的括号, 而没有相应的结尾括号, 或者是没有在任何表达式后面跟加号。第二种情况是预期有一个或多个备选方案, 但都不匹配。例如, 一个 JSON 解析器可能期待一个对象、数组、数字或字符串, 但输入的字符是 $ - 在引用的字符串以外的 JSON 中, 这个字符根本不是有效的 JSON。

顺序替代, 可以让你创造出好的错误信息。一般的模式是这样的。

这个正则表达式试图匹配关闭的括号。如果这样做不成功, 它不是默默地失败, 而是使用一个代码块 {…​} 使用内置的 die 函数抛出一个异常。异常会中止解析, 如果解析方法的调用者没有捕捉到异常, 程序会退出, 并返回一个匹配不成功的返回代码。为了成为改进错误报告的有效工具, 我们必须将这种模式应用到更多的地方。

只在最琐碎的输入中描述错误就足够了。在任何多行输入中, 我们需要指出错误的位置；否则, 用户将很难修复问题。

我们可以通过匹配对象 $/ 来获取位置, 然后用它来计算行号。因为这是我们在相当多的地方都会用到的东西, 所以最好把这个逻辑提取到一个方法中。然后我们可以用与调用正则表达式相同的语法来调用这个方法, 只是在参数周围加上一对括号。

它以前是:

现在是:

注意, 我们用调用自定义错误方法代替了直接调用 die 函数。这个方法有几个小技巧来确定行号：.target 方法返回 grammar 当前匹配的字符串, self.pos 方法提取当前的解析位置。self.pos 相当于 $/.to, 只是后者只在解析结束时, 或者是在捕获的时候才会起作用。

这些方法是从哪里来的？通过声明一个类型为 grammar, 它自动获得父类 Grammar^[57](提供 parse 和 subparse 方法), 而后者又继承自 Cursor^[58], Cursor 提供了 .target 和 .pos 方法。

Str.lines^[59] 方法将一个字符串分解成一个包含行数的列表, 在这个列表上调用 .elems 会产生行数。对于一个没有任何行的字符串, 这个方法会产生行数。请注意, 即使是最铁杆的 C 语言程序员也会计算从 1 开始的行数(而不是0), 所以从 lines.elems 中的数字符合我们的行数目的。

示例代码的输出如下:

错误报告正确地报告为第2行的错误, 因为输入字符串中的 \n 引入了断行。

我们在上一节中看到的 error 方法是一个很好的第一近似法, 但我们可以做的事情还有更多, 以提高它的精度。

第一件事很简单。在许多情况下, 一个隐式的 <.ws> ` 调用可以匹配 `[ <something> || <error(…​)>] 块之前的空格。在 grammar 中, ws 可以匹配换行, 这可能会把报告的错误位置往下移, 这与我们对错误位置报告的直观理解不符。

我们可以通过删除 $parsed 字符串中的尾部空格来弥补这个问题:

另一个改进策略是在错误消息中提供一些上下文。例如, Raku 解析器会在错误位置周围打印出源代码, 并在错误位置上标记一个弹出符号 ⏏。

我们在自己的 grammar 中也可以这样做。

这个版本的 error 方法构造了一个上下文字符串, 其中包含了错误位置前后的十个字符(虽然它使用 $chars max 0 来防止负索引)。它产生的输出是这样的。

或使用输入字符串 "1 + 2 5", 你得到:

到目前为止讨论过的技术依赖于手动插入 || <error(…​)> 片段到 grammar 中。如果你想避免这种情况 - 牺牲一点错误信息的清晰度, 你可以使用另一种技术。即使不是这样, 你也可以将它与显式错误报告结合起来使用。

就像每当海平面或河流的水位达到一个新的记录时, 高水位标志就会被推高一点, 我们可以记录下我们的 grammar 达到的最远的位置。我们可以通过一个动态变量来做到这一点, 如果 self.pos 大于变量的当前值, 我们将其设置为 self.pos。这个高水位标志就构成了我们错误位置报告的基础。

一个方便的地方是 ws token, 因为它已经在很多地方被调用了, 而且它是一个自然的原始 token 的分界符。每当正则表达式位置达到一个新的高水位标记时, 我们还可以记录下调用 ws 的规则名称。这些信息可以通过 callframe^[60] 内置的子例程获得。

callame 函数从父类(在语法中是 Grammar)调用 ws 方法, 传递的参数与当前收到的方法相同。换句话说, 你在这里看到的 ws 方法包装了默认的 ws 正则表达式。我们可以通过调用这里的 grammar 中的任何其他命名的正则表达式, 例如用 self.customws 方法来委托给 grammar 中的任何其他命名的正则表达式。

这个 ws 方法假设动态变量 $*HIGHWATER 和 $*LASTRULE 已在某处声明。如果我们在 token TOP 中这样做(如前面的例子所示), 我们遇到了一个问题: 一旦解析了失败, 变量不再可用于报告错误。再次一个包装器来拯救: 我们可以将所有 grammar 都有的 parse 方法包装起来:

签名中的语法 |c 可以捕获所有剩余的参数, 包括命名参数和位置参数。这确保了像 MathExpression.parse($string, rule ⇒ 'multiplication') 这样的调用可以继续工作。callsame 然后将相同的参数传递给原始解析方法。最关键的部分是匹配失败时调用 error 方法。当然, error 方法还需要一些摆弄才能使用 $*HIGHWATER 和 $*LASTRULE 动态变量。

这个 error 方法使用 $*HIGHWATER 代替 self.pos 来确定解析失败的位置, 而 $*LASTRULE 则用于报告最后一次解析规则的进展。

这里还有一个值得注意的变化：error 方法不是访问 self.target, 而是获取目标字符串作为参数。这是由于 grammar 力学中的一个细节, 我们到目前为止已经略过了。当你调用 SomeGrammar.parse(…​) 时, 这是对类型对象 SomeGrammar 的方法调用。但是 grammar 引擎需要在某个地方保留状态, 所以方法 parse 会创建一个 grammar 的实例 - 这与你可以在正则表达式调用的方法内部的 self 中访问的实例是一样的。这个细节很重要, 因为解析完成之后, 方法 parse 才调用 error, 所以实例就没有了。试图调用 self.target 或 self.pos 时, 会死掉, 并打印消息 Cannot look up attributes in a MathExpression type object。

这种基于高水标的错误报告正确地识别了 1+ 为未完成的和, 1* 为未完成的乘法, 以及 (1 为不完整的组表达式。

解析匹配的定界符对与它们之间的一些内容, 这很常见, 所以 Raku 有一个特殊的语法。与其这样写:

不如写成:

这里的 ~ 是一个解析器组合器, 它是对下面的 token 进行重新排列。在这个例子中, 视觉上的好处并不大, 但如果分隔内容的正则表达式较长, 那么把分隔符靠得更近一些就好了。

更重要的是, 如果找不到闭合的分隔符, 正则表达式引擎会调用一个叫做 FAILGOAL 的方法。在默认的实现中, 这只是使匹配失败。我们可以覆盖这个方法来产生一个错误信息。

FAILGOAL 方法的参数是正则表达式的源代码。匹配结束分隔符的部分。trim^[61] 方法删除了周围的空白, 其输出结果被送入本章前面提到的 error 方法的一个版本中。

输出结果如下:

对于哪种类型的项目应该使用哪种错误报告技术, 没有硬性规定。唯一的规则是, 实际使用你的 grammar 的人越多, 你就越应该在错误信息上下功夫。

你也可以把所有这些技术结合起来：在你需要的地方使用 [<expected> || <error('…​')>] 模式, 在你需要的地方放一个 FAILGOAL 方法, 在你没有明确安装断言的情况下, 使用高水标记技术来获得一个好的错误位置, 以获得更好的错误报告。

在本章后面的例子中, 你可能会觉得不适应, 因为在本章后面的例子中, 现在 grammar 的源码有一半以上的内容是专门用来报错的。但我们一开始就使用了一个相当简单的 grammar, 这就人为地缩小了 grammar 的规模。

此外, 大部分的错误报告代码都是相当通用的, 可以被分解成一个角色, 并在许多 grammar 中重复使用。这就是 Grammar::ParseError^[62] 模块所提供的功能。

最后, 我想说的是, 好的解析错误是足够重要的, 值得这样的关注。^[63]

从失败的解析过程中生成良好的错误信息并不容易, 因为失败的正则表达式是解析过程中正常的一部分。因此, 只有在某一时刻, 我们决定提交一个解析结果, 并在该承诺没有成立时产生错误消息, 我们才能产生错误消息。

这个承诺可以是显式的, 即在其第二个分支中触发异常的顺序选择的形式。或者, 我们可以在规则解析空白时, 使用高水标记方法, 使其隐式化。

最后, ∼ 解析器组合器允许你匹配一段被分隔符封住的输入, 并提供了一个钩子, 当闭合的分隔符不匹配时, 可以改善错误信息。

书面英语是以字母表为基础的，通常是一组字母对应于音素(口语中的元素)。

Abjads 或辅音字母的结构类似，但只包含辅音。可能有元音标记，也可能没有元音标记，在说单词的时候，这些标记表明元音应该插入哪里，但这些标记一般不表明应该插入哪个元音。阿拉伯语和希伯来语都属于这一类，一些古代北非和西亚的文字也是如此。

音节表是一种书写系统，每个音节都有自己的字符。一个著名的例子是平假名，它是日语书写系统的一个组成部分。

相比之下，表意文字传达的是一种思想或意义。在中国的书写系统中，它们往往与音节字结合在一起，形成了几千个字符。

不同的书写系统有几个地方会影响到程序员如何处理文字处理：你不能认为文字实际上是由字母组成的。一般来说，文本分割(将文本分割成单词、句子和其他单位的过程)是针对特定语言的。并非所有语言和书写系统都使用空格来分隔单词，甚至根本就不使用空格来分隔单词。有关更多信息，请参阅 Unicode 技术报告中关于文本分割的内容^[64]。

内置的字符类如 \d 和 \w 可以匹配所有脚本中的字符，而不仅仅是拉丁文脚本。这意味着，如果你使用 \d+ 来匹配一个数字，它可以匹配 42 和 ٤٢(这是东阿拉伯语数字^[65])。虽然这可能会让人感到惊讶，但将字符串 "٤٢" 转换为数字就像我们的"正常"阿拉伯数字一样。

计算机将文本存储为一系列的字节。UTF-8、UTF-32 或 ISO-8859-1 等编码描述了一个字节或一串字节如何映射到一个代码点。

代码点是 Unicode 联盟对人类语言中使用的字符的描述。它由一个介于 0 到约 110 万之间的数字，以及使用大写 ASCII 字符的字符描述组成，如 GREEK SMALL LETTER OMICRON。Unicode 属性数据库还记录了更多的信息，如该字符是否是字母、小写字母、是典型的从左至右书写的一部分等等。

自然语言和书写系统的多样性意味着我们对语言的许多假设（通常是隐含的）并不成立：不是每一个逻辑或视觉字符都是一个单一的代码点，不是所有的单词都是由字母组成的，也不是所有的单词都是由空格分隔的，这只是其中的几个例子。

Raku 提供了一些安慰，它将字素簇作为单个字符来处理，并在字符类中提供了对 Unicode 属性匹配的支持。

符号表达式(Symbolic Expressions)，也就是 S-Expressions，是 Lisp 程序设计语言中使用的一种树形嵌套列表的记号。在 S-表达式中，列表是用括号分隔的，列表中的元素用空格分隔。

对应于 Raku 数据结构:

列表元素通常被称为原子。原子可以是一个未引用的标识符，通常可以包含各种标点符号。例如 (+ 1 2) 就是 1+2 的 Lisp 表达式。你可以使用双引号来引用包含空格的原子。

在 Lisp 编程语言大家庭中的大多数方言中，大多数方言都使用 S-表达式来处理程序代码和数据结构。但是，它们在 S-表达式中允许的内容是不同的。有的允许使用浮点字面量，有的则在标识符中允许使用哪些字符。

如果你拥有的只是一把锤子，那么一切看起来都像钉子一样^[67]。 如果你在工作中使用一个闪亮的新工具，比如正则表达式和 grammar，你往往会忽略了使用其他工具来解决问题的选项。

本着这种精神，我想重温一下之前的数学表达式解析的例子，这次在 grammar 中做的少一些，更多的部分在随附的代码中。Grammar 的这次迭代并没有为每个优先级引入一个新的解析级别，而是完全忽略了优先级，只是简单地解析了一个备选项和运算符的列表。然后，action 方法使用运算符优先级表来创建相应的树。这被称为运算符优先级解析器，也简称为 OPP。

这种方法有两个主要的优点。它使得在两个现有的级别之间插入一个优先级更容易，而且 grammar 的扁平化结构使得解析速度更快。

Python、YAML、CoffeeScript 等编程语言和数据格式都使用缩进的方式来编码程序或数据的结构。例如，这个 Raku 程序:

在 Python 3 中会是这样的:

在一个以冒号(:)结束的行之后，下一行必须比上一行缩进更多。所有与第二行有相同缩进的行都属于这个块。如果一行的前导空格比前一个区块少，那么这就完成了所有开放的区块的前导空格较多的区块。

Python 或 YAML 的完整 grammar 在这本书中会有太多的内容，所以让我们来探讨解析基于缩进的语言背后的概念，而不需要考虑大多数不相关的复杂问题。

我们在这里要解析的语言是 Python 的一个小子集，我给它取名 Pythonesque。它包含了包含数字、变量和常用的中缀运算符的表达式，以及带有缩进体的 if 语句。if 语句可以嵌套。

下面的代码是用 Pythonesque 编写的一个小程序示例。

最上层开始时缩进为零，第一层缩进至少使用了一个空格（这里是四个空格），第二层必须比第二层进一步缩进（这里是十个空格）。

本章已经向你展示了现实世界中用于处理现实世界数据的解析器的元素：递归、运算符优先级解析器，以及基于缩进级别的结构解析。最后一个例子还展示了在递归和代码之间的相互作用中的取舍。

在本书的整个过程中，你已经了解了关于 Raku 的基本知识，Raku 正则表达式的构建模块，正则表达式和 Raku 代码如何相互作用，以及捕获，它提供了一种从正则表达式匹配中提取信息的方法。

本书中关于正则表达式机制和技巧的章节已经让你了解了正则表达式的工作原理，以及如何使用它们来解析常见的数据格式。语法允许你结构化和重用重构 grammar。action 对象机制方便了对结果匹配的访问，而关于错误报告的讨论则说明了当匹配失败时该怎么做。

有了前几章的背景知识和本章的应用，你应该能够编写自己的 grammar 和解析器了。在此，我想用 Perl 的创造者、Perl 6 的发明者 Larry Wall 的一句话来告诫大家：要有适量的乐趣！在这里，我想说的是，你应该能在本章中找到自己的乐趣。