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 <haskell@stefan-klinger.de> wrote:
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/` 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#L56-L64


--
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.