[antlr-interest] v3.0 debug interface

[Tom Brandon]

I had a couple of comments about your post (see below), but then
realised I wasn't quite sure how debugging is supposed to work wrt
target languages. How is the Antlr GUI executing grammars for debugging?
Is it executing an interpreted version of the grammar or a compiled
version? If it is interpreted then what does it do about actions? Are
you planning to support debugging of languages with actions in languages
other than the language of the GUI? It would seem nice to allow this as
an option in the design of Antlr though supporting it in the GUI may not
be a priority.

You suggest a java debugging interface which can then be proxied out
over TCP to non-Java clients, but doesn't this mean that the solution
(at least the solution of the GUI) is limited to debugging grammars that
target Java? Wouldn't it be better to have Antlr specify a language
neutral TCP based debugging protocol. Then a GUI would implement this
and with a bit of target language code to run a compiled grammar and
send the debugging information over TCP any target language could be
debugged from a single GUI. There may still be target language specific
protocols (such as your Java interface) but shouldn't Antlr 3 specify a
single language neutral debugging mechanism.

And then the issues with the actual proposal:

Any reason for not going with a more standard Listener based pattern (if
you weren't already intending such a pattern)? Will the system support
multiple listeners? Can't really conceive of a case where multiple apps
would want to listen, but you may want more flexibility in the GUI,
multiple parts each registering their own listeners rather than
everything having to come off one master listener (and there's the
code-gen specific events mentioned below where you might want
corresponding GUI modules for different code-gens).

Any reason for a non-extensible model? If you use a standard Listener
pattern with event data wrapped up in objects then you could have a
generic method (in addition to specific methods), like:
public void debugEvent(AntlrDebugEvent evt); 

Not really sure about use-cases for that. Maybe some code generators
want to add (or subclass) their own events which shouldn't pollute the
main interface.

Tom.

-----Original Message-----
From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Terence Parr
Sent: Tuesday, 22 March 2005 13:26
To: 'antlr-interest' Interest
Subject: [antlr-interest] v3.0 debug interface

Howdy,

I am working on the debug interface so that parsers trigger events.  
The GUI can listen for these events (initially in Java and then
marshaled over a socket to support non-Java languages) and do cool
displays etc...  The debugger will be able to tell the parser to
Thread.wait() in order to implement breakpoints etc...

Anyway, I've been thinking hard about what events we need to trigger.  
Most of my thoughts are driven by the ways in which I intend to use a
debugger.  Also I've take some ideas from David Wigg (who suggested I
fire events for alternatives not just rules) and Scott Stanchfield (who
did the ParseView debugger).

The code generator adds the appropriate triggers upon -debug
command-line option.  All but the location() triggers are functioning.  
Currently, I'm going to have the GUI launch the parser with a
TokenStream but later your apps will be able to create an instance of 
the GUI and pass it to the parser as the debug event listener. :)   By 
default, the parser compiles but doesn't emit any debug output; I'll
probably change that so it mimics the -traceParser 2.x feature.

BTW, I've kept this interface as small as possible.  Some of the
functionality I want in the debugger is not obviously possible from this
interface, but in fact with a little work the debugger will be able to
do amazing things!

So, here it is so far...I'm happy to receive feedback.  I expect that
this will change a lot as Jean builds the GUI on top.

Ter
-------------------------------
package org.antlr.runtime;

public interface ANTLRDebugInterface {
<SNIP>
}

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