While I haven't tried out your example in parsec, I can at least confirm that in trifecta it does work that way you expect it, ie. there is no difference between the error messages in both of your cases: (parsec's many1 = trifecta's some) Prelude > :m +Text.Trifecta Prelude Text.Trifecta > :m +Text.Parser.LookAhead Prelude Text.Trifecta Text.Parser.LookAhead > ... Prelude Text.Trifecta Text.Parser.LookAhead > parseTest (lookAhead (char 'a') >> char 'b') "a" ... Loading package reducers-3.10.2.1 ... linking ... done. Loading package trifecta-1.5.1 ... linking ... done. (interactive):1:1: error: expected: "b" a<EOF> ^ Prelude Text.Trifecta Text.Parser.LookAhead > parseTest (lookAhead (some $ char 'a') >> char 'b') "a" (interactive):1:1: error: expected: "b" a<EOF> ^ Prelude Text.Trifecta Text.Parser.LookAhead > Hope this helps. -Andreas silly8888 writes:

Suppose that we have the following parser:

p = lookAhead (char 'a') >> char 'b'

If we use it like so

parse p "" "a"

we get the following error:

Left (line 1, column 1): unexpected "a" expecting "b"

What happened is that char 'a' succeeded by consuming the 'a' from the input and then lookAhead rewinded the input stream (as it does on success). Then, char 'b' tries to parse (again) the first character of the input and fails. Everything works as expected.

Now let's slightly modify our parser:

p' = lookAhead (many1 $ char 'a') >> char 'b'

I've only added a many1. I was expecting this parser to give the same error as the previous one: many1 $ char 'a' will succeed consuming one 'a' and then lookAhead will rewind the input (as it does on success). Thus when we call char 'b' we are going to be in the beginning of the input again. Well, that doesn't happen:

Left (line 1, column 2): unexpected end of input expecting "b"

As you can see, lookAhead did not rewind the input as it was supposed to. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe