Make creating parser/lexer/etc sequence easier

[tbodt]

To create a parser, you have to create about 5 different objects, most of which are not referenced again. That's quite cumbersome. Maybe a *Recognizer class could be generated which automatically creates the *Parser, *Lexer, and CommonTokenStream, and provides accessors for them, in case you need them.

[sharwell]

The proposed methods would only apply to certain use cases. In other cases, using these methods would result in an error. This should be optional functionality if included at all.

[parrt]

Yeah, You might as well just create something yourself that works for you. I can imagine creating a function that accepts the class definitions for a lexer a parser but then it's hard to call the start rule without knowing the type of the resulting parser. You would have to pass in the name of the start rule two. If it's okay with you, I'll close this as a general issue.

[tbodt]

What I meant was a class, generated with the lexer, parser, etc. classes like this:

public final class WhateverRecognizer {
    private WhateverLexer lexer;
    private WhateverParser parser;

    public WhateverRecognizer(ANTLRInputStream in) {
        lexer = new WhateverLexer(in);
        CommonTokenStream cts = new CommonTokenStream(lexer);
        parser = new WhateverParser(in);
    }

    // one of these for each parser rule:
    public ParseTree rule() {
        return parser.rule();
    }

    public WhateverLexer getLexer() {
        return lexer;
    }

    public WhateverParser getParser() {
        return parser;
    }

    public void addErrorListener(ANTLRErrorListener listener) {
        parser.addErrorListener(listener);
        lexer.addErrorListener(listener);
    }

    public void removeErrorListeners() {
        parser.removeErrorListeners();
        lexer.removeErrorListeners();
    }

    // and on and on...
}

This would be for a grammer called Whatever.

As much as possible of this would be delegated to a class in the runtime API. I'm not sure about calling it a Recognizer, as there is a Recognizer class in the runtime API.

[sharwell]

Your comment confirms I interpreted your original request correctly. There are many grammars which do not work at all with CommonTokenStream, and/or have special requirements for initialization prior to use. A class like the above would only lead to confusion for those users, because any attempt to use the class would result in incorrect behavior.

The small reduction in code for creating a parser instance is not worth the additional implementation complexity or confusion to users where the described pattern is not a good fit for the application.

[parrt]

Someone just recommended we gen an extra ctor; reopening to consider.

Why can all this:

ANTLRInputStream input = new ANTLRInputStream(System.in);
ArrayInitLexer lexer = new ArrayInitLexer(input);
CommonTokenStream tokens = new CommonTokenStream(lexer);
ArrayInitParser parser = new ArrayInitParser(tokens);

Not just become:

   ArrayInitParser parser = new ArrayInitParser(System.in);

That is, provide some methods for this (for different inputs, such as System.in, file name, string,…). This way the use of ANTLR would become even simpler. The above is boiler plate
that every user has to copy and paste.

[tbodt]

If there was another constructor as @parrt described, how would you get a reference to the lexer? You need a reference to the lexer to add an error listener, for example.

[parrt]

Perhaps in that case one could not use that simple mechanism. On the other hand, adding listeners is pretty common. An object that aggregates the lexer and parser could be returned. Or, more simply, given access to the parser, one can ask for the token stream which can also provide the lexer.

[tbodt]

If you want the lexer, I think it's pretty cumbersome to say:

WhateverLexer lexer = (WhateverLexer) parser.getInputStream().getTokenSource();

Plus it involves a cast. Maybe if you create a parser like this, the error listener methods also add or remove the listener from the lexer.