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

[Jim Idle]

I think though that the reason for having them as special productions is
so that they don't affect the predictions of the normal case and generate
lots of ambiguity.

Wasn't the idea that on getting a mismatch, you then tried each error alt
in the order given, rather like backtrack mode but that the error
productions were not included in the ordinary alts? The first error alt
that matches then deals with the error messages and so on.

I am pretty sure that this arose because of all the messing around that I
had to do to stop parsers from dropping out of loops and that one problem
was that there were cases where you could not specify common error
patterns without affecting prediction and followsets and so on to such an
extent that you would have to use backtrack mode all the time? Therefore
the idea of special annotation/indication of error alts was required?

Jim

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Terence Parr
> Sent: Thursday, September 08, 2011 12:28 PM
> To: Antlr-Interest Antlr.Org
> Subject: Re: [antlr-interest] ANTLRWorks 2 (for ANTLR v4)
>
> yes, That is of course something for ANTLR not AW. I called those error
> alternatives in my wish list, but then I realized that you can simply
> list them already without having to identify them as error
> alternatives. Then, in that rule, you can specify the appropriate error
> message.
>
> Ter
> On Sep 8, 2011, at 5:45 AM, Douglas Godfrey wrote:
>
> > 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-
> addres
> >> s
> >
> >
>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
> email-address