Hi,
I'm not sure if this is a bug, but I think the problem is in the lexer, not in
the part that that tries to convert a single token to a value of the given type.
Example:
λ:1> lex "123"
[("123","")]
λ:2> lex "123.aaa"
[("123",".aaa")]
λ:3> lex "123.456aaa"
[("123.456","aaa")]
So in "123.aaa" you actually convert "123" to an Int, but in "123.456aaa" you
try to convert "123.456" to an Int, which fails.
Not sure how hard would it be to improve this (while keeping things
standard-compliant) or whether it's worth the effort.
Ömer
Javran Cheng
Hi Cafe,
Not sure if there are existing discussions, but I recently run into a problem with Read instance of Int:
Prelude> :set -XTypeApplications Prelude> reads @Int "123." [(123,".")] Prelude> reads @Int "123.aaa" [(123,".aaa")] Prelude> reads @Int "123.456aaa" [] -- I expected this to be [(123,".456aaa")] Prelude> reads @Double "123.234aaa" [(123.234,"aaa")]
Further investigation shows that [realNumber](http://hackage.haskell.org/package/base/docs/src/GHC.Read.html#readNumber) is used for Read instance of Int. 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.
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. 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), 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.
Javran _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.