Thank you all for helping. Putting Jeff and Ron's insights together I was able to come up with a simple solution. I know exactly where in the input string my replacement text is. So I need not inject anything, I can just go there and recognize that text only as my ruby slippers, and then continue at the end of the skipped text.
The insight here provided by Jeff is that it does not matter where in the string the ruby slippers are sitting. As long as I can find them, I can use them. Thanks for the kind guidance. Th. On Mon, Feb 9, 2015 at 10:59 PM, Jeffrey Kegler < [email protected]> wrote: > Still having Internet troubles. > > Two notes: First, the text associated with a lexeme does *NOT* have to be > its value, if you use the lexeme_read() method to read it. That's how you > can do the Ruby Slippers, for example. > > Second, the text is fixed, but you can change how you move around in it -- > you don't have to read it in order. That allows some of the same effects > of changing the text, althjough not all. > > A major reason that the text is fixed, is for error messages. An error > message has to report an error as occurring *somewhere* in the error > stream. But if you provide your own lexeme values, error messages will be > the only place where the lexeme-text association makes a difference. > > On Mon, Feb 9, 2015 at 8:49 PM, Ron Savage <[email protected]> wrote: > >> On Tuesday, 10 February 2015 14:24:56 UTC+11, Thomas Weigert wrote: >>> >>> Thanks, Ron. >>> >>> I see how the Ruby Slippers can work if you know ahead of time what the >>> text will be that we need to insert into the input, so we can "secret it >>> away" before calling read. I guess I could get this to work by prescanning >>> the input for all the text strings, then putting them all into "Ruby >>> Slippers Shoeboxes" at the end of the input string and when hitting one of >>> these tokens doing the Ruby Slipper thing, just like you did in >>> match.parentheses.02.pl >>> >> >> But that prescanning is just what we want Marpa to do! Hmmm. The 4 points >> in your first post are incredibly restrictive. I suggest you revisit that >> topic. For example, if they are all prefixed with #, then life is >> simple(r). If they all end with \n, then that helps too. I still think the >> only way to handle a lot of flexibility in such introns (to use DNA-style >> terminology) is to accept that you'll have to write the grammar for all >> such cases. We can help you simplify it, but ATM it seems far too vague (in >> the nicest possible way, of course :-) to work with. >> >> -- >> 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 a topic in the > Google Groups "marpa parser" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/marpa-parser/tYljqfGS3Aw/unsubscribe. > To unsubscribe from this group and all its topics, 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.
