#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): While I certainly want to remove some of the ugliness around `Constraint`/`Type`, more clouds are appearing on the horizon. Specifically, I think {{{ f :: Int -> ... helper :: Int => ... }}} is problematic. When `f` calls `helper`, there are lots and lots of `Int`s available: the one passed into `f` as well as all of the others. Note that this is not the same with {{{ g :: a -> (a => r) -> r }}} where only one value of type `a` is in scope. (Thanks, parametricity!) Yes, `=>` should merely introduce an implicit argument, but GHC should not guess an implicit value when there is more than one option. This brings us back to Simon's suggestion about singleton types. I conjecture that there is no way to identify all singleton types without user direction. We could have users write a `{-# SINGLETON Either () Void #-}` pragma. But then we haven't come very far, as I don't know a way to check whether a `SINGLETON` pragma is lying or telling the truth. I also want to amplify Issue 2 from comment:31 to make sure that `blah :: Ord a -> a -> Set a` gets a reasonable error message. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11715#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler