Two naive questions

[mk-solidat]

Hey there,

I'm new to ANTLR and parsing in general, so I apologize if the following two questions sound naive.

1. Say, I have a rule

typeidentifier:
	SCALARTYPE
	| IDENTIFIER
	| typeidentifier (X_MIN typeidentifier)+
	| typeidentifier ARROW typeidentifier;

What antlr seems to do then (at least in c++) is to generate a visitor class with a method to visit typeidentifier.

Question: why don't I get a class just to visit typeidentifier and a method for each possible pattern? That would allow me to be way more specific in what I return when I see a typeidentifier and what I get for each method. Also, it would break if I change the grammar (eg add a pattern for typeidentifier) - which seems desirable.

2. Why are the output languages tightly coupled to the antlr java tool? Wouldn't antlr be even more flexible if it returned some readily traversable output format from which anyone could write their own codegen and runtime?

[mk-solidat]

And while we're at it... Wouldn't it be kinda nice if - in this example - we had exact method signatures like

template<typename Result>
class GrammarTypeidentifierParserVisitor
{
protected:
   virtual Result visit1(const SCALARTYPE & arg0) = 0;
   virtual Result visit2(const IDENTIFIER & arg0) = 0;
   virtual Result visit3(const typeidentifier & arg0, const std::vector<std::tuple<X_MIN, typeidentifier>> & arg1) = 0;
   virtual Result visit4(const typeidentifier & arg0, const ARROW & arg1, const typeidentifier & arg1) = 0;
public:
   Result visit(const typeidentifier & ctx)
   {
      // generated code will safely unwrap the and call the relevant overload
      // or better still, typeidentifier might be (or contain) a std::variant containing all the relevant data directly
   }
};

[kaby76]

Question: why don't I get a class just to visit typeidentifier and a method for each possible pattern?

You can get a visitor method for each alt in the rule, but you need to use alt labeling.

typeidentifier:
	SCALARTYPE # a1
	| IDENTIFIER # a2
	| typeidentifier (X_MIN typeidentifier)+ # a3
	| typeidentifier ARROW typeidentifier # a4
        ;

Then, the Antlr Tool will generate:

class  abbParserBaseVisitor : public abbParserVisitor {
public:
...
  virtual std::any visitA1(abbParser::A1Context *ctx) override {
    return visitChildren(ctx);
  }

  virtual std::any visitA2(abbParser::A2Context *ctx) override {
    return visitChildren(ctx);
  }

  virtual std::any visitA3(abbParser::A3Context *ctx) override {
    return visitChildren(ctx);
  }

  virtual std::any visitA4(abbParser::A4Context *ctx) override {
    return visitChildren(ctx);
  }

  virtual std::any visitA5(abbParser::A5Context *ctx) override {
    return visitChildren(ctx);
  }
...
}

[mk-solidat]

much better, thanks!

still some room for improvement I guess. I would prefer if we had multiple arguments that match the rule definition. Also, I found that optional nodes are just pointers that can be null (rather than std::optionals). And yea, the any return type is annoying. I understand that a fixed return type for all rules would be weird, but one per rule maybe? :) So... basically a visitor type per rule?

But this is just me musing about how things could be even nicer. I can work with this api for now.