#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 diatchki): As for issue 1), I am a bit weary of doing the change, as the current behavior has a fairly simple explanation; the alternative I mentioned would be more of a heuristic, as I don't think we have a specific order of evaluation, and it could make some custom errors not show up, when you'd like them to show. Generally, even though `TypeError` is implemented just as a type function, I really think of it more of a special right-hand side in type function definitions. If you use it in this way, then you don't encounter the problems you found, because the type error is only ever generated when there is no other alternative. So this is how I'd structure your example in this style: {{{ type family Assert (prop :: Bool) (val :: k) (msg :: ErrorMessage) where Assert 'True val msg = val Assert 'False val msg = TypeError msg }}} In fact, we should probably add this type function to `Data.Type.Bool`. With this combinator, you could define `F` simply as: {{{ type F n = Assert (n <=? 8) Int (Text "Input to F should be no greater than 8") }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14771#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler