[antlr-interest] ANTLRWorks 2 (for ANTLR v4)
douglasgodfrey at gmail.com
Thu Sep 8 05:45:11 PDT 2011
How about a direct language feature to issue a warning or error on parsing
I.e. you have a grammar where certain improper syntax is expected. You
make a rule
that will recognize the improper syntax or semantics and issue a syntax
a better error description when the rule is matched. The side effect of
an error rule is the normal unwinding that occurs on a parse failure.
On 9/1/11 2:18 PM, "Terence Parr" <parrt at cs.usfca.edu> wrote:
>Hi, In parallel with the development of ANTLR v4, superstar Colin Bean
>will be building the new version of ANTLRWorks. We already have a great
>base in what Jean Bovet did for the 1st version. It's a known entity and
>has lots of bookkeeping code that we can cut and paste into the new one
>such as the automatic update facility and preferences. Because we've got
>something to play with, we have something to critique and also a basic
>I can imagine the basic tool being missing but it would be great to get
>feedback from the antlr community. Remember, that there are probably 2
>main communities: the people new to languages and/or ANTLR and the people
>very used to working with ANTLR grammars. For example, new people tend to
>like the syntax diagrams but many old-timers like myself prefer looking
>at the grammar because it's more terse. Recognizing that we must serve
>both those communities, please comment with any thoughts on the following:
>* What feature seemed like a good idea, but didn't end up being that
>valuable? You can say even heretical things like: " the single step
>feature in the debugger just didn't seem to be that useful beyond
>learning about parsing"
>* Do you use the re-factoring? Keep in mind that v4 will automatically
>handle direct left recursion.
>* What features do you think are really critical to add?
>* What features could be really great if we improved them?
>* Do we need better export facilities? would you really use things like
>"export grammar as hyperlinked HTML", for example.
>* What parts of the debugger did you use? There is a lot of stuff in
>there like: breakpoints on input tokens, step forward, step backward,
>jump to the end, break on specific kinds of events, break at specific
>line in the grammar, show the parse tree, show the AST constructed, list
>to the incoming events, etc... Should we rethink the entire notion of
>the debugger at something that simply displays information about what it
>sees during the parse? I.e., doesn't need to be a controller in the
>sense that you can single step the actual running parser over the usual
>You might include whether you are in the newbie or experienced camp or
>somewhere in between.
>Udo Borkowski has already implemented a fantastic tree layout algorithm
>from an academic paper. The performance is extremely good and the results
>are tight. Colin will probably implement his own syntax diagram viewer
>so that we can make it more than just a pretty picture. We want to
>highlight elements and step through etc.
More information about the antlr-interest