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" <pa...@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 List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
