[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:                    |
-------------------------------------+-------------------------------------
Description changed by nomeata:

@@ -19,0 +19,4 @@
+
+ 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.

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 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.

 (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.

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12864#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler