what Jeff Clites said earlier bears repeating: Read is specified to match
the behavior of source code. thus, its overflow behavior is strictly
correct; if you disagree that numeric literals should be treated that way
in Haskell, your gripe is with core language behavior, not with Read.
it's absolutely a reasonable argument you're making! just, I think you'll
get farther appealing for changes in any other parser.
On Sun, Jul 20, 2025, 11:45 AM Stefan Klinger
More feedback! Thanks =)
Brandon Allbery (2025-Jul-20, excerpt):
If you are using a bounded `Integral` it is expected that you are doing so because you value speed over correctness.
No? It is expected that I'm sure all my calculations fit within that type. Doing things wrong quickly is pointless.
Anyways, I'd like to address the repeated concerns about performance!
I've just added performance testing [1] with criterion to the proposed implementation. If I have done this correctly, then (with a lot of `SPECIALIZE` pragmas), my code seems actually faster than the builtin read — if only a wee bit. Without specialisation, it depends on the size (bits) of the type.
Note that I had no intention to be particularly fast, I would have been satisfied with not-too-slow-but-detecting-overvlows. Turns out, that my implementation seems not that slow at all.
I was getting the impression that I have failed to explain the proposed implementation [2] sufficiently. There is one modulo operation *per literal*, i.e., “per number that one wants to parse”, this is *not* per digit of that number. And there is one comparison per digit — but if one counts the digits instead, then this counting also implies one comparison per digit. Hence, as described before, I was not expecting my code to be particularly slow either.
Tom, thanks again for the pointers, especially `https://ghc.dev/` https://ghc.dev/ and the separate mailing list. I'll try to follow these instructions in the upcoming week.
Following George's advice, I'll try to contact GHC devs there, or try to file a bug. Actually, I was expecting GHC folks to hang about on this mailing list…
George Colpitts (2025-Jul-20, excerpt):
Isn't Victor's suggestion of using Data.ByteString.Char8.readWord8 a workaround for the issue with read?
Well, I was not looking for a workaround (I have one), but rather asking for advice on how to improve the implementations that I find unsatisfying.
Cheers Stefan
[1]: https://github.com/s5k6/robust-int/blob/master/specialized.html [2]: https://github.com/s5k6/robust-int/blob/master/src/Data/RobustInt/Parsec.hs#...
-- Stefan Klinger, Ph.D. -- computer scientist o/X http://stefan-klinger.de /\/ https://github.com/s5k6 \ I prefer receiving plain text messages, not exceeding 32kB.
-- Stefan Klinger, Ph.D. -- computer scientist o/X http://stefan-klinger.de /\/ https://github.com/s5k6 \ I prefer receiving plain text messages, not exceeding 32kB. _______________________________________________ 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.