I strongly agree with per-declaration warning suppression. But I'd like to
leave both warnings on by default in -Wall.
1. Sometimes an upstream library will drop a constraint. The warning lets
me know I can drop it too.
2. Sometimes an implementation evolves from a draft that requires a
constraint to a final form that does not; it's easy to forget to check
whether any constraints have become redundant.
It's true that this is somewhat analogous to a function that is less
polymorphic than it can be. But my answer to that is the opposite: I'd be
very happy to be warned when I write a top-level function with a specific
type when it could be parametrically polymorphic in that type.
On Jun 6, 2016 9:40 AM, "Richard Eisenberg" <e...@cis.upenn.edu> wrote:
> 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
>
>
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
