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