Re: coco/rb ver 0.5.0

"Mark Probert" <probertm@NOSPAM_acm.org> wrote in message
news:Xns9333B2AEE7E5probertmNOSPAMacmorg@47.129.29.57...

> parse the Language of your Dreams (assuming that you can express it in
> LL(1), which isn't Ruby).

I'll just add that you need not parse a grammar in one stage. For most
grammars you can probably define a convenient stage 1 grammar in LL(1) and
then do you own manual top-down parsing of the resulting parse tree generate
of stage 1. This typically makes the grammar cleaner and more maintainable -
and certainly a lot more powerful.

For example, you can avoid having fixed keywords for types like <int>,
<float>, etc. and allow such types to be defined within the same grammar.
During the second stage you have more information. The downside is that
second stage is usually not supported by parser tool, but it is easily
implemented with recursive tree-walking functions.

Today memory isn't a big deal in relation to parsing text, so it is no
longer of concern to do multistaged parsing. Therefore, LL(1) also shouldn't
be considered too limited. A parser should simply do the grunt-work of
building a parser tree and convert text to numeric data where applicable. It
is much more difficult to write a single-pass LL(1) parser - and there is no
reason to.

The only major downside of a multi-staged parser is that it can be tricky to
report errors syntax error discovered at stage 2, as well as semantic
errors, unless you carefully relate parse-tree to locations in source text.

Mikkel