[GHC] #5910: Holes with other constraints

[GHC]

#5910: Holes with other constraints
----------------------------------------+-----------------------------------
    Reporter:  xnyhps                   |       Owner:                                   
        Type:  feature request          |      Status:  new                              
    Priority:  normal                   |   Milestone:                                   
   Component:  Compiler (Type checker)  |     Version:  7.5                              
    Keywords:  holes                    |          Os:  Unknown/Multiple                 
Architecture:  Unknown/Multiple         |     Failure:  Incorrect warning at compile-time
  Difficulty:  Unknown                  |    Testcase:                                   
   Blockedby:                           |    Blocking:                                   
     Related:                           |  
----------------------------------------+-----------------------------------

Comment(by xnyhps):

 Sorry for the delay.

 Replying to [comment:6 simonpj]:
 > Replying to [comment:5 xnyhps]:
 > >
 > > However, there's a one problem with this approach. The code that
 handles prioritization of errors and the code that handles deferring type
 erros to runtime, as far as I can tell, do different things to handle
 multiple errors: when `-fdefer-type-errors` is on, '''every''' error is
 reported and no prioritization is done. This also means that when just
 holes are deferred, the class ambiguity errors I initially had still
 happen. Do you have a suggestion on how to avoid this, other than always
 deferring all type errors?
 >
 > Can you give me a concrete example, showing the behaviour you get, and
 the behaviour you want?
 >
 > Do you have a separate flag to enable holes? I assume so.

 This is still the example I'm working with:

 {{{
 test = show _?a
 }}}

 '''With''' `-fdefer-type-errors`, I see:

 {{{
 [1 of 1] Compiling Main             ( test.hs, interpreted )

 test.hs:1:8: Warning:
     No instance for (Show a0) arising from a use of `show'
     The type variable `a0' is ambiguous
     Possible fix: add a type signature that fixes these type variable(s)
     Note: there are several potential instances:
       instance Show Double -- Defined in `GHC.Float'
       instance Show Float -- Defined in `GHC.Float'
       instance Show () -- Defined in `GHC.Show'
       ...plus 24 others
     In the expression: show (_?a)
     In an equation for `test': test = show (_?a)

 test.hs:1:13: Warning:
     Found hole _?a with type a0
     In the first argument of `show', namely `_?a'
     In the expression: show (_?a)
     In an equation for `test': test = show (_?a)
 Ok, modules loaded: Main.
 }}}

 Makes sense. There's a hole, and a `show` for which it can not figure out
 what instance to use. Trying to run it will throw an exception with the
 first error. That's all good.

 '''Without''' `-fdefer-type-errors` (but holes still get deferred):

 {{{
 [1 of 1] Compiling Main             ( test.hs, interpreted )

 test.hs:1:8:
     No instance for (Show a0) arising from a use of `show'
     The type variable `a0' is ambiguous
     Possible fix: add a type signature that fixes these type variable(s)
     Note: there are several potential instances:
       instance Show Double -- Defined in `GHC.Float'
       instance Show Float -- Defined in `GHC.Float'
       instance Show () -- Defined in `GHC.Show'
       ...plus 24 others
     In the expression: show (_?a)
     In an equation for `test': test = show (_?a)
 Failed, modules loaded: none.
 }}}

 So the hole gets deferred, but all other type errors still exist and the
 prioritization of errors therefore does not remove this one. Somehow
 prioritizing first, and then deferring would also not be ideal, as then
 unrelated type errors in completely different could become hidden.

 There is currently no flag yet to enable them, they're always on, but I do
 plan to add one. However, I'm hoping my changes to the core are
 noninvasive enough when not using holes that it would suffice to only use
 the flag to turn off the parsing of holes.

 Replying to [comment:7 simonpj]:
 > Would you like to try that simplification?  That is, do NOT take
 implicit parameters as your guide!

 I'm going to look into this, thanks!

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