#11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Perhaps the user guide is deficient with regard to implicit parameter shadowing. Maybe it's not even reliable -- I'm not sure. As for your first paragraph, I'm not convinced yet: `Int` is not like any other constraint, in that it's not a class. In GHC 8.0, we have a few forms of constraint: 1. Fully-applied classes 2. Implicit parameters 3. Tuples (which is actually special syntax for (1)) 4. Equality constraints 5. Other built-in constraints (`Coercible`, `Typeable`, are there more?) 6. Type families and synonyms which produce constraints You are advocating for something new: 7. Other Haskell types We thus can choose how to handle case (7) independently of how we handle other constraints, just like (2) has different "shadowing" behavior than (1). So `Int` will always be different from `Given Int`, and I think that's OK. As long as implicit parameters are around, then we've already lost the thinness of constraints. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11715#comment:43 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler