Related articles |
---|
JavaCUP and actions stofte@gmail.com (Svend Tofte) (2005-04-26) |
Re: JavaCUP and actions cdodd@acm.org (Chris Dodd) (2005-04-28) |
Re: JavaCUP and actions cfc@shell01.TheWorld.com (Chris F Clark) (2005-04-28) |
From: | "Svend Tofte" <stofte@gmail.com> |
Newsgroups: | comp.compilers |
Date: | 26 Apr 2005 20:47:35 -0400 |
Organization: | http://groups.google.com |
Keywords: | Java, parse, question, comment |
Posted-Date: | 26 Apr 2005 20:47:35 EDT |
Hello,
I'm currently writing a parser, which will do an online parse of the
input language. That is, emit the translated code (XML) as soon as
possible. If you use a top-down approach, this is simple enough.
However, we'd like to use a bottom-up parser, simply because we've had
experience with one such parser (JavaCUP), and many languages seem LR
grammar styled.
Given an ordinary expression grammar, for example:
E ::= E PLUS:p T | T ;
T ::= T TIMES:t F | F ;
F ::= LPAREN:l E RPAREN:r | NUMBER:n ;
JavaCUP eats it up fine. However, if I proceed to add actions to the
first production, such as:
E ::= {: System.out.print("<E>"); :}
E
PLUS:p
{: System.out.print(p); :}
T
{: System.out.print("</E>"); :}
Then I get some six shift/reduce errors. Which on one hand seems fine
(how can it know, so early in the parse, that this production is it).
But ... reading in the dragon book, and taking in what my teacher told
me, and reading the JavaCUP manual (under "The Grammar"), I feel that
this should be possible. That JavaCUP would merely "delay", the
execution of actions, that it could not yet guarentee was to be
executed.
However, this doesn't seem to be the case.
So I'd like to know, if what I want is possible at all (it seems like
it should be), and if so, does JavaCUP do this? If not, is there
another LALR parser generator which does this?
And if no to all those, I will have to use a top-down approach
naturally.
Regards,
Svend
[Adding interior actions changes the grammar. When you write this (using
yacc syntax which I know better):
a: b { blah } c { farp } d ;
it is treated like this
a: b xx1 c xx2 d;
xx1: /* empty */ { blah };
xx2: /* empty */ { farp };
In the absence of the embedded rules, the parser can defer deciding whether
it's seen an "a" rule until it parses the "d", but with embedded rules, it
has to decide as soon as it's seen the "b".
The solution is to put all your debug stuff at the end of the rule. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.