<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Cafe,<div><br></div><div>Not sure if there are existing discussions, but I recently run into a problem with Read instance of Int:</div><div><font face="monospace, monospace"><br></font></div><div><div><font face="monospace, monospace">Prelude> :set -XTypeApplications </font></div><div><font face="monospace, monospace">Prelude> reads @Int "123."</font></div><div><font face="monospace, monospace">[(123,".")]</font></div><div><font face="monospace, monospace">Prelude> reads @Int "123.aaa"</font></div><div><font face="monospace, monospace">[(123,".aaa")]</font></div><div><font face="monospace, monospace">Prelude> reads @Int "123.456aaa"</font></div><div><font face="monospace, monospace">[] -- I expected this to be [(123,".456aaa")]</font></div><div><font face="monospace, monospace">Prelude> reads @Double "123.234aaa"</font></div><div><font face="monospace, monospace">[(123.234,"aaa")]</font></div><div><br></div><div>Further investigation shows that [realNumber](<a href="http://hackage.haskell.org/package/base/docs/src/GHC.Read.html#readNumber">http://hackage.haskell.org/package/base/docs/src/GHC.Read.html#readNumber</a>) is used for Read instance of Int.</div><div>I think what happened is that when the leading parser input can be parsed as a floating number, it will do so and commit to that decision, making backtracking impossible.</div><div><br></div><div>I do understand that Read just need to be able to parse whatever Show can produce and is not designed to deal with raw inputs, but this is still a surprising behavior to me.</div><div>When I'm using Text.ParserCombinators.ReadP, I really appreciates it that I can use `readP_to_S read` to parse simple values (integers and floating points in particular),</div><div>but it bothers me that parsing Int from "123.aaa" is fine but "123.1aa" will fail simply because the not-yet-consumed part of input is different.</div><div><br></div><div dir="ltr" class="gmail_signature"><div>Javran</div></div></div></div></div></div>