I tried posting this before but, from my point of view, it vanished. My apologies if it's a duplicate. In http://www.cs.uu.nl/~daan/download/parsec/parsec.html we read,
testOr2 = try (string "(a)") <|> string "(b)"
or an even better version:
testOr3 = do{ try (string "(a"); char ')'; return "(a)" } <|> string "(b)"
Why is the latter better? (BTW, I like Parsec. Thanks, Daan. (-:) -- Mark
On Wed, 31 Dec 2003 19:21:54 -0500 (EST)
Mark Carroll
I tried posting this before but, from my point of view, it vanished. My apologies if it's a duplicate.
In http://www.cs.uu.nl/~daan/download/parsec/parsec.html we read,
testOr2 = try (string "(a)") <|> string "(b)"
or an even better version:
testOr3 = do{ try (string "(a"); char ')'; return "(a)" } <|> string "(b)"
Why is the latter better?
As soon as you reach a point where a syntax error means no parse will succeed you want to commit to that alternative for two reasons. 1) As long as there appears to be a possibility for an alternative parse the input needs to be saved and 2) there's no point backtracking if all other alternatives will fail; it just wastes time. In the above example both issues come up. If we successfully parse the "(a" then the second alternative "(b)" can't possibly succeed and since it can't succeed there's no point in saving the input "(a" to be reparsed when backtracking since there's no point in backtracking. Obviously, this example is merely to illustrate the idea as there'd be little to no inefficiency in this case.
Thanks to Tom for his interesting points. I am still developing an inuition for how the error reporting goes. (-: On Thu, 1 Jan 2004, Derek Elkins wrote: (snip)
testOr3 = do{ try (string "(a"); char ')'; return "(a)" } (snip) example both issues come up. If we successfully parse the "(a" then the second alternative "(b)" can't possibly succeed and since it can't succeed there's no point in saving the input "(a" to be reparsed when backtracking since there's no point in backtracking. (snip)
Ah, that makes sense - thanks! I think part of my problem might have been the quoted and real brackets and braces - at least a couple of times, I thought the char and the return were within the try. (-: I will try to look more carefully next time. -- Mark
On Wed, Dec 31, 2003 at 07:21:54PM -0500, Mark Carroll wrote:
I tried posting this before but, from my point of view, it vanished. My apologies if it's a duplicate.
In http://www.cs.uu.nl/~daan/download/parsec/parsec.html we read,
testOr2 = try (string "(a)") <|> string "(b)"
or an even better version:
testOr3 = do{ try (string "(a"); char ')'; return "(a)" } <|> string "(b)"
Why is the latter better?
testOr3 is a bit better at error reporting, for example: *> parseTest testOr2 "(a" parse error at (line 1, column 1): unexpected "a" expecting "(b)" *> parseTest testOr3 "(a" parse error at (line 1, column 3): unexpected end of input expecting ")" But it still gives silly error messages in some cases: *> parseTest testOr3 "(" parse error at (line 1, column 1): unexpected end of input expecting "(b)" The original testOr1 is better here: *> parseTest testOr1 "(a" parse error at (line 1, column 3): unexpected end of input expecting ")" *> parseTest testOr1 "(" parse error at (line 1, column 2): unexpected end of input expecting "a" or "b" *> parseTest testOr1 "" parse error at (line 1, column 1): unexpected end of input expecting "("
(BTW, I like Parsec. Thanks, Daan. (-:)
I like Parsec too :) Tom -- .signature: Too many levels of symbolic links
participants (3)
-
Derek Elkins -
Mark Carroll -
Tomasz Zielonka