[Pharo-project] PetitParser puzzle
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" 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
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"
Now the fun part:
line ^ lineBlank / lineNonBlank
try line ^ lineNonBlank / lineBlank Norbert
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
Oops, sorry, I was too quick the last reply. Norbert 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"
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
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
On 6 May 2011 19:13, Norbert Hartl <norbert@hartl.name> wrote:
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.
Hmm, indeed, hadn't thought of that. Swapping the / sides makes it work.
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.
OK, makes sense. Thanks! -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
participants (2)
-
Damien Pollet -
Norbert Hartl