Re: Correct parsers for bounded integral values

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 <[email protected]>
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/`
> <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.

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