Google SoC 系列:ANTLR v3 Ruby 分析器

XRuby 在努力创建一种编译器，能将 Ruby 编译成 Java 字节码。当然，编译器需要一种分析输入语言的方法，XRuby 团队用流行的 ANTLR 分析器产生器创建了他们自己的 Ruby 分析器。分析器产生器的作用是接收一门语言的文法并产生代码以分析该语言。使用 ANTLR 意味着文法和分析器的创建工作必须从零开始，这不同于 JRuby 的方法。在 JRuby 里，Ruby 分析器使用了另外一种叫做 YACC 的分析器产生器，而且 JRuby 选择复用该文法并使用 Yacc 的 Java 端口产生其分析器。

当被问到 Ruby 是否是一个分析起来比较困难的语言时，Wang Haofei（从事该 Google Soc 项目并且是 XRuby 团队的一员）做出了如下解释：

是的。该语言有许多模棱两可的地方。比如，“<<”可能是左位移操作，也可能是 heredoc 的起点。区分这两种情况需要维护状态（依赖上下文）： http://seclib.blogspot.com/2005/11/distinguish-leftshift-and-heredoc.html 其它像 ID/ 函数的模糊性，字符串表达式替换，heredoc 等等都很棘手。

当提到困难时，一个不错的问题是离目标还有多远。Wang Huofei：

XRuby 第一个公开发行版已经可以处理全部 ruby 标准类库和 Ruby on Rails（没有在对最新版做测试）： http://seclib.blogspot.com/2006/02/first-release-of-rubyfront.html 自此以后，Xue 修正了一些 bug，总的来说 XRuby 很稳定。在 SoC 项目进行过程中我们将编写和运行更多的测试，以帮助我们发现一些未知的问题。

Xue Yong Zhi 是该 SoC 项目的指导者，而且也是 XRuby 团队的成员。

该 Soc 项目的一个主要部分是将现有的分析器迁移到 ANTLR v3 上。Wang Huofei：

1. ANTLR v3 对 v2 进行了重写，通过 LL(*) 分析大大提高了分析能力，v2 的分析能力不但弱很多（有限的 LL(k)）而且还迫使我不得不花时间去处理一些问题。基于 ANTLR 的分析器比别的分析器更容易维护，迁移到 v3 将帮助我们把分析器做得更好更清晰。
2. ANTLR v3 将来应该有 Ruby 后端支持，所以我们可能会用 Ruby 编写 Ruby 分析器。
3. ANTLR v3 的性能更好。

上面第二点十分有趣。Ruby 缺少一个用 Ruby 写的 Ruby 分析器。编写处理 Ruby 代码的工具是一个问题。用 Ruby 写代码分析、重构工具和自动重构、格式程序等等甚至更多的工具并非不可能，但是很困难，因为还没有用 Ruby 代码分析 Ruby 源码的先例。有些工作，像 Ryan Davis 的分析树，用的是Ruby 解释器的分析器（通过一个本地扩展）来获得Ruby 源码的抽象语法树（AST）。AST 是一颗代表Ruby 源码的树，分析器工具必须了解代码的结构。然而，分析树不是一个完整的解决方案，因为当前的版本没有给出树上各个节点的源码位置。显然，像重命名一个Ruby 源文件中的标识符这样的重构算法，需要知道标识符的位置在哪儿。

由于各式各样的Ruby IDE 问世，这个问题在过去几年里变得更加明显了。这些带有代码分析器（用来警告代码中潜在的错误）并基于Eclipse RDT 的 IDE 是第一个支持 Ruby 广泛重构特征的 IDE。其他特征是支持基于 Ruby 的文件的，比如 Rake 文件——Ruby 的 make 或 ant 文件。问题是：这些工具都是用 Java 构建的（或其他语言）且 Java IDE 都使用 JRuby 分析器。

这意味着这些工具的功能都被那些语言禁固了，更糟的是，这些工具常常绑定到了特定的 IDE 上。例如，支持 RDT 的重构逻辑，对 Ruby in Steel （建立在 Visual Studio 上的 IDE）是不可用的。在 Java 界与之相比的区别是，分析器是可用的。像 PMD 或 Findbugs 这些工具都是用 Java 编写的，因此 Java 在哪里运行都可使用这些工具，更重要的是，可以用 Java 代码扩展这些工具。

因为该 Soc 项目的描述并没有 100% 说清楚基于 Ruby 的分析器的研究计划，Wang Huofei 澄清了该项目计划：

这取决于我们做得有多好。即使不能满足 Soc 的进度表，我们也愿意做这些事情。

好消息。

制造代码工具一个必须的东西是 AST，用来分析源码。前面已经提到的分析树，提供了一种表现 Ruby 源代码的格式。已有的基于分析树的工具，比如 Ruby2Ruby 可以把 AST 转换成 Ruby 源代码；如果某工具想修改 AST 并输出为 Ruby 源代码，这很有用。Rubinus，一个用 Ruby 实现 Ruby VM 的项目，也使用了分析树输出，用以把 Ruby 编译为 Rubinius 字节码，接着解释这些字节码。当被问到分析器的输出时，Wang Haofei 这样解释到：

ANTLR 有其自己内建的 AST 支持，这为我们序列化一个字符串或改变其他结构提供了很大方便。我们的分析器与分析树输出看起来很相似。在 XRuby 里我们把 AST 转换成像 DOM 这样的结构并使用 Visitor 模式产生 Java 字节码。

而分析树输出看起来还没有计划，很有可能把 ANTLR 产生的 AST 转化成分析树格式。一个类似的方法已经被 JParseTree（JRuby 的一个分析树端口）所采用，现在 JRuby 一部分额外软件包（ JRuby Extras ）提供了常用 Ruby 类库的 JRuby 端口。

从 XRuby 团队的 blog 可以得到更多关于 XRuby 及其分析器项目信息。

查看英文原文： Google SoC Series: ANTLR v3 Ruby Parser - - - - - -

译者简介：宋玮是 InfoQ 中文站的志愿者翻译。他有多年软件开发经验，从 2002 年开始就使用 Java，在各个项目开发过程中先后使用过 Struts、Oracle ADF、AspectJ 等。最近正在使用 Spring 及 Ruby on Rails，对敏捷方法有比较大的兴趣并做过一些尝试。他的 blog 为 http://www.donews.net/victorsong 。与 InfoQ 中文站分享内容，请邮件至 china-editorial@infoq.com 。