[antlr-interest] ANTLRWorks 2 (for ANTLR v4)

[Douglas Godfrey]

How about a direct language feature to issue a warning or error on parsing
a rule...

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
error with 
a better error description when the rule is matched. The side effect of
encountering
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
>target.
>
>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
>socket connection?
>
>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.
>
>Thanks!
>Ter
>
>List: http://www.antlr.org/mailman/listinfo/antlr-interest
>Unsubscribe: 
>http://www.antlr.org/mailman/options/antlr-interest/your-email-address