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:johan.tibell@gmail.com] Sent: 07 January 2015 15:27 To: Simon Peyton Jones Cc: ghc-devs@haskell.org; Bill Mitchell (Bill.Mitchell@hq.bcs.org.uk); 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 mailto:simonpj@microsoft.com> 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 ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

| Btw, there are a couple of other warnings, I have been wishing to have | a way to disable them on a per-entity basis... any chance for for a | general syntax to suppress warnings on a more granular level than per- | module? I think that would be a fine idea. But we'd need some kind of concrete syntax. And it ought to work for types and classes as well as functions...

Ha ha ha. Very good, yes! | -----Original Message----- | From: Michael Sloan [mailto:mgsloan@gmail.com] | Sent: 08 January 2015 00:06 | To: Johan Tibell | Cc: Simon Peyton Jones; Milan Straka; Bill Mitchell | (Bill.Mitchell@hq.bcs.org.uk); Ross Paterson; ghc-devs@haskell.org | Subject: Re: Redundant constraints | | One option for avoiding the warning without runtime overhead would be | to do something like this: | | f :: Ord a => a -> a -> Bool | f x y = True | where | _ = x < y | | | On Wed, Jan 7, 2015 at 7:27 AM, Johan Tibell | wrote: | > 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 | > | > 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 | >> ghc-devs@haskell.org | >> http://www.haskell.org/mailman/listinfo/ghc-devs | >> | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs@haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | >

| I've fixed some of the warnings in transformers, but there are still | 14 of them, triggered by Applicative becoming a superclass of Monad. In GHC's own source code I did this #if __GLASGOW_HASKELL__ < 710 -- Pre-AMP change runGhcT :: (ExceptionMonad m, Functor m) => #else runGhcT :: (ExceptionMonad m) => #endif | I think some of the changes already made are of this sort, exposing | details of the GHC implementation, e.g. the changes to the public | interface of Array and Ratio. For example, it's probably reasonable | to remove the Ix constraint from Data.Array.bounds, but the portable | reference implementation of Data.Array.elems requires Ix, even though | the GHC implementation doesn't. Similarly a portable implementation | of the Functor instance for Array i requires Ix, but the GHC | implementation doesn't. Fair enough. If the Core Libraries Committee wants to add some of these constraints back in, that's fine with me. They just need a comment to explain. (We have a trick, now in the user manual, for how to add a redundant constraint without triggering a complaint.) Simon

I was wrong about binary, sorry. It was just the other three Simon From: Lennart Kolmodin [mailto:kolmodin@gmail.com] Sent: 08 January 2015 20:26 To: Simon Peyton Jones Cc: ghc-devs@haskell.org; Milan Straka; Bill Mitchell (Bill.Mitchell@hq.bcs.org.uk); Judah Jacobson; Ross Paterson Subject: Re: Redundant constraints 2015-01-07 18:19 GMT+03:00 Simon Peyton Jones mailto:simonpj@microsoft.com>: 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 I'd like to update binary to not have any unnecessary constraints. I couldn't find any though. commit c409b6f30373535b6eed92e55d4695688d32be9e removes unnecessary constraints from ghc maintained libraries, and silences the redundant-constraints warnings from the other libraries containers, haskeline and transformers. I couldn't find anything related to binary though, nor any warnings in the build log. If there are any, please let me know, or file a bug at http://github.com/kolmodin/binary Thanks! Lennart Enjoy! Simon