Let `def(...)` to return the value of `ref(...)`? about dart-petitparser HOT 6 CLOSED

Your proposal mixes two (quite distinct) styles of defining grammars.

The first style is the one you typically see in-lined with normal Dart code. Here you build little grammars, assign them to variables, compose them and use them for parsing/matching right away. This is how most of the tests are built, and the suggested way of building grammars if productions don't refer to themselves and if re-usability is not of a concern.

The second style is the one where you subclass CompositeParser. This is where you declaratively define large, possibly recursive grammars that have possibly different production actions associated. I don't mind letting def(...) return the new production, but it looks to me that you just try to avoid having to refer to productions by name? Did you see CompositeParser2 that uses noSuchMethod(...) to define and refer to productions?

from dart-petitparser.

I just tried CompositeParser2, it works but not friendly to my IDE(I use IDEA dart plugin).

For the code:

    dart_instr_expr =  char(r'$') & block_brace;
    dart_str_single =  char("'") & (dart_instr_expr | string(r"\'") | char("'").neg()).star() & char("'");
    dart_str_double =  char('"') & (dart_instr_expr | string(r'\"') | char('"').neg()).star() & char('"');

The type checker of IDE will warning that it can't resolve the variables like dart_instr_expr, and it won't help to assist the names when I typing.

So I think it's great to let me write code like this:

class MyParser extends CompositeParser {

  var start; 
  var aaa ;

  void initialize() {
    aaa = def("aaa", string("aaa"));  // return value if void !!!
    start = def("start", aaa) ;
    aaa.map((each) => "[$each]");  // action can't work !!
  }
}

In this way, the editor will work perfectly.

from dart-petitparser.

Or provide a powerful function to generate a name for me, that I don't need to write it?

class MyParser extends CompositeParser {

  var aaa ;
  void initialize() {
    aaa = powerful(string("aaa"));  
    def("start", aaa) ;
    aaa.map((each) => "[$each]"); 
  }
}

from dart-petitparser.

Aha, I find I can use a fake class to help IDE:

class PaserDef {
  var aaa;
  var start;
}

class MyParser extends CompositeParser2 implements PaserDef {

  void initialize() {
    aaa = string("aaa");
    start = aaa;
    aaa((each) => "[$each]");
  }

}

main() {
  var parser = new MyParser();
  var rs = parser.parse("aaa");
  print(rs.value);
}

The ParserDef class is only used to help IDE. But the noSuchMethod is still working :)

from dart-petitparser.

The names/variables of CompositeParser or CompositeParser2 are not used by PetitParser, they are purely for the convenience of the grammar designer. Not clear why you try to work around these helpers? Why don't you create your grammar in a factory method or your own helper class then?

from dart-petitparser.

You are right, I didn't realize I can create my own, thank you!

from dart-petitparser.