[Haskell-cafe] a bug in Read instance of Int?
javran.c at gmail.com
Fri Mar 29 03:22:42 UTC 2019
Thanks for the responses! If Haskell report says so, it's fine to leave it
as it is - I do have it in mind that Read isn't supposed to be used this
To be fair, "(x,s) is an element of (readsPrec d (showsPrec d x s))" is
indeed a stronger property than it needs to be.
But still, it is worth taking a note as concerns when using `readS_to_P
On Thu, Mar 28, 2019 at 4:09 AM Brent Yorgey <byorgey at gmail.com> wrote:
> The 2010 Haskell Report specifies that
> (x,"") is an element of (readsPrec d (showsPrec d x ""))
> Notice it does NOT say that
> (x,s) is an element of (readsPrec d (showsPrec d x s))
> which would be false, as your example shows by setting x = 123 and s =
> read really isn't meant to be a general-purpose parser; it only works on
> sequences of lexical tokens. As Ömer points out, reads @Int and reads
> @Double both depend on 'lex', and there is no way for 'lex' to know what
> kind of thing reads is ultimately trying to parse. If you changed lex so
> that lex "123.456aaa" returns [("123", ".456aaa")] then reads @Double would
> break. I suppose you could try to change lex so that lex "123.456aaa"
> returns [("123", ".456aaa"), ("123.456", "aaa")] but this seems like a lot
> of work for little benefit. If you are running into this kind of issue
> with Read instances, it strongly suggests to me that you should be using a
> proper parsing library rather than Read.
> On Thu, Mar 28, 2019 at 5:08 AM Ömer Sinan Ağacan <omeragacan at gmail.com>
>> 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"
>> 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
>> > 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](
>> 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.
>> 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.
Javran (Fang) Cheng
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe