[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:                    |
-------------------------------------+-------------------------------------

Comment (by nomeata):

 We briefly talked about this, and it is not obviously easily possible.
 Currently, the type checker will, for example with `ex2 = fid d1 i1`,
 create two insoluble wanted constraints, one at `d1` and one at `i1`,
 which are then reported separately.

 So here is a wild and not-thought through idea: We already have the
 machinery to turn (some) type errors into coercions. So how about this
 scheme:

  * The type checker runs. Type errors that can be “fixed” by coercions are
 fixed this way, and ''not'' reported right now. The others are reported as
 ususal.
  * (New step) We try to detect common, interesting patterns of code and
 error coercions, and possibly move them around. For example:
   {{{
   (i ▷ (DelayedError Int Double), d ▷ (DelayedError Double Int)) ::
 (Double, Int)
   }}}
   would be re-written to
   {{{
   (i, d) ▷ (DelayedError (Int, Double) (Double, Int)) :: (Double, Int)
   }}}
   This pass would only move these coercion wrappers around, otherwise, we
 preserve the AST as entered by the user.
  * Finally, the syntax tree is traversed as well, and all `DelayedError`
 axioms are reported.

 One side-effect of this would be that we could report error messages
 citing the actual source of the context where they appear, in the actual
 syntax of the user (using annotations), which might work better than our
 current context-explanation-generating machinery.

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