[antlr-interest] ENHANCEMENT: Friendlier parser class, syntactic sugar for top level production.

Johannes Luber jaluber at gmx.de
Thu Jul 31 02:45:02 PDT 2008


Austin Hastings schrieb:
> I didn't see this in the 3.1b? release notes, so I thought I'd ask for 
> it again.
> 
> I'd like to see the Parser class come with a .parse(...) method. This 
> would do what the examples suggest: create  a lexer, etc., and then 
> invoke the top level production.
> 
> Obviously, you could override this. If you do, then no harm done. But 
> most people are doing the same things, so why should the code generator 
> generate the last little bit that they need?
> 
> Equally obviously, there would need to be a way to identify the  top 
> level production. The most obvious way is to use the first one 
> encountered. A slightly better way would be to add some syntax to 
> identify it. Either as an option, or as a rule attribute:
> 
> options {
>    language = Java;
>    main_rule = compilation_unit;
> }
> 
> // or
> 
> algebraic_expr
>    : ...
>    ;
> 
> boolean_expr
>    : ...
>    ;
> 
> compilation_unit
>    @main_rule
>    : ...
>    ;
> 
> 
> =Austin
> 

Another possibility is to look for a rule with EOF. There should be only 
one rule anyway with EOF at its end and that is the top rule. Until name 
mangling is introduced, using parse() as standard point of entry causes 
a naming conflict with a real parse rule, though. But I haven't seen a 
grammar yet where a rule named parse makes sense, so this may not happen 
often.

Johannes


More information about the antlr-interest mailing list