[Haskell-cafe] a bug in Read instance of Int?
Ömer Sinan Ağacan
omeragacan at gmail.com
Thu Mar 28 10:07:42 UTC 2019
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.
λ:1> lex "123"
λ:2> lex "123.aaa"
λ:3> lex "123.456aaa"
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.
Javran Cheng <javran.c at gmail.com>, 27 Mar 2019 Çar, 10:17 tarihinde şunu yazdı:
> 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."
> Prelude> reads @Int "123.aaa"
> Prelude> reads @Int "123.456aaa"
>  -- I expected this to be [(123,".456aaa")]
> Prelude> reads @Double "123.234aaa"
> 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.
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
More information about the Haskell-Cafe