JavaCUP and actions

"Svend Tofte" <>
26 Apr 2005 20:47:35 -0400

          From comp.compilers

Related articles
JavaCUP and actions (Svend Tofte) (2005-04-26)
Re: JavaCUP and actions (Chris Dodd) (2005-04-28)
Re: JavaCUP and actions (Chris F Clark) (2005-04-28)
| List of all articles for this month |

From: "Svend Tofte" <>
Newsgroups: comp.compilers
Date: 26 Apr 2005 20:47:35 -0400
Keywords: Java, parse, question, comment
Posted-Date: 26 Apr 2005 20:47:35 EDT


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 ;

JavaCUP eats it up fine. However, if I proceed to add actions to the
first production, such as:

E ::= {: System.out.print("<E>"); :}
            {: System.out.print(p); :}
            {: 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

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

[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]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.