try works in this case, but it won't if we are using a parser which can consume and then fail (instead of char 'a'). In which case we may want it to fail without exploring the second option.<br><br>Hmmm though you might be right. Having lookAhead return Consumed is
only a problem if the parser passed to lookAhead succeeds, but the
parser following lookAhead fails without consuming, which seems like a fairly rare case.<br><br>Although, it would be a problem for cases where the lookAhead is checking for a negation. For example:<br>parseStuff = (lookAhead parseNotCapital >> identifier) <|> number<br>
wouldn't work if lookAhead returned Consumed on success, and try doesn't save us either.<br><br>Even if returning "Consumed" is the desired behavior I'd still say it at least deserves a note in the docs.<br>
<br>Martijn, how did you encounter this problem?<br><br>- Job<br><br><br><div class="gmail_quote">On Thu, Aug 20, 2009 at 2:21 PM, Christian Maeder <span dir="ltr"><<a href="mailto:Christian.Maeder@dfki.de">Christian.Maeder@dfki.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Daniel Fischer wrote:<br>
> Am Donnerstag 20 August 2009 13:44:15 schrieb Martijn van Steenbergen:<br>
>> Goedemiddag café,<br>
>><br>
>> Consider the following function, using parsec-3.0.0:<br>
>>> la :: Parsec String () (Maybe Char)<br>
>>> la = lookAhead (optionMaybe anyChar)<br>
>> *Lookahead> parseTest (char 'a' <|> char 'b') "a"<br>
>> 'a'<br>
>> *Lookahead> parseTest (char 'a' <|> char 'b') "b"<br>
>> 'b'<br>
>> *Lookahead> parseTest (la *> char 'a' <|> char 'b') "a"<br>
>> 'a'<br>
>> *Lookahead> parseTest (la *> char 'a' <|> char 'b') "b"<br>
>> parse error at (line 1, column 2):<br>
>> unexpected "b"<br>
>> expecting "a"<br>
>><br>
>> The first three work fine and as expected, but the fourth example fails<br>
>> where I would expect success. I know <|> won't try the rhs if the lhs<br>
>> consumed input, but lookAhead's documentation promises not to consume<br>
>> any input. Is this a bug in Parsec or am I missing something?<br>
><br>
> Bad bug in Parsec (from the beginning, the same happens in parsec-2), I'd say.<br>
<br>
</div>I'd say, its a feature. lookAhead returns whatever its argument returns.<br>
So in this case it returns "Consumed" without consuming.<br>
<br>
You can always wrap around a "try" to force the alternative:<br>
<br>
parseTest (try (la >> char 'a') <|> char 'b') "b"<br>
<br>
Cheers Christian<br>
<br>
Maybe it should have been:<br>
<div class="im"><br>
la >> (char 'a' <|> char 'b')<br>
<br>
</div>in the first place.<br>
<div><div></div><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>