<div dir="ltr">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 way.<div><div>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.</div><div>But still, it is worth taking a note as concerns when using `readS_to_P reads`.<br></div><div><br></div><div>Cheers,</div><div>Javran</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 28, 2019 at 4:09 AM Brent Yorgey <<a href="mailto:byorgey@gmail.com">byorgey@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The 2010 Haskell Report specifies that<div><br></div><div><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center">(x,"")</span><span style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium;text-align:center"> is an element of </span><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center">(readsPrec</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center"> d</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center"> (showsPrec</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center"> d</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center"> x</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center"> ""))</span><br></div><div><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center"><br></span></div><div><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center">Notice it does NOT say that</span></div><div><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center"><br></span></div><div><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center"><span class="gmail-m_1709458858869157819gmail-pcrr7t-">(x,s)</span><span style="font-family:"Times New Roman";font-size:medium"> is an element of </span><span class="gmail-m_1709458858869157819gmail-pcrr7t-">(readsPrec</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-"> d</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-"> (showsPrec</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-"> d</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-"> x</span><span class="gmail-m_1709458858869157819gmail-pcrr7t-"> s))</span><br></span></div><div><span class="gmail-m_1709458858869157819gmail-pcrr7t-" style="font-family:monospace;color:rgb(0,0,0);text-align:center"><span class="gmail-m_1709458858869157819gmail-pcrr7t-"><br></span></span></div>which would be false, as your example shows by setting x = 123 and s = ".456".<br><br>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.<br><br>-Brent</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 28, 2019 at 5:08 AM Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I'm not sure if this is a bug, but I think the problem is in the lexer, not in<br>
the part that that tries to convert a single token to a value of the given type.<br>
Example:<br>
<br>
    λ:1> lex "123"<br>
    [("123","")]<br>
<br>
    λ:2> lex "123.aaa"<br>
    [("123",".aaa")]<br>
<br>
    λ:3> lex "123.456aaa"<br>
    [("123.456","aaa")]<br>
<br>
So in "123.aaa" you actually convert "123" to an Int, but in "123.456aaa" you<br>
try to convert "123.456" to an Int, which fails.<br>
<br>
Not sure how hard would it be to improve this (while keeping things<br>
standard-compliant) or whether it's worth the effort.<br>
<br>
Ömer<br>
<br>
Javran Cheng <<a href="mailto:javran.c@gmail.com" target="_blank">javran.c@gmail.com</a>>, 27 Mar 2019 Çar, 10:17 tarihinde şunu yazdı:<br>
><br>
> Hi Cafe,<br>
><br>
> Not sure if there are existing discussions, but I recently run into a problem with Read instance of Int:<br>
><br>
> Prelude> :set -XTypeApplications<br>
> Prelude> reads @Int "123."<br>
> [(123,".")]<br>
> Prelude> reads @Int "123.aaa"<br>
> [(123,".aaa")]<br>
> Prelude> reads @Int "123.456aaa"<br>
> [] -- I expected this to be [(123,".456aaa")]<br>
> Prelude> reads @Double "123.234aaa"<br>
> [(123.234,"aaa")]<br>
><br>
> Further investigation shows that [realNumber](<a href="http://hackage.haskell.org/package/base/docs/src/GHC.Read.html#readNumber" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/base/docs/src/GHC.Read.html#readNumber</a>) is used for Read instance of Int.<br>
> 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.<br>
><br>
> 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.<br>
> 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),<br>
> 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.<br>
><br>
> Javran<br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Javran (Fang) Cheng<br></div></div>