
#12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Sorry if I was unclear, Simon. GHC says the constraint `b ~ Foo a` is redundant. To me, this warning means that GHC is suggesting it would be better to write `foo :: (RealFrac a, Integral b) => a -> b`. I disagree with GHC's suggestion: I meant to write the original signature (which is equivalent to the one which requires `FlexibleContexts`), because it is more specific and can help with type inference elsewhere in my program. Moreover, if I wrote the original signature in a different form (the `FlexibleContexts` version), GHC does ''not'' suggest it would be better to write `foo :: (RealFrac a, Integral b) => a -> b`. In that case it notices that the type restriction is meaningful. What I'm getting at here is: if A and B are equivalent (as my two signatures are), then GHC should have the same behavior when I do either one. Maybe it's difficult for GHC to realize that my particular A and B are equivalent, and I suppose that would be a valid reason to close the ticket. As to why I chose to write the signature I did instead of the `FlexibleContexts` version, it can be save some space in type signatures when some type variables are equivalent to long expressions. I don't give a whit about using `FlexibleContexts`, in fact it is enabled almost everywhere in my code already. As to whether putting type equalities in contexts should require `FlexibleContexts`: that misses the point, since I get the same warning with the original signature when the extension is enabled. GHC still behaves differently on equivalent inputs. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12700#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler