Fwd: [antlr-interest] How to resolve nondeterminism in treeparser ?

[Bryan Ewbank]

:-( forgot to change the "reply" address - if anyones keeping metrics for 
evalating that particular issue :-(

---------- Forwarded message ----------
From: Bryan Ewbank <ewbank at gmail.com>
Date: Jul 4, 2005 2:37 PM
Subject: Re: [antlr-interest] How to resolve nondeterminism in treeparser ?
To: Subhobroto Sinha <subhobrotosinha at rediffmail.com>

The problem is that you have three levels of nested "(...)+" operators, so 
after the first INT|FLOAT, ANTLR doesn't know if it is supposed to leave the 
innermost loop, or keep spinning.
 The three levels of nesting are here:
  (1) firstPass : functionName order (csvCoeffs)+ ;
(1) secondPass : functionName order (csvCoeffs)+ ;
 (2) csvCoeffs : (coefficient)+; 
 (3) coefficient : (i : INT | f : FLOAT )+;
 You need to decide which of these should be a looping construct, and 
discard the "+" operator around the other two levels of expression. I think, 
from reading the input grammar, the "+" in the (3) rule is wrong - but 
that's just a guess. 
 Another option, perhaps more what you meant to do, is to have the parser 
build a tree preserving the shape of the original input. That would means 
that there would be a tree containing a CSV_COEFF node with COEFFICIENT 
nodes beneath it, and INT|FLOAT nodes beneath that. 
 For example, replace this:
 csvCoeffs : coefficient (COMMA! coefficient)*;
With this:
 csvCoeffs : coefficient (COMMA! coefficient)* { ## = 
#(#[CSV_COEFF,"CSV_COEFF"], ##); } ;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20050704/776edf3d/attachment-0001.html