Ruby语言实现的Ruby语法分析器：ruby_parser 1.0

07年12月22日，Ryan Davis宣布了ruby_parser的发布。ruby_parser是一个纯Ruby实现的Ruby源代码语法分析器。这个语法分析器的编写过程中使用了Ruby yACC (RACC)，一个包含在Ruby标准库中的语法分析程序生成器。

ruby_parser(RP)是一个纯Ruby实现的Ruby语法分析器（借助了racc——它在缺省情况下使用C语言的扩展)。RP的输出与语法分析树的输出相同：用ruby中的数组以及基本类型来表达的s-expression。

这个库很容易使用：

RubyParser.new.parse "1+1"  

上面的语句会返回：

s(:call, s(:lit, 1), :+, s(:array, s(:lit, 1)))

Ruby世界中一直缺少纯Ruby实现的Ruby语法分析器。“纯Ruby”意味着该语法分析器：

◆仅仅包含Ruby源文件
◆没有任何本地扩展或者C语言代码（例如通过RubyInline）——C语言代码要求用户系统必须包含C编译器来处理这些代码

上面这些属性对于保证代码能够通用于各种Ruby运行时至关重要。如果一个语法分析器的实现使用了基于C语言的本地扩展，那么它就无法在不支持这些扩展的Ruby版本上运行，例如JRuby、XRuby或者.NET上的IronRuby和Ruby.NET。即便这些Ruby版本支持了本地扩展（JRuby正在考虑这一方案)，它还会造成部署问题，因为这要求扩展所使用的库或DLL必须被移植到任何可能的OS/CPU组合之上（否则某些用户将无法使用该语法分析器)。Ryan Davis的另一个项目RubyInline，通过自动编译那些内联的C代码一定程度上的改善了这一状况。但要RubyInline要求目标系统需要包含一个C编译器——这一条件并不是总能满足，尤其是对于Windows系统来说。

因为可以使用类似语法分析树（ParseTree）的通用方法来对Ruby代码进行分析并获得抽象语法树（Abstract Syntax Tree），所以在Ruby历史上的一定时期内，纯Ruby语法分析器的缺失被忽视了。然而自从各种Ruby运行时雨后春笋一样的出现以来，Ruby语法分析器被反复实现了很多次——两次使用Java（JRuby和XRuby），一次使用C#（Ruby.NET所编写的语法分析器也被IronRuby所使用）。所有这些分析器提供了不同的抽象语法树以及获取它们的方式。

这造成了Ruby源代码工具的一些问题。例如，目前Aptana/RDT（基于Eclipse）中包含的Ruby重构工具就被绑定到Java和JRuby的抽象语法树上，这使其无法被用在其他的Ruby实现上。类似的，针对其他基于Java的Ruby IDE的工具也正在被开发，这造成了大量代码分析管理工具被限制在Java和JRuby上。除此之外，这些工具的逻辑使用Java而不是Ruby编写，这对Ruby开发人员来说不够友好。

纯Ruby语法分析器提供了改变这种情况的机会——Ruby IDE（或者其他工具）可以获得Ruby的抽象语法树，同时避免被绑定到特定的语法分析器实现上。例如，一个基于Java的IDE可以在开启JRuby的同时使用ruby_parser进行语法分析。为了达到这一目的，目前版本的ruby_parser需要在输出中增加源代码位置的信息，例如，每个抽象语法树的节点需要了解其在源代码中开始和结束位置的偏移。这对源代码工具来说至关重要，因为虽然纯粹的语法树结构信息也很有用，但是如果工具无法了解节点在源码中的位置，它就不能对源码进行修改。

ruby_parser的另一个使用者是Rubinius。Rubinius是一个绝大部分代码使用Ruby编写的Ruby虚拟机，不过它使用的是Matz的Ruby参考实现（MRI）中所包含的语法分析器，而通过使用ruby_parser可以使Rubinius移除这一部分的C语言代码。此处还存在一个问题：“如果语法分析器是Ruby编写的需要Ruby虚拟机来运行，那么依赖语法分析器的Ruby虚拟器要如何工作？”，这是一个类似“鸡大生蛋，蛋破生鸡”问题。为了避免这个问题，在Rubinius的虚拟器中，ruby_parser的Ruby源代码会被编译为Rubinius字节码。当Rubinius启动时，它通过读取ruby_parser的字节码文件——这些文件不需要进行语法分析——来运行一个Ruby语法分析器。

对于ruby_parser来说，还有许多工作要做。发布说明中列出了其中的一些问题：

◆已知问题：速度还很不尽如人意。运行5500个测试用例目前需要21分钟。
◆已知问题：代码有些难看。不过这不全是我的错，我会尽快改进这一状况。
◆已知问题：目前还不支持newline节点。
◆已知问题：功能还可以更加强大。
◆已知问题：ParseTree中的dasgn_curr声明可能会乱序。
◆待做事情：加入注释节点。

原文链接：http://www.infoq.com/cn/news/2008/01/ruby_ruby_parser

【相关文章】

• Ruby 1.9正式发布 运行效率大幅度提升

• Ruby on Rails 2.0正式发布

• 被遗忘的Ruby Web开发框架