[antlr-interest] Abstract tree parser

[Kirby Bohling]

On Tue, Feb 23, 2010 at 6:44 PM, Gerald Rosenberg <gerald at certiv.net> wrote:
> On 2/23/2010 4:04 PM, Kirby Bohling wrote:
>> I wish that superClass option was smart about handling debug vs.
>> non-debug, that's the one thing that annoys me any time I choose that
>> option is that I can't integrate with most of the cool debuggers
>> without extra work.
>>
>
> Curious to know what problems you run into.  I use debug mode all the
> time in a variety of circumstances know of no issue of whether the super
> class option is used or not.
>

So if I write a super class, I have to choose either to inherit from
"DebugParser", or from "Parser" (and I believe similarly for Lexer,
not sure about the tree).  When you try and debug it using AntlrWorks
certain functionality doesn't work if you don't have the methods from
DebugParser (or it just doesn't post the events as expected).  When
using AntlrWorks, when it generated the code, and then failed to
compile due to the missing methods if I recall correctly.  It's been a
while.  If I had all the methods inline, this wasn't a problem at all,
as they would be inserted as expected.  As I recall, I wrote an
interface that did all of my methods, and then generated one version
of my parser that inherited from Parser, and one that inherited from
DebugParser, and then delegated to my helper class.  I recall cursing
generics and wishing that Java had "real" templates so I wouldn't
spend a bunch of time writing/generating boilerplate delegation.

I suppose I could have just inherited from DebugParser until I was
done, but I was worried about side affects or other weird behavior, so
I tried to use it only when I was actually using ANTLRWorks.

Kirby




> Gerald
>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>