Agreed. Ive hit exactly these issues myself to the point where i err on suppressing that warning in my code now. In part because i use those unused constraints as a semantic contract.
On Friday, June 3, 2016, Adam Foltzer <[email protected]> wrote: > With 8.0.1 freshly arrived, I'm taking on the task of updating a number of > our larger projects here at Galois. I made a couple of these comments > briefly on a relevant Trac ticket[1], but I wanted to open this discussion > to a wider audience. > > We tend to use -Wall (and -Werror, in CI environments), and so I've had to > make decisions about how to handle the new -Wredundant-constraints > warnings. So far, I've come to think of it as two different warnings that > happen to be combined: > > Warning 1: a warning for constraints made redundant by superclass > relationships, and > Warning 2: a warning for unused constraints > > Overall I'm a fan of Warning 1. It seems very much in the spirit of other > warnings such as unused imports. The only stumbling block is how it affects > the 3-release compatibility plan with respect to, e.g., the AMP. Most of > our code targets a 2-release window, though, so in every such case it has > been fine for us to simply remove the offending constraint. > > Warning 2 on the other hand is far more dubious to me. In the best case, > it finds constraints that through oversight or non-local changes are truly > no longer necessary in the codebase. This is nice, but the much more common > case in our code is that we've made a deliberate decision to include that > constraint as part of our API design. > > The most painful example of this I've hit so far is in an API of related > functions, where we've put the same constraint on each function even when > the implementation of that particular function might not need that > constraint. This is good for consistency and forward-looking compatibility > (what if we need that constraint in the next version?). The warning's > advice in this case makes the API harder to understand, and less abstract > (the client shouldn't care or know that f needs Functor, but g doesn't, if > both will always be used in a Functor context). > > On another level, Warning 2 is a warning that we could have given a more > general type to a definition. We quite rightly don't do this for the > non-constraint parts of the type signatures, so why are we doing it for the > constraints? > > I'm happy that Warning 1 is now around, but Warning 2 feels much more like > an opinionated lint check, and I really wish it wasn't part of -Wall. > > [1]: https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15 >
_______________________________________________ Glasgow-haskell-users mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
