[GHC] #12864: Produce type errors after looking at whole applications

[GHC]

#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