I've been bitten by this too and had to disable the warning.
Let me propose an alternative;
* -Wredundant-constraints becomes only your Warning 1. That is, it reports when
a user writes a constraint that is fully equivalent to some other, strictly
smaller constraint, like suggesting simplifying (Eq a, Ord a) to (Ord a).
* -Wtype-overly-specific takes on Warning 2, and adds the ability to catch any
type signature that's more specific than it needs to be. (Whether or not to add
this to -Wall is for others to decide.) This is indeed a more lint-like
warning, but HLint would be hard-pressed to figure this one out.
* We really need a way of disabling/enabling warnings per declaration. I
propose something like this:
> {-# WARNINGS foo -Wno-type-overly-specific #-}
> foo :: Int -> Int
> foo x = x
Richard
On Jun 4, 2016, at 9:11 AM, Carter Schonwald <carter.schonw...@gmail.com> wrote:
> 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 <acfolt...@gmail.com> 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
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
