Proposal: Improve Read Integer
Proposal: Improve Read Integer http://hackage.haskell.org/trac/ghc/ticket/4500 Currently, according to H98, H2010, GHC and hugs, reads "1.2" :: [(Integer, String)] is [] whereas I would expect it to be [(1,".2")] Patch: http://hackage.haskell.org/trac/ghc/attachment/ticket/4500/read-integer.dpat... Suggested deadline: 1 Dec 2010. Thanks Ian
Ian Lynagh wrote:
Proposal: Improve Read Integer http://hackage.haskell.org/trac/ghc/ticket/4500 Currently, according to H98, H2010, GHC and hugs, reads "1.2" :: [(Integer, String)] is [] whereas I would expect it to be [(1,".2")] http://hackage.haskell.org/trac/ghc/attachment/ticket/4500/read-integer.dpat...
This is a good change. But for GHC the patch is not complete. It needs to provide the old behavior in H98 and H2010 mode. Thanks, Yitz
On Tue, Nov 16, 2010 at 11:04:05PM +0200, Yitzchak Gale wrote:
Ian Lynagh wrote:
Proposal: Improve Read Integer http://hackage.haskell.org/trac/ghc/ticket/4500 Currently, according to H98, H2010, GHC and hugs, reads "1.2" :: [(Integer, String)] is [] whereas I would expect it to be [(1,".2")] http://hackage.haskell.org/trac/ghc/attachment/ticket/4500/read-integer.dpat...
This is a good change. But for GHC the patch is not complete. It needs to provide the old behavior in H98 and H2010 mode.
To do this we'd have to have a separate Integer type in haskell98/haskell2010, and therefore separate definitions of all classes and functions whose types contain Integer, and different default type defaulting. I doubt anyone relies on the current behaviour, and I think it's just an oversight (i.e. bug) in the language definition anyway. So I suggest we shouldn't be strictly backwards compatible in this case. Thanks Ian
I wrote:
This is a good change. But for GHC the patch is not complete. It needs to provide the old behavior in H98 and H2010 mode.
Ian Lynagh wrote:
To do this we'd have to have a separate Integer type in haskell98/haskell2010, and therefore separate definitions of all classes and functions whose types contain Integer, and different default type defaulting.
Effectively, we are talking about a library change for Haskell 2011. This is the version of Haskell Prime where we expect such changes, including Prelude changes, to begin happening, so this won't be the only one. Breaking changes to the base libraries have sometimes created quite a mess. May I mention extensible exceptions? I think Simon did a great job on the module design side, but I hope we are a little wiser now about how that process should go in Cabal, on Hackage, and for the Haskell Platform. What mechanism are you proposing?
I doubt anyone relies on the current behaviour, and I think it's just an oversight (i.e. bug) in the language definition anyway.
The current behavior is consistent with the behavior of just about every other popular programming language. Of course, most of them are sullied with all kinds of horrid numeric type coercion, and you are absolutely correct that this unseemliness should not be allowed to seep into Haskell's pristine waters. But most people wouldn't think of it at first. That's probably why the Read instance is what it is. And I'm not sure you're correct that no one has ever unthinkingly relied upon that behavior.
So I suggest we shouldn't be strictly backwards compatible in this case.
Perhaps that is OK, perhaps not. In any case, we do need a sane mechanism for introducing these kinds of library changes simply while at the same time providing a reasonable deprecation process with legacy support. Thanks, Yitz
On 11/17/10 02:33, Yitzchak Gale wrote:
I doubt anyone relies on the current behaviour, and I think it's just an oversight (i.e. bug) in the language definition anyway.
The current behavior is consistent with the behavior of just about every other popular programming language.
C strtol() has the behavior Ian proposed, FWIW. (it parses 1.2 yielding the value equal to 1 and the location starting at the beginning of ".2".) -Isaac
The current behaviour is consistent with how Haskell tokenizes at the
source level.
I find this easy to remember, and I would be surprised if read behaved
the way you suggest.
-- Lennart
On Tue, Nov 16, 2010 at 8:34 PM, Ian Lynagh
Proposal: Improve Read Integer http://hackage.haskell.org/trac/ghc/ticket/4500
Currently, according to H98, H2010, GHC and hugs, reads "1.2" :: [(Integer, String)] is [] whereas I would expect it to be [(1,".2")]
Patch: http://hackage.haskell.org/trac/ghc/attachment/ticket/4500/read-integer.dpat...
Suggested deadline: 1 Dec 2010.
Thanks Ian
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On the other hand,
import Numeric
main = do
print (readDec "1.2" :: [(Integer,String)])
print (readSigned readDec "1.2" :: [(Integer,String)])
currently gives
[(1,".2")]
[]
The behaviour of readDec is entirely as I would expect - the behaviour of readSigned is not. I think it is confusing that (readSigned readDec) and readDec give different results. As the errata maintainer of the Haskell'98 Report, I would be prepared to regard the current behaviour of readSigned as a Report bug, if there is consensus. I'm not sure whether Haskell'2010 has an errata maintainer.
Regards,
Malcolm
On 17 Nov, 2010,at 09:00 AM, Lennart Augustsson
Proposal: Improve Read Integer http://hackage.haskell.org/trac/ghc/ticket/4500
Currently, according to H98, H2010, GHC and hugs, reads "1.2" :: [(Integer, String)] is [] whereas I would expect it to be [(1,".2")]
Patch: http://hackage.haskell.org/trac/ghc/attachment/ticket/4500/read-integer.dpat...
Suggested deadline: 1 Dec 2010.
Thanks Ian
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Wed, Nov 17, 2010 at 09:00:07AM +0000, Lennart Augustsson wrote:
The current behaviour is consistent with how Haskell tokenizes at the source level. I find this easy to remember, and I would be surprised if read behaved the way you suggest.
Hmm, my intuition was that reads would accept any prefix that parses, but that isn't true (e.g. reads "Truefoo" :: [(Bool, String)]). I'll close the proposal. Thanks Ian
participants (5)
-
Ian Lynagh -
Isaac Dupree -
Lennart Augustsson -
malcolm.wallace -
Yitzchak Gale