[antlr-interest] A postmortem of my use of antler

[Benjamin Shropshire]

Gerald B. Rosenberg wrote:
> At 03:08 PM 3/10/2008, Benjamin Shropshire wrote:
>
>> "how is antlr /expected/ to be used?" is the big one. That one should 
>> be on page one. I have yet to find a direct answer anywhere.
>
> Very difficult to formulate a one page/one paragraph answer.  After 
> all, Antlr is a DSL tailored for a large, variable problem space.  The 
> Antlr language operators are rather basic in nature -- to the extent 
> there are coding patterns, they are quite general at best.

Your points #12 & #13 cover a lot of what I would have liked to see on 
the front page. (That and enough context for someone new to known what 
they are talking about.)

> The step function learning problem is largely (I believe) one of 
> learning how to design a recognition specification subject to the 
> available mechanics of the Antlr language operators.
>
Oddly I was having a blast building and debugging my grammar. It was 
when I started trying to put int actions that stuff got difficult.

> That said, there are a number of caveats* that could be shared with 
> those new to Antlr**:
>
> 10) Use predicates to make clear what your code means.
> 11) Unless performance is absolutely your top 6 design requirements, 
> don't worry about using predicates.
that would be "don't worry about what predicates /cost/"?
>
> 12) Don't try to do too much in the lexer.  The parser is more 
> powerful anyway.
> 13) Don't try to do too much in the parser.  Use tree-walkers to 
> evolve an AST.

> 14) Don't try to dump complex blocks from a parser or AST.  Use 
> StringTemplate to unparse.
Does this hold if the final output is not a text file (e.g. in memory 
structures or a binary data file)
> 15) Actions (brace delimited statements) can be inserted almost anywhere.
Yah, I wish I'd noticed that one sooner.