If you add ambiguous lexemes, and they allow more than one parse, Marpa will track both parses for as long as either remains possible, so backtracking should not be necessary
I read your new message as you taking it that ambiguous lexemes only have a localized effect. Marpa, in fact, pursues all the possible parses as far as they go. The choice of which lexeme to use is *not* made until the parse is complete. If the question is how to look at all those parses, you use repeated calls to $recce->value() to iterate them. If you really want to traverse an ASF as a forest, top-down, Marpa has a interface for this which is AFAIK ground-breaking. Ruslan S. is an expert at this top-down ASF interface. If we are still talking past each other, you might try creating a mini-example, showing what it is that you think Marpa cannot do. On Sun, Feb 15, 2015 at 12:29 PM, Thomas Weigert <[email protected]> wrote: > Ruslan, > > thanks for your reply. So sorry for not being clear enough. > > I am not looking to handle the situation you describe which I believe > pertains to that one recognizes two or more conflicting lexical symbols and > then continues the parse with all these symbols as possible continuations. > > My situation is as follows: I encounter a rejection in the parse and am > recovering. I have two or more ruby slippers prepared, which in this case > are all applicable. If I step into one of the ruby slippers, it will whisk > me away back into the parser and the parser will continue until the ruby > slippers have done their thing. However, at this point we have advanced in > the parse and might have consumed G1 locations and are not in the same > position anymore that we were when we stepped into the ruby slippers. > > But I had other ruby slippers I could have used, and had I stepped into > one of these, I would have ended up with a different parse, potentially. So > I am trying to find a way of stepping into each of the ruby slippers, one > at a time, and getting a partial parse. After I found all the partial > parses from the applicable ruby slippers, I would like for each of these > partial parses to be reflected in the parse forest. > > I would have to do something for this to happen. Recognizing alternative > lexemes is not the way to get there, I believe. I have partial parses that > I need to hand back to the G routines, so they can embed them into their > constructed data structures. > > Maybe I am outside of what is feasible here, but it would be good to know > at least.... > > > On Sunday, February 15, 2015 at 4:12:52 AM UTC-6, rns wrote: >> >> Marpa allows ambiguous lexemes; in external lexing you can read those >> several alternative lexemes via several calls to lexeme_alternative() [1] >> and then a single call to lexeme_complete() [2] and, provided the grammar >> has the appropriate rules, this will lead to a parse forest (use example of >> a parse forest with internal lexing can be found in [3]). >> >> Marpa will use both pairs to continue both parses if you give it a >> grammar which defines rules for such both pairs, example is also in [3]. >> And, if you have enough rules, Marpa will parse the input according to them >> and will allow you to handle the multiple parse results. >> >> >> >> On Sun, Feb 15, 2015 at 8:53 AM, Thomas Weigert <[email protected]> >> wrote: >> >>> I am wondering whether it is possible to generate ambiguous parses with >>> the help of an external lexer. >>> >>> I have the following situation: Upon a rejection event, I am cleaning up >>> in the lexer to be able to continue the parse. However, there are two pairs >>> of ruby slippers I can use. What I would like to do is not to arbitrarily >>> choose one pair and continue the parse, but to use both pairs to continue >>> both parses, potentially resulting in a parse forest. >>> >>> From studying the manual and the available examples, I cannot see how to >>> do this. >>> >>> I would greatly appreciate if anybody could advise whether this is >>> possible, and if so, point me into the right direction. >>> >>> Thanks, Th. >>> >>> -- >>> 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. > -- 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.
