AFAIK, once you called value(), the recognizer goes to the valuation phase and cannot be put back to the reading phase. value() returns undef to mark the end of the parse series, because you have already retrieved the parse value (there is only one because there is no ambiguity). After calling series_restart(), you can call value() again to re-retrieve the parse.
However, semantics can be done with events -- create completion events for the rules and set up semantic actions in the reading loop to build the parse value. Ron Savage did smth. like that [1]. Another (simpler) example of reading loop with events from which you can start is [2]. BTW, is it exactly the recognizer construction that is the bottleneck? IMO, once the grammar is precomputed, the recognizer can be created from it rather quickly. I used to create a new recognizer for each of 100+ inputs in a test loop and had no a problem. Hope this helps. [1] https://github.com/ronsavage/Text-Delimited-Marpa/blob/master/lib/Text/Delimited/Marpa.pm#L402 [2] https://gist.github.com/rns/ba250ed6a5ed1c82ce7b#file-length-prefixed-pl On Fri, Mar 13, 2015 at 8:26 AM, Thomas Weigert <[email protected]> wrote: > I am struggling with the following: In my application, I have to perform > many parses on the same string. It really drags performance down if I > recreate the recognizer on a new string every time. > > To solve this problem, I attempt to use the same recognizer and string to > perform these parses in a single parse series. I set up the grammar so that > an event is triggered when I recognized enough so that it constitutes a > "parse". At this point I handle what I got and then resume the parsing at > an appropriate point. > > The parsing process works fine using this scheme. Instead of performing a > new parse on the same string, I perform these parse sections on the same > string in the same series. > > But here is the rub: I need to get at the syntax tree that is recognized > at the intermediate stages. But after I call "value" in the recognizer the > first time, I run into trouble: While the parser still is set up and can > continue perfectly fine, any subsequent calls to "value" return undef. > > This is frustrating, because I can see in the lexeme tracing that the > parser continues doing the expected thing, recognizing the fragments I > throw at it. But I can no longer obtain the value constructed. > > I realize that this does not quite follow the rules, since the document on > "Phases" states that the evaluation phase has to come after the reading > phase (it says even strong that if I call "resume" in the evaluation phase > the behavior is undefined, which is what I am doing here). However, Marpa > is clearly set up to not require this, because the parser can continue > after the evaluation phase back in the reading phase. But somehow, I cannot > enter any further evaluation phases. > > I was thinking that maybe starting another parse series might work. So I > do a "series_restart" before I call "resume", but now the evaluation phase > gets confused about the packages it is in. It is not clear to me whether > this is supposed to be supported because the documentation is confusing. It > states that "The series_restart() method must be called before value() > <https://metacpan.org/pod/distribution/Marpa-R2/pod/Scanless/R.pod#value> > when ambiguous() > <https://metacpan.org/pod/distribution/Marpa-R2/pod/Scanless/R.pod#ambiguous> > detects an ambiguous parse and the application needs to get the parse > values." As I am not dealing with an ambiguous parse, this may not apply > but maybe it is meant to be broader. > > Does anybody know if this situation is meant to be supported? > > Thanks, Th. > > > P.S. Marpa provides these amazing possibilities, so maybe I am getting > greedy with what I am trying to accomplish. But parsing has never been more > fun as when I learned about Marpa. > > -- > 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.
