Ryan Davis宣布了ruby_parser
发布
ruby_parser是
个纯Ruby实现Ruby源代码语法分析器这个语法分析器编写过程中使用了Ruby yACC (RACC)个包含在Ruby标准库中语法分析
生成器ruby_parser(RP)是
个纯Ruby实现Ruby语法分析器(借助了racc——它在缺省情况下使用C语言扩展)RP输出和语法分析树输出相同:用ruby中
以及基本类型来表达s-expression这个库很容易使用:
RubyParser.
.parse "1+1"上面
语句会返回:s(:call, s(:lit, 1), :+, s(:
.gif' />, 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实现上类似针对其他基于JavaRuby IDE工具也正在被开发这造成了大量代码分析管理工具被限制在Java和JRuby上除此的外这些工具逻辑使用Java而不是Ruby编写这对Ruby开发人员来说不够友好纯Ruby语法分析器提供了改变这种情况
机会——Ruby IDE(或者其他工具)可以获得Ruby抽象语法树同时避免被绑定到特定语法分析器实现上例如个基于JavaIDE可以在开启JRuby同时使用ruby_parser进行语法分析为了达到这目目前版本ruby_parser需要在输出中增加源代码位置信息例如每个抽象语法树节点需要了解其在源代码中开始和结束位置偏移这对源代码工具来说至关重要虽然纯粹语法树结构信息也很有用但是如果工具无法了解节点在源码中位置它就不能对源码进行修改ruby_parser
另个使用者是RubiniusRubinius是个绝大部分代码使用Ruby编写Ruby虚拟机不过它使用是MatzRuby参考实现(MRI)中所包含语法分析器而通过使用ruby_parser可以使Rubinius移除这部分C语言代码此处还存在个问题:“如果语法分析器是Ruby编写需要Ruby虚拟机来运行那么依赖语法分析器Ruby虚拟器要如何工作？”这是个类似“鸡大生蛋蛋破生鸡”问题为了避免这个问题在Rubinius虚拟器中ruby_parserRuby源代码会被编译为Rubinius字节码当Rubinius启动时它通过读取ruby_parser字节码文件——这些文件不需要进行语法分析——来运行个Ruby语法分析器对于ruby_parser来说
还有许多工作要做发布介绍说明中列出了其中些问题: ◆已知问题:速度还很不尽如人意
运行5500个测试用例目前需要21分钟◆已知问题:代码有些难看
不过这不全是我错我会尽快改进这状况◆已知问题:目前还不支持
line节点◆已知问题:功能还可以更加强大
◆已知问题:ParseTree中
dasgn_curr声明可能会乱序◆待做事情:加入注释节点
最新评论