[antlr-interest] v3.0 debug interface

[Terence Parr]

On Mar 24, 2005, at 4:22 AM, Scott Stanchfield wrote:
> Ter's proposing a unicast observer pattern, rather than multicast (as 
> Ter's
> assuming only a single listener).

Or daisy-chain or a listener that is the multicast.  Please pass on a 
common use-case and I'll add :)

> The debugger(s) will need some sort of notification/registration 
> mechanism.
> In Eclipse, this is easy (plugin registration makes it easy, and we can
> define an ANTLR launcher that looks for registered debuggers and 
> attaches
> them as listeners to a parser).

Yeah, there are a number of nasty issues related to ease of hooking 
this beast up.  i'm brainstorming with Jean Bovet this Sunday.

> If there was a good chance that people would want to wire a debugger to
> ANTLR in a JavaBean builder, I'd agree that having it follow the 
> JavaBean
> event model (using EventListener and EventObject) would be a good 
> idea. I
> don't think that's likely, so I'd avoid the extra event object 
> creation, and
> because of that, skip the EventListener extension.

Yeah, I like location(line,pos) as it's language neutral; heck even C 
would like it. :)

> I'd like to be notified of:
> * which parser sent the information (we could be debugging multiple 
> parsers
> at once with a single debugger...) for all methods

Yeah, i am worried about this; haven't thought about how this will 
work.  I'm going to start with one grammar and then  when I know more, 
add multiple grammar support (like multiple tree parsers).

> * predicate evaluation (and success/failure)

Yep, this is reasonable.  The only question is how do you identify the 
predicates?  By their text?  I.e., do i do this?

if ( dbg.predEval("isTypeLA(1)", isType(LA(1))) ) { ... }

in the prediction expressions?  Hmm...probably would want the decision 
number as well.  File line info?  Does ParseView do this?  Have you 
found it useful?  I imagine it would be.

> * whether we're guessing or not

3.0 doesn't have syn preds yet so I'll add later.

> * la(k)/lt(k) evaluation

I thought about this for a long time.  Seems to me we can derive this 
in just about every situation unless the debugger can't load the input 
file such as when it's coming in from a socket.  In most cases, the 
debugger can show the input with all consumed char dimmed out.  The 
next input is the lookahead.  'course, you don't know how they are 
tokenized.  OTOH, since most of the time the input will be fully 
tokenized a priori, that could be just sent to the debugger. 
Hmm...perhaps LA(i)/LT(i) is easier.  Anybody else have thoughts here?  
I'm trying to keep the interface to a minimum as you can tell.

> * enterAlt needs a ruleName as well

It's the prior enterRule value, right?

> * parsing completed successfully

I guess you're right.  That's hard though.  Where do you put it?  Every 
rule can be a start symbol.  Further, can't end of input suggest you're 
done successfully?

> * text or a token was matched

I have consumed.

> * newline was triggered

Perhaps it's obvious, but why do you want this?

> * have location indicate the file we're in

Yeah, I was thinking about include files and such too...would the file 
be an int representing which file to reduce network traffic?  Then we'd 
need a "registerFile("foo.txt", 1);" to get file number.

> * I'd prefer to be notified of rules by number rather than name - a
> debuggable parser can provide a rule-name lookup method or public 
> static
> array of rule names

True.  We would need rules to register then.  We'd want to avoid having 
both antlr and the debugger have to use the exact same algorithm to 
number rules.

> These features will allow a debugger to show the user exactly what's 
> going
> on during the scan/parse by highlighting source, displaying messages, 
> and so
> forth.

Yup.

> Here's what I've got for ANTLR 2.7.6's parser listener. I've 
> simplified it
> significantly from previous versions. Note the lack of event objects 
> in this
> version; I felt they were a waste. Still an observer pattern.

[...]

Nice.

Ter
--
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.jguru.com