Feedback on -Wredundant-constraints

[Carter Schonwald]

Strong emphatic agreement. Both that it should split up thusly and that the
latter shouldn't be in WALL. Otherwise it poisons the well for all be the
most sophisticated users of type level programming.

I don't suppose there's any hope of having this resolved prior to GHC 8.2
because it is a real usability regression? Because I think we can all agree
that the proposed change would not break any 8.0 series code, and
positively impact everyone.
On Jun 6, 2016 9:40 AM, "Richard Eisenberg" <eir at 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.schonwald at 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 <acfoltzer at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160606/29f89d2b/attachment.html>