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 声明可能会乱序。
- 待做事情:加入注释节点。
评论