Deprecating fromIntegral

[Edward Kmett]

I'm -1 on this proposal.

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.

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.

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.

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.

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.

-Edward

On Thu, Sep 21, 2017 at 8:24 AM, Niklas Hambüchen <mail at nh2.me> wrote:

> This is not a joke.
>
> I just found a bug in base (https://ghc.haskell.org/trac/ghc/ticket/14262
> ):
>
>   import System.IO
>   hWaitForInput stdin 4294968296
>
> This code should wait for 49.something days, but it waits for 1 second.
>
> It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt`
> (where CInt = Int32), causing an overflow.
>
> I argue that `fromIntegral` causes unnoticed data corruption without any
> warning, and thus are worse than partial functions.
>
> In this case, this data corruption occurs in the most fundamental code
> that we all use and have to rely upon (`base`).
>
> So I propose that we add a deprecation pragma to `fromIntegral`
> (however, keeping it forever, like Java does, as there's no benefit to
> removing it, we just want that people use safer functions over time),
> and instead provide a `safeFromIntegral` that can only widen ranges, and
> one or more `unsafeFromIntegral` or appropriately named functions that
> can error, wrap, return Maybe, or have whatever desired behaviour when
> the input value doesn't fit into the output type.
>
> For some inspiration, `foundation` provides ideas in that direction:
>
> http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html
> http://hackage.haskell.org/package/basement-0.0.2/docs/
> Basement-IntegralConv.html
>
> It is a bit funny how we argue that Haskell is good for high assurance
> programming, and we build all sorts of fancy constructs to eliminate
> more run-time errors, when in fact we do worse than C in detecting
> errors in the most basic types a computer can use, such as converting
> between 64-bit and 32-bit integers.
>
> Let's fix that.
>
> It avoids real problems in real production systems that are difficult to
> debug when they happen (who writes a unit test checking that a timeout
> of 50 days still works? This is the kind of stuff where you have to rely
> on -- very basic -- types).
>
> I'd like to probe support for such a change before doing any work on it.
>
> Niklas
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170921/19a9b295/attachment-0001.html>