I had one thought though: consider an abstract data type with functions that operates over it. I might want to require e.g Ord in the definition of a function so I have freedom to change my implementation later, even though the current implementation doesn't need Ord. Think of it as separating specification and implementation. An example is 'nub'. I initially might implement it as a O(n^2) algorithm using only Eq, but I might want to leave the door open to using Ord to create something better, without later having to break backwards compatibility.
Yes, a per-function way to suppress the warning might be useful. But I have not implemented that. At the moment it’s just per-module. Simon From: Johan Tibell [mailto:[email protected]] Sent: 07 January 2015 15:27 To: Simon Peyton Jones Cc: [email protected]; Bill Mitchell ([email protected]); Milan Straka; Ross Paterson Subject: Re: Redundant constraints I think this probably makes sense, especially since you can silence the warning when you intend to add an unnecessary constraint. I had one thought though: consider an abstract data type with functions that operates over it. I might want to require e.g Ord in the definition of a function so I have freedom to change my implementation later, even though the current implementation doesn't need Ord. Think of it as separating specification and implementation. An example is 'nub'. I initially might implement it as a O(n^2) algorithm using only Eq, but I might want to leave the door open to using Ord to create something better, without later having to break backwards compatibility. On Wed, Jan 7, 2015 at 4:19 PM, Simon Peyton Jones <[email protected]<mailto:[email protected]>> wrote: Friends I’ve pushed a big patch that adds –fwarn-redundant-constraints (on by default). It tells you when a constraint in a signature is unnecessary, e.g. f :: Ord a => a -> a -> Bool f x y = True I think I have done all the necessary library updates etc, so everything should build fine. Four libraries which we don’t maintain have such warnings (MANY of them in transformers) so I’m ccing the maintainers: o containers o haskeline o transformers o binary Enjoy! Simon _______________________________________________ ghc-devs mailing list [email protected]<mailto:[email protected]> http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
