Related articles |
---|
Parsing starting from any non-terminal clint@0lsen.net (Clint Olsen) (2003-04-27) |
Re: Parsing starting from any non-terminal matt@peakfive.com (Matt) (2003-05-06) |
Re: Parsing starting from any non-terminal peter_flass@yahoo.com (Peter Flass) (2003-05-15) |
From: | Matt <matt@peakfive.com> |
Newsgroups: | comp.compilers |
Date: | 6 May 2003 01:04:59 -0400 |
Organization: | AT&T Broadband |
References: | 03-04-099 |
Keywords: | parse |
Posted-Date: | 06 May 2003 01:04:59 EDT |
Clint Olsen wrote:
>
> One of the irritating things about yacc and friends is the ability to parse
> a subset of a language L. So, I've created a parser for the entire
> language, but I have another section of code that just needs the expression
> evaluation portion. I know this is possible in recursive descent, but what
> about LR-style generated parsers?
> [You can fake it.
>
> start: WHOLE wholeprogram | EXPR expression ;
>
> Then adjust your lexer to stuff a WHOLE or EXPR token at the beginning
> to get the parser started. -John]
I needed something that would start the parser in one of a hundred or
so places so rather than faking it, like John said, I wrote some code
that took the output documentation of yacc and found the correct state
to start the parser in. Adding a hundred fakes would probably have
been easier but I also needed the parser to stop in the middle and
treat a special token as, say, an expression, or a statement. I could
probably've faked this, too but I used the "reduce by rule expr" as a
"shift token expr" and it worked just fine. needless to say this was
all rather brittle. On the other hand, adding lots of "fake" rules
could also break the grammar.
Since then I've replaced it all by a recursive decent parser. But
these have different problems, at least the way I built it.
Matt
Return to the
comp.compilers page.
Search the
comp.compilers archives again.