I guess a better solution, although more complex, would be too look at
#14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): the available equations for T and see if evaluation is "stuck" due to the type error. If so, we report the custom error. Otherwise, we leave the expression as is. That would be good! ---- Regarding the issue 2: say GHC can't solve `F n ~ Word` as in the given example. Currently it reports: {{{ • Couldn't match type ‘If (n <=? 8) Int DUMMY’ with ‘Word’ }}} Sometime in other places in my code (I don't know how to reproduce it in the smaller example) it reports the following, which is better because it mentions `F n`: {{{ • Couldn't match type ‘If (n <=? 8) Int8 DUMMY’ with ‘Word’ Expected type: Word Actual type: F n }}} I'd like `F n` to appear more often instead of having to remember that the complex expression `If (n <=? 8) ...` refers to `F n`. Maybe we could even suggest adding `F n ~ Word` as a constraint for `test2`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14771#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler