* [email protected] <[email protected]> [2014-11-22 12:10]: > And from my observation this technique only requires parser to stop > (in case of an error or some other event), save it's inner state and > transfer control to lexer. When lexer is done, parser is resumed, > restores its state and continues. Is Marpa's technique somewhat > trickier than that?
No. The difference is in the usefulness of the parser state that was saved before pausing. Particularly when you pause the parser right after the parse has failed: Marpa knows exactly what would have made the parse succeed and you can ask it – then give it what it needed and resume. You might be able to achieve even this with traditional parsers as well… I think. But not by asking the parser! Instead the custom code would have to know exactly which conditions might cause a particular parse failure. I’m unsure right now if that’s even feasible. But even if it is, the custom code is then tightly coupled to the grammar i.e. it will have to be checked and sometimes updated to match the grammar whenever the grammar changes. With Marpa, this approach is not merely hypothetically possible, it is practical and trivial – with custom code that is largely decoupled from the grammar even. Because Marpa actually sees what is happening – how the input is interacting with the grammar. Traditional parsers are essentially blind during the parse: they grope along, committing to the greedily most likely parse at a given point (when they decide to commit), without any real idea why they are there, hoping that it all works out in the end. For valid input, this does eventually work out OK, but if the input isn’t valid, the parser ends up stranded in the middle of nowhere with no idea what happened. Marpa knows exactly what happened. Effectively it can extract the knowledge about possible failures that is implicit in the grammar and expose it to introspection, whereas in traditional parsers the user code surrounding the parser would have to have that knowledge encoded explicitly, redundantly outside the grammar. Hence the coupling to the grammar. This also changes how you write grammars. You can write a grammar that has barely any valid inputs, then introspect its failure conditions to make wide classes of nominally invalid input parse successfully. It’s not that known techniques like pausing, lookahead, etc are somehow trickier with Marpa than with traditional parsers. (Quite the opposite!) It’s that ongoing insight into the parse makes all these same old useful techniques far more effective than they could otherwise be. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
