@Aristotle: Very nicely put. Thanks! On Sat, Nov 22, 2014 at 5:51 PM, Aristotle Pagaltzis <[email protected]> wrote:
> * [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. > -- 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.
