[antlr-interest] Unnecessary Java output file diffs

Terence Parr parrt at cs.usfca.edu
Wed May 20 12:13:34 PDT 2009


All you have to do is alter the line in Java.stg template file.  We  
could add an action variable like @members that fills in the version  
template string.
Ter
On May 20, 2009, at 12:11 PM, Sam Harwell wrote:

> I wanted to make an option that doesn’t include the timestamp and  
> line number in the generated file, but I couldn’t think of a name  
> for it. Anyone have any suggestions?
>
> Sam
>
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-bounces at antlr.org 
> ] On Behalf Of Tom Ball
> Sent: Wednesday, May 20, 2009 2:07 PM
> To: antlr-interest at antlr.org
> Subject: [antlr-interest] Unnecessary Java output file diffs
>
> Our distributed build system compares output files and only copies  
> back the ones that have changed since the last build.  We've noticed  
> that our Antlr->Java step always gets copied, for two reasons.   
> First, because a timestamp is in the output file's header -- is that  
> necessary as a default?  More useful might be a timestamp variable  
> that can be put a .g file if desired, and expanded during generation.
>
> We think the second reason might be a bug, as here is some example  
> output from a common, unchanged source file:
>
> @@ -2531,7 +2531,7 @@
>                         int index13_13 = input.index();
>                         input.rewind();
>                         s = -1;
> -                        if ( (((input.LT(1).getText()
> .equals("gte"))||(input.LT(1).getText().equals("lte"))|| 
> (input.LT(1).getText().equals("gt"))|| 
> (input.LT(1).getText().equals("lt"))|| 
> (input.LT(1).getText().equals("eq"))|| 
> (input.LT(1).getText().equals("ne")))) ) {s = 2;}
> +                        if  
> ( (((input.LT(1).getText().equals("gte"))|| 
> (input.LT(1).getText().equals("lte"))|| 
> (input.LT(1).getText().equals("lt"))|| 
> (input.LT(1).getText().equals("gt"))|| 
> (input.LT(1).getText().equals("eq"))|| 
> (input.LT(1).getText().equals("ne")))) ) {s = 2;}
>
>                         else if ( (true) ) {s = 8;}
>
> Shouldn't the order of the token comparisons be the same for every  
> generation?  I guess it doesn't matter in this example since the  
> string can only have one match, but my hunch is that with other  
> rules comparison order matters.  Here is the rule which generated  
> the above:
>
> comparator returns [Operation value]
>   : ((eqToken | '=') { $value = Operation.EQ; })
>   | ((neToken | '!=') { $value = Operation.NEQ; })
>   | ((gtToken | '>') { $value = Operation.GT; })
>   | ((gteToken | '>=') { $value = Operation.GTE; })
>   | ((ltToken | '<') { $value = Operation.LT; })
>   | ((lteToken | '<=') { $value = Operation.LTE; })
>   ;
>
> // Pseudo-tokens
> eqToken : {input.LT(1).getText().equals("eq")}? NCNAME ;
> neToken : {input.LT(1).getText().equals("ne")}? NCNAME ;
> ltToken : {input.LT(1).getText().equals("lt")}? NCNAME ;
> lteToken : {input.LT(1).getText().equals("lte")}? NCNAME ;
> gtToken : {input.LT(1).getText().equals("gt")}? NCNAME ;
> gteToken : {input.LT(1).getText().equals("gte")}? NCNAME ;
>
> NCNAME
>   : (LETTER | '_') (LETTER | NONLETTER | '.' | '-' | '_')*
>   ;
>
> Tom
>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address



More information about the antlr-interest mailing list