If you use ambiguous lexemes, you can step into all the Ruby Slippers at once. So you do get whisked away, but it is to everywhere.
On Sun, Feb 15, 2015 at 1:16 PM, Thomas Weigert <[email protected]> wrote: > Jeff, > > yes, I am sorry, I believe we are still not talking about the same > situation. I'll concoct an example, but let me try one more time now.... > > The ambiguity in my situation does not come from that the lexer encounters > an ambiguous lexeme. My problem is that I encounter a parsing problem and > try to fix it up. However, there are two or more legitimate ways of fixing > it up. Any of these ways of fixing up the parse will lead to a good parse. > I want to have all of these reflected in the final parse forest. > > The way I fix up the interrupted parse is by using ruby slippers. I grab > an arbitrary slipper (all of the ruby slippers will lead to good parses) > and step into them. When I kick of the ruby slipper with resume it parses > the whole text handed over by the ruby slippers, which results in a moving > of the G1 location. I get back control in the external lexer after this, > but I am not in the previous location any more as far as the parse is > concerned. I can now not just step into the next ruby slipper and try > again, as this assumes that I am still in the previous location. So while I > know exactly what the other possible parses are (they would result from > stepping into the other ruby slippers), I can no longer step into them as > they are no longer applicable. The first ruby slipper has whisked me away. > > If I could somehow access before I step into the ruby slippers the parser > location and roll back when I return from the ruby slipper journey, then I > could step into the next slipper. But all I got is the position in the > input stream. > > Th. > > > > On Sunday, February 15, 2015 at 2:49:03 PM UTC-6, Jeffrey Kegler wrote: >> >> >> >> 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: >> >>> >>> >>> 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. > -- 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.
