Deprecating fromIntegral

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating fromIntegral

Niklas Hambüchen
On 26/09/17 22:56, Bardur Arantsson wrote:
> The idea is that you get literally
> every warning that the compiler developers can think of and then have to
> selectively turn off individual warnings. This squares pretty well with
> the
> 'deprecation-before-we-have-replacements-because-you-can-provide-your-own'
> narrative, at least.

I feel like "every warning that the compiler developers can think of"
and the motivation we're going after here are pretty far apart.

Warning when one type doesn't fit into another part is not something
that should be in a "low risk warning category".

I was suggesting we might want to have a flag that is free from the
3-release-policy (a backwards-compatibility mechanism); I was not
suggesting to have more verbose warning categories.

In other words, the intent of that would be to be able to subscribe to
warnings that will be enabled in `-Wall` in ~3 years, already at the
current release.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating fromIntegral

Niklas Hambüchen
In reply to this post by David Feuer
On 26/09/17 21:46, David Feuer wrote:
> David Luposchainsky drafted the MonadFail proposal in December 2013,
>
> So it seems that there was a fairly clear consensus that having fail
> in Monad was a bad idea almost ten years ago

I'm aware of that and didn't suggest otherwise.

I was replying specifically to:

> 4. Then once it has been around in base [... for 3 releases ...] then
we could build consensus to perform a deprecation of the existing method.

This suggests that the order is:

1. put it in base
2. wait 3 releases
3. build consensus about deprecation

I pointed out (and you did now, too, more elaborately) that in the case
of MonadFail, the consensus about deprecation step (3) was done before
(1) and (2).
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating fromIntegral

Jon Fairbairn
In reply to this post by Niklas Hambüchen
Niklas Hambüchen <[hidden email]> writes:

>> I'm -1 on deprecating it, and +1 on adding additional conversion
>> functions of various sorts: explicit widening, explicit narrowing, etc.
>
> What is your reasoning against deprecating it?

May I just interject that fromIntegral itself is not the
problem. There’s nothing wrong with “fromIntegral 5::Ratio
Integer” for example. The problem is having the type “(Num b,
Integral a) => a->b”, which drags in all the horror that is Num.

A type more like “(Integral a, InfinitePrecisionNumber b) => a
-> b” (and an appropriate definition of the class) would allow
its continued use in places where it’s safe.

--
Jón Fairbairn                                 [hidden email]


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating fromIntegral

Sven Panne-2
In reply to this post by Niklas Hambüchen
2017-09-28 0:22 GMT+02:00 Niklas Hambüchen <[hidden email]>:
This suggests that the order is:

1. put it in base
2. wait 3 releases
3. build consensus about deprecation
[...]

For the current proposal I would really like to see:

   0. Put the proposed functions into a separate package

At least for me, it's far from clear what exactly has to be added, how usable it would be, how many changes are needed in libraries/apps out in the wild etc., and removing/changing broken things from base is very, very hard. So it would be wise to let a proposal mature in a separate package. But that's a general remark for everything which should go into base.

Regarding fromIntegral: I fail to see why this function should be special in any way. If you use one of the fixed-width integral types, you basically opt-in into a world of wrap-arounds, silent under-/overflows etc. As already mentioned in this thread, this doesn't only happen when fromIntegral is used, it can happen for tons of other operations, too. For the same reasoning, one would have to deprecate (+), (-), (*) etc. on fixed-width types.

So in a nutshell: -1 for deprecating fromIntegral, +1 for additional conversions (but not in base yet).


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
123