Hi Alan, the way that parboiled (http://parboiled.org) handles this is as follows: parboiled allows your grammar to contain arbitrary "parser action logic" at any position within the rules (so at the beginning, somewhere in between or at the end). Even though you _can_ have actions that exhibit side-effects parboiled recommends the usage of "pure" actions, that are side-effect free except for manipulation of an internal "working" structure, a stack of custom value objects. If a rule fails the parsing engine resets this stack to a snapshot taken before starting rule matching, which, because of efficient implementation, takes only one assignment operation. As long as actions only work on the stack structure they do not have to worry about "cleaning up" on rule mismatches. If they do have side-effects they are responsible for managing these themselves.
Concerning this issue with packrat parsing (rather than backtracking): parboiled does not do packrat parsing but rather concentrates on providing a really efficient backtracking engine, since I have yet to see a real-word example where packratting does actually increase parsing performance over an efficient parser without the overhead of creating and managing the rule match cache. If anyone has such an example I would be very interested... Cheers, Mathias --- math...@parboiled.org http://www.parboiled.org On 20.10.2010, at 00:59, Alan Post wrote: > Hello List, > > I've just started using and working on a packrat parser. > > My specific problem is that I have an input language that I want to > transform into an output language and collect some data about what > occured during the parse. > > As a simple example, imagine the following grammar and code: > > start <- a b c / b > > a <- 'a' {print "a"} > b <- 'b' {print "b"} > c <- 'c' {print "c"} > > If I give the input "ab", this is is not a valid string, but if the > code immediately executes during the parse, It will print both "a" > and "b". A more complex example might parse a fair part of the input > before backtracking. > > Given that backtracking could make code executed in-place like this > invalid, what is typical in a packrat parser if the code can be > specified inline like this? > > Do I limit myself to non-destructive (functional) operations? Do I > collect the code snippets and execute all of them after a valid parse? > Something else? > > Thank you for your help, > > -Alan > -- > .i ko djuno fi le do sevzi > > _______________________________________________ > PEG mailing list > PEG@lists.csail.mit.edu > https://lists.csail.mit.edu/mailman/listinfo/peg _______________________________________________ PEG mailing list PEG@lists.csail.mit.edu https://lists.csail.mit.edu/mailman/listinfo/peg
