On Tuesday, 10 February 2015 12:57:47 UTC+11, Thomas Weigert wrote: > > Thank you for this tip. Indeed, this was an assumption that I was making. > I got the idea from the R.pod: > > "The resume() method uses a new input string to scan the physical input > stream that was specified to the read() method. resume()'s input string > may be specified explicitly or implicitly. By default, the new input string > runs from the current location to the end of the physical input stream." >
I take that to be a doc bug. It can only mean the $pos (and optional $length) passed to resume() tell Marpa whereabouts within the original input stream to resume at (and how long - $length - a string to consider, i.e. how must more of the original input stream to consider). There are 2 courses of action in these situations: 1: Since you know $pos, use your own - called external - scanner to process the tokens starting at the one which $start points to (presumably #), and when finished, set $pos to the end of this substring, and call resume($pos). 2: Off-the-top-of-my-head: Consider changing the rule 'word ::= W' to 'word ::= W | fakecpp', so Marpa finds the # without error, and extend the grammar to handle all things which follow a #. In this case you deliberately sidetrack Marpa to process #ifdef and then let it (with resume($pos) ) naturally return to process the next token, here operator. -- 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.
