Deprecating fromIntegral

[Niklas Hambüchen]

Hey Henning,

On 21/09/17 15:21, Henning Thielemann wrote:
> That's all very true! Other safety oriented languages like Modula-3 at
> least perform a runtime check on integer conversion.
> 
> However, I'd like to see practical solutions first before adding
> deprecations.

I agree, deprecating before finding a solution doesn't make sense.

I intend this thread to be mainly about discussing possible solutions
and problems with them, hopefully we'll find something good.

> fromInteger will always be partial when converting to a fixed width
> integer. fromInteger is used for converting number literals to the
> wanted type. Thus every number literal will issue a warning and I cannot
> see how to circumvent this.

Yes. I would say though that `fromInteger` being partial is a less
severe problem than `fromIntegral`'s silent overflow; if a `fromInteger`
fails partially, you'd at least get a nice run-time error, which would
be better.

(Though, in practice the current `fromInteger is not partial, e.g.
`(fromInteger 256 :: Word8) == 0` without error, and I suspect it would
be good if we added a partial function in addition to the silently
wrapping one here too.)

> Another problem I see is that integralUpsize and integralDownsize are
> not Haskell 98 and multi-parameter type classes are not really
> satisfying here because you have to define n^2 instances for n types. A
> convenient conversion function would certainly need even more advanced
> types, e.g. type-level comparison of bit widths.

That's a good point, and that's why I think that...

> For now the least invasive solution would be to provide a partial
> integer conversion function.

... this might be a good first step.

It would turn

 "You ship code into production and 50 days later it corrupts your data"

into

 "You ship code into production and 50 days later it crashes"

which is already much better, and, I believe, easy to implement.

> If we have fixed fromIntegral then the next natural question would
> arise: How to protect arithmetic operations plus, minus, times against
> overflow? Aren't overflows as dangerous as losing bits on integer
> conversion? Is there a solution that works both for conversion and
> arithmetics?

Yes, all types of overflows can be problematic and dangerous.

You could say though that overflows "within the type" are somewhat less
problematic: Arithmetic overflows are more well-known and in people's
minds, it is relatively easy for a programmer to pick a type that is
large enough so that "+" doesn't overflow, and that only stops working
once you need to convert to another type, when the `fromIntegral`
problem occurs.
In "their own types", people work confidently, it's when interfacing
with others' code where the big bugs occur (like in the example I gave).

Haskell provides easy methods to prevent overflow *within* one's own
numeric types if one desires (like implementing "+" with `error` if it
doesn't fit); but currently our conversion functions *between* types
don't give us good explicit means to do so.

Also, how to deal with in-type overflows is an unsolved problem in
general, while C already solves much of the conversion problem.

I think solving the parts that C has solved would already avoid a good
amount of bugs.

> As always, I object to use the terms 'safe' and 'unsafe' when actually
> 'total' and 'partial' are meant. LLVM uses 'ext' and 'trunc'. I'd prefer
> names along these lines.

Good point.

I used "safe" and "unsafe" to express the idea that one kind would
always succeed in the naturally expected fashion and one would not, but
the more precisely the naming is, the better.