<div dir="ltr">I'm -1 on this proposal.<div><br></div><div>fromInteger and fromIntegral are a huge part of our ecosystem. They comprise a large part of the difference between how we handle numeric literals and how literally every other language on the planet handles numeric literals. fromIntegral shows up all over the place in any code that is even remotely mathematical to deal with converting between integer indices and other numeric types for computation.</div><div><br></div><div>If we pretend Num is about working with rings fromInteger provides the canonical ring homomorphism from Z into every ring, so that half of the equation has to remain in place. toInteger is Integral reason for existence, so you're just asking the existing users to replace fromIntegral with 'fromInteger . toInteger' do dodge a warning that doesn't come with any other clear explanation about how to fix.</div><div><br></div><div>Any properly replacement requires language extensions such as multi parameter type classes that we've failed to demonstrate an ability to standardize as well as n^2 instances and makes it difficult to convert between integral types and numbers supplied by different packages.</div><div><br></div><div>Now, if you wanted to write a package that provided widening and shrinking conversions and this gradually was picked up by a larger and larger cross section of the community and more organically worked its way into base that'd be one thing, but these nicer safe conversions haven't yet been adopted by any significant fraction of the community at this point, so any form of deprecation is very much premature.</div><div><br></div><div>On the other hand I'm definitely +1 on adding documentation to hWaitForInput or on fromIntegral about how you should be careful when switching between numeric types of different sizes.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 21, 2017 at 8:24 AM, Niklas Hambüchen <span dir="ltr"><<a href="mailto:mail@nh2.me" target="_blank">mail@nh2.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is not a joke.<br>
<br>
I just found a bug in base (<a href="https://ghc.haskell.org/trac/ghc/ticket/14262" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/ticket/14262</a>):<br>
<br>
  import System.IO<br>
  hWaitForInput stdin 4294968296<br>
<br>
This code should wait for 49.something days, but it waits for 1 second.<br>
<br>
It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt`<br>
(where CInt = Int32), causing an overflow.<br>
<br>
I argue that `fromIntegral` causes unnoticed data corruption without any<br>
warning, and thus are worse than partial functions.<br>
<br>
In this case, this data corruption occurs in the most fundamental code<br>
that we all use and have to rely upon (`base`).<br>
<br>
So I propose that we add a deprecation pragma to `fromIntegral`<br>
(however, keeping it forever, like Java does, as there's no benefit to<br>
removing it, we just want that people use safer functions over time),<br>
and instead provide a `safeFromIntegral` that can only widen ranges, and<br>
one or more `unsafeFromIntegral` or appropriately named functions that<br>
can error, wrap, return Maybe, or have whatever desired behaviour when<br>
the input value doesn't fit into the output type.<br>
<br>
For some inspiration, `foundation` provides ideas in that direction:<br>
<br>
<a href="http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html" rel="noreferrer" target="_blank">http://hackage.haskell.org/<wbr>package/basement-0.0.2/docs/<wbr>Basement-From.html</a><br>
<a href="http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralConv.html" rel="noreferrer" target="_blank">http://hackage.haskell.org/<wbr>package/basement-0.0.2/docs/<wbr>Basement-IntegralConv.html</a><br>
<br>
It is a bit funny how we argue that Haskell is good for high assurance<br>
programming, and we build all sorts of fancy constructs to eliminate<br>
more run-time errors, when in fact we do worse than C in detecting<br>
errors in the most basic types a computer can use, such as converting<br>
between 64-bit and 32-bit integers.<br>
<br>
Let's fix that.<br>
<br>
It avoids real problems in real production systems that are difficult to<br>
debug when they happen (who writes a unit test checking that a timeout<br>
of 50 days still works? This is the kind of stuff where you have to rely<br>
on -- very basic -- types).<br>
<br>
I'd like to probe support for such a change before doing any work on it.<br>
<br>
Niklas<br>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
</blockquote></div><br></div>