#13775: Type family expansion is too lazy, allows accepting of ill-typed terms -------------------------------------+------------------------------------- Reporter: fizruk | Owner: diatchki Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sorry -- I didn't mean to sound snarky!
A different design choice is to refuse to solve such constraints until GHC is sure that the type functions involved will produce a valid result
I think you are suggesting that * Don't do any work on a constraint that mentions `TypeError`. E.g. `C [TypeError ..]` would never be solved, regardless of the instances for `C`. That sounds attractive, but it's fragile. Suppose we had `[W] C [alpha]` where `alpha` is a unification variable. Can we use an instance declaration on that? Well, no; it might turn out that, after hundreds more simplification steps on other constraints mentioning `alpha`, that `alpha := TypeError...`. Or it might be `[W] C (F alpha)`, where eventually `alpha := Int`, and then we reduce `F Int` to `TypeError...`. So I don't see how to make this approach robustly implementable. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13775#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler