Deprecating fromIntegral

[Thomas Jakway]

I can see both sides of this and am dismayed.  On the one hand, -Wall 
literally means with all warnings--so it makes sense to pack as many 
warnings as possible into it.  If that's too many warnings for the end 
user, they can disable individual ones when looking through the output.  
If we wanted to be really thorough we could provide a suggestion at the 
end of the output ("90% of your warnings are from ____").  On the other 
hand,

grep -I -R --include="*.hs" "fromIntegral" | wc -l

on ghc prints 2598, which is a lot.

For what it's worth I'm in favor of adding it to -Wall because I would 
rather be warned about too many things and have to force myself not to 
ignore them than spend a long time figuring out the source of a bug.  At 
the very least when I do encounter a bug it'll give me somewhere to start.

There's no great solution here, only tradeoffs.  I won't lose any faith 
in Haskell whichever route we take.

On 09/22/2017 02:53 PM, Evan Laforge wrote:
 > On Thu, Sep 21, 2017 at 4:19 PM, Niklas Hambüchen <mail at nh2.me> wrote:
 >> On 21/09/17 19:27, Evan Laforge wrote:
 >>> If I were to suddenly get 10,000 lines of warnings...
 >> If the built tool is set up sensibly (perhaps we should make it so if
 >> that is not already possible, but I think these days warnings of
 >> dependency packages are omitted anyway, as cabal and stack build them in
 >> parallel), you should get (and care about and fix) only warnings about
 >> those occurrences that are in the packages you maintain / build 
directly.
 > I mean dependencies within the project, not external packages.  If
 > modify something in the middle of the dependency tree, I'll be usually
 > recompiling (say) a couple of hundred modules, for my personal
 > medium-ish project.  I assume in a real company with a larger codebase
 > you could easily be recompiling thousands.  Maybe just the mono-repo
 > ones though.
 >
 > Also I'm assuming most code is not in packages, and is not in hackage.
 > I have no real basis for that, other than experience with other
 > languages.  But, as shown below, my guesses can be pretty wrong:
 >
 >> Most packages have < 3 occurrences of fromIntegral, a few have < 20
 >> occurrences. Very few have more than 20.
 >>
 >> Assuming we go for a naming improvement and add 3 functions ala
 >> maybeFromInteger / runtimeCheckedFromInteger / fromIntegerWrap, a
 >> package owner would have to step through their deprecation warnings and
 >> replace each with one of the new 3 functions to get their package
 >> warning-free.
 > I'm surprised about that, I assumed more.  Grepping for fromIntegral
 > in a local project, I get 259 occurrences over 693 modules... I
 > expected a lot more.
 >
 > However, a lot of those I think would be false positives, because
 > they're converting across newtypes, where the underlying type is the
 > same.  I'm not sure what I would use for those... I guess it would be
 > fromIntegerWrapped, but it's kind of verbose and awkward and is
 > implying wrapping when it's not actually present.  Maybe they should
 > be using 'coerce'?  Most of them existed before coerce did, but that's
 > not an excuse any more.  I think I'd be more likely to try out
 > int-cast.
 >
 >> I could probably already have fixed 1000 of the 7000 total occurrences
 >> on Hackage myself within the time it as taken me to debug integer
 >> conversion related problems in GHC/base in the last week.
 >>
 >> (In other words, these changes are cheap and have high payoff.)
 > Of course that's the bottom line, so if it's the case then it's hard
 > to argue against.
 >
 > I've had similar bugs due to sloppy haskell -> C FFI conversions so
 > I'm sympathetic to the idea.  It's just a blanket deprecation on
 > fromIntegral seems like a broad brush.
 > _______________________________________________
 > Libraries mailing list
 > Libraries at haskell.org
 > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries