[antlr-interest] error(10): internal error: TWalker.g : java.lang.IllegalArgumentException: Can't find template tokenRefRuleRoot.st

Thomas Brandon tbrandonau at gmail.com
Thu Aug 9 20:46:53 PDT 2007


On 8/10/07, Cameron Esfahani <dirty at apple.com> wrote:
>
> Based on some comments, I realized that I didn't understand tree grammars as
> well as I thought.  So looking back at section 8.2 in the ANTLR book,
> specifically at the implementations of CMinus.g and CMinusWalker.g, I
> realized that more complicated tree grammars don't look very similar to the
> parser grammar.
>
> Here is the relevant portion from my parser grammar:
>
> numeric_expression
>  : inclusive_or_expression
>  ;
>
> inclusive_or_expression
>  : exclusive_or_expression ( whitespace! '|'^ whitespace!
> exclusive_or_expression )*
>  ;
>
> exclusive_or_expression
>  : and_expression ( whitespace! '^'^ whitespace! and_expression )*
>  ;
>
> and_expression
>  : shift_expression ( whitespace! '&'^ whitespace! shift_expression )*
>  ;
>
> shift_expression
>  : additive_expression
>  (
>  whitespace!
>  ( '<<'^ | '>>'^ ) whitespace! additive_expression
>  )*
>  ;
>
> additive_expression
>  : multiplicative_expression
>  (
>  whitespace!
>  ( '+'^ | '-'^ ) whitespace! multiplicative_expression
>  )*
>  ;
>
> multiplicative_expression
>  : cast_expression
>  (
>  whitespace!
>  ( '*'^ | '/'^ | '%'^ ) whitespace! cast_expression
>  )*
>  ;
>
> cast_expression
>  : unary_expression
>  ;
>
> unary_expression
>  : postfix_expression
>  | ( '~'^ | '!'^ ) whitespace! cast_expression
>  ;
>
> postfix_expression
>  : primary_expression
>  ;
>
> primary_expression
>  : number_size -> ^( T_NUM number_size )
>  | '('! whitespace! numeric_expression whitespace! ')'!
>  ;
>
> and here is the corresponding portion from the tree grammar:
>
> numeric_expression
>  : ^( '|' numeric_expression numeric_expression )
>  | ^( '^' numeric_expression numeric_expression )
>  | ^( '&' numeric_expression numeric_expression )
>  | ^( '<<' numeric_expression numeric_expression )
>  | ^( '>>' numeric_expression numeric_expression )
>  | ^( '+' numeric_expression numeric_expression )
>  | ^( '-' numeric_expression numeric_expression )
>  | ^( '*' numeric_expression numeric_expression )
>  | ^( '/' numeric_expression numeric_expression )
>  | ^( '%' numeric_expression numeric_expression )
>  | ^( '~' numeric_expression )
>  | ^( '!' numeric_expression )
>  | ^( T_NUM number_size )
>  ;
>
> It doesn't give me that warning anymore, and I think it is correct...
>
> Any comments?
Ah right, your error was in a tree grammar. Then the error would be
that you cannot use ^ and ! operators in a tree grammar at all (well,
when tree rewrites are introduced you may be able to, assuming
operators are allowed as well as rewrites). You use the ^( ... )
construct instead of TOKEN^ and ! is not allowed in tree parsers.
Using rewrite rules rather than operators in your parser is
particularly useful when you have a tree grammar after your parser as
then you just need to remove the LHS of all rewrites in order to
derive the tree grammar rather than the larger scale rewriting the use
of operators entails.

e.g. where:
and_expression:
  shift_expression ( whitespace! '&'^ whitespace! shift_expression )*
  ;
must be changed to something like:
and_expression:
  ^( '&' numeric_expression numeric_expression )
  ;

If you have:
and_expression:
  shift_expression (whitespace '&' whitespace shift_expression
    -> ^( '&' shift_expression shift_expression )
  ;
Then this you just remove the LHS to get:
and_expression:
  ^( '&' shift_expression shift_expression )
  ;
(Of course you can also collapse the expression hierarchy like you did
by converting everything to numeric_expression)

Tom.
>
> Cameron Esfahani
> dirty at apple.com
>
> "Most people are bad programmers," says Joy. "The honest truth is that
> having a lot of people staring at the code does not find the really nasty
> bugs. The really nasty bugs are found by a couple of really smart people who
> just kill themselves. Most people looking at the code won't see anything ...
> You can't have thousands of people contributing and achieve a high
> standard."
>
> Bill Joy on the myth of Linux's much touted "power in the masses"
> development benefits.
>
>


More information about the antlr-interest mailing list