#12864: Produce type errors after looking at whole applications -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -6,6 +6,6 @@ - In many cases the error messages would be better if it would at one - application if a function at once, and, in general, present the user with - the (inferred) type of the function as well as the (expected) type due to - the argument. This way, only one type error will be reported per function - application, and comparing these two reported types will allow the user to - spot the problem more easily. + In many cases a procedure like the following would be better: For a given + application `f a1 a2 a3`, present the user with the (inferred) type of + `f`, as well as the (expected) type `f` needs to have to be used with + arguments `a1 a2 a3`. This way, only one type error will be reported per + function application, instead of many, and comparing these two reported + types will allow the user to spot the problem more easily. New description: Currently, the type error messages we produce in case of function applications are rather dumb, in particular if arguments were ommited, added, swapped or not parenthized correctly. (Examples in the first comment below.) In many cases a procedure like the following would be better: For a given application `f a1 a2 a3`, present the user with the (inferred) type of `f`, as well as the (expected) type `f` needs to have to be used with arguments `a1 a2 a3`. This way, only one type error will be reported per function application, instead of many, and comparing these two reported types will allow the user to spot the problem more easily. (With „one application“ I mean `e1 e2 e3 … en` where `e1` is not of that form.) Furthermore, once we have these two types in our hands, we can look for common patterns, and give even more helpful error messages, such as suggesting to swap two arguments. Clearly, there are many tricky corner cases (e.g. polymorphic functions, types with constraints or type classes, type applications etc.). But that should not stop us from trying better in obvious, monomorphic cases. -- Comment (by nomeata): Reformulated it a bit. I stared a bit at the code, but it is not obvious how to do it: Type information moves from the function towards the arguments and then down, and eventually hits something that does not match. I don’t know enough about the type checker to see if this can sensibly be refactored, and what would be the cost (e.g. performance?) Maybe I’ll try to corner Richard someday and talk this over with him. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12864#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler