Ok, next try.
Am 06.05.2011 um 13:59 schrieb Damien Pollet: > I have a unit test for a parser of mine: > > testLine > self fail: 'Just a line.' rule: #lineBlank. "passes" > self parse: 'Just a line.' rule: #lineNonBlank. "passes" > self parse: 'Just a line.' rule: #line. "end of input > expected at 0" > Here you test if the parser can consume all of the string. But it different to the situation if the parser succeeds. A star parser always succeeds. And the operator / only matches of the parser on the left side couldn't succeed. In the "line" case the lineBlank succeeds thus the right one is not tried. So no characters are consumed and the test fails because it does not parse. That was what first came to my mind but then I thought this might be just a hack to reverse the order of ther parser. But my initial mail was right. The more specific parser should go before to all matching parser. hope this helps, Norbert > Now the fun part: > > line > ^ lineBlank / lineNonBlank > > For reference, here are the rest of the involved rules: > > blank > ^ #blank asParser > > lineBlank > ^ blank star > > lineNonBlank > ^ blank star , blank not , lineEnd negate plus > > lineEnd > ^ (Character lf asParser) > / (Character cr asParser , Character lf asParser optional) > > Insights ? > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >
