Re: Am implenting backtracking for the parser-generator

Greg Beaver wrote:

The best approach will be to open a feature request at http://pear.php.net/bugs/report.php?package=PHP_ParserGenerator

Ok.

However, please don't comment out is_expected_token(). This is extremely important code that allows a syntax error to be thrown at the moment it occurs.

Ok. Can you post a simple grammar where it goes wrong when it is commented out?

My basic rule of thumb: don't comment out code just because you don't understand it :)

Of course. I didn't plan to leave it commented out permanently. I was just afraid of ruining something that I didn't really understand, so I commented it out instead of trying to get it to sort-of work with the backtracker without really unrestanding it.

However, if you can demonstrate that your feature does not add bloat and is easy to test for correctness, I would definitely consider adding it.

Okay, great. I will need some time to clean up my code. I will also have to think about a good short example that illustrates the need. All reasonable uses of backtracking will be LALR(n) for some definite n, and it can be shown that all LALR(n) languages are also LALR(1). So the backtracker does only allow for simpler and more straigt forwards grammars. It does not add languages that could not be parsed before. Oh, and the destructor code... I could see no system in when the destructors are called. It seems that they are not called on the rhs-symbols when reducing a rule. Will constructors ever be used for anything in php? I would vote for removing the destructor code. Iirc, PHP already has its own destructor system, allowing for a destructor to be called when gc erases an object. afaics no need to put another system on top of that. -Rune