<p dir="ltr">I strongly agree with per-declaration warning suppression. But I'd like to leave both warnings on by default in -Wall.</p>
<p dir="ltr">1. Sometimes an upstream library will drop a constraint. The warning lets me know I can drop it too.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<div class="gmail_quote">On Jun 6, 2016 9:40 AM, "Richard Eisenberg" <<a href="mailto:eir@cis.upenn.edu">eir@cis.upenn.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I've been bitten by this too and had to disable the warning.</div><div><br></div><div>Let me propose an alternative;</div><div>* -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).</div><div><br></div><div>* -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.</div><div><br></div><div>* We really need a way of disabling/enabling warnings per declaration. I propose something like this:</div><div><br></div><div>> {-# WARNINGS foo -Wno-type-overly-specific #-}</div><div>> foo :: Int -> Int</div><div>> foo x = x</div><div><br></div><div>Richard</div><div><br></div><div><div>On Jun 4, 2016, at 9:11 AM, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:</div><br><blockquote type="cite">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. <span></span><br><br>On Friday, June 3, 2016, Adam Foltzer <<a href="mailto:acfoltzer@gmail.com" target="_blank">acfoltzer@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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:<div><br></div><div>Warning 1: a warning for constraints made redundant by superclass relationships, and</div><div>Warning 2: a warning for unused constraints<div><br></div><div>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.</div></div></div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>[1]: <a href="https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15</a></div></div>
</blockquote>
_______________________________________________<br>Glasgow-haskell-users mailing list<br><a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank">Glasgow-haskell-users@haskell.org</a><br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br></blockquote></div><br></div><br>_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br>
<br></blockquote></div>