From: Tanaka Akira Date: 2002-11-08T12:04:33+09:00 Subject: Re: bRuby? (Yet another Ruby parser) In article , ptkwt@shell1.aracnet.com (Phil Tomson) writes: > I guess the point of my question is that there seem to be at least six > projects out there that are essentially doing the same thing. Aren't we > duplicating a lot of effort? Is there any way we can work together on one > of these parsers and possibly get results quicker? Ruth calls Ruby's internal parser. Ripper reuse parse.y including the lexer but not actions. My xmlize reuse production rules from parse.y but not actions and the lexer. Maybe, Mark's parser for cocorb don't reuse production rules parse.y because the rules are not LL(1). The hardest problem for writing Ruby parser is cloning the heuristics of lex_state to resolve ambiguity especially with "do" and "{". I tried to understand the heuristics but I couldn't. So xmlize behaves differently to the original parser in subtle cases. So, I think Ruth and Ripper are right direction if perfect compatibility is required. However Ruth may have some restrictions because internal parser rip off some information such as comments, exact token position, etc. The ultimate answer is Rite, of course. It should have reusable parser component. When it is available, we don't need to update various parsers to follow matz's. But it seems that matz doesn't designed the API for the component yet. So we need to propose suitable API of the component. I think various parser projects may help matz. -- Tanaka Akira