Hi Victor! > Le 20 févr. 2020 à 04:07, Morales Cayuela, Victor (NSB - CN/Hangzhou) > <[email protected]> a écrit : > > Hi! > >> It really depends what you'd like to do. You reported you're fluent in C++. >> Something quite interesting would be to enable push-parser in lalr1.cc. >> It's more ambitious than the subcomplain task, but it will probably take you >> less time, because it's more compact, it will impact much less code. > > Ok, seems very interesting! I use C++ (currently C++17) in my daily job as a > developer and I always try to keep up with the latest of the standard. > I will familiarize myself first with push/pull parsers and then I will start > with it 😊 I will also take a look at TODO to check if there is already any > specification about how it should look like.
I think all the information you need is in the manual, in the push example in C (see examples/c/pushcalc), and in yacc.c's implementation of push. Actually, Java also has push-parser support, and is probably a better source of inspiration than C. I recommend that you first build by hand a push parser before trying to get this done by m4. For instance take examples/c++/calc++, and change the generated parser so that it works as a push parser. Keep this preciously somewhere to make sure "make" doesn't kill it. When it works, you can show us a diff between the regular pull parser and the push parser, and when we agree, we can proceed to make it work in m4. Actually, maybe examples/c++/calc++ is too bloated: first create a very simple example in C++, similar to examples/c/calc. Start from this one, it is much simpler, and yet sufficient. Most of the effort, I guess, is finding what local variables must be turned into member variables, to survive across calls to yyparse (amusingly enough coroutines would make this easy, but we can't afford them yet ;-). But lalr1.java should help. Note that C++ allows to consider other options than the C parsers. Since the C++ parser is an object, maybe we can have push and pull use the same object. I mean, *maybe*, we can *always* move most local variables into member variables, even for regular pull-parsing. Of course it's technically possible, the "maybe" refers to the runtime cost: *if* benchmarks show that it is not a regression to move to a model with more member variables and less local variables, then the m4 part will be much easier. Maybe you should start with that: find a means to benchmark two pull parsers: one off-the-shelf, generated by today's lalr1.cc, and another one where the local variables that need to be member variables in push-mode are made member variables. How does that sound?
