On Thu, Sep 21, 2017 at 4:19 PM, Niklas Hambüchen 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

On 21/09/17 19:27, Evan Laforge wrote: 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

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: 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries