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

 Replying to [comment:4 simonpj]:
 > Replying to [comment:3 xnyhps]:
 >
 > > Hmm. My intent was to allow typechecking to continue when there are
 holes (so compiling them, similar to {{{undefined}}}, to something like
 {{{throw#}}}). If I understand your suggestion correctly, we should abort
 compilation and show the hole's type as errors when an unresolved hole is
 found.
 >
 > No, not at all.  Your new stuff will integrate beautifully with
 `-fdefer-type-errors`.  With this flag, `TcErrors` will build an error
 thunk for any unsolved constraints, thereby deferring the error until
 runtime just as you wanted.  So you can use the holes as to-dos.  Look at
 `TcErrors.reportTidyWanteds`, and note the call to `deferToRuntime`.
 >
 > If you want to defer only '''holes''', but not other type errors, until
 runtime, you’d need another flag, but I think as a first cut deferring
 '''all''' type errors (including holes) would do.  Or alternatively you
 could by-default defer holes but not other errors.  But then you’d still
 want a flag to say “don’t defer holes”.
 >
 > I strongly urge you to use the `TcErrors` stuff.  It does precisely what
 you want.  If you don’t see how, ask more.


 Thanks for the advice, I've been working on implementing this, and it is
 indeed a good way to report handle the compilation of holes. Instead of
 using `-fdefer-type-errors`, I've changed it so that holes are always
 deferred (maybe it's just me, but using ghci with `-fdefer-type-errors` on
 got annoying quite quickly, like having to `print` everything because
 otherwise it has a warning that the result is not in `IO`).

 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?

 Btw, I'm attaching an updated patch against a more recent version of HEAD.
 Some things were changed in the constraint solver that have been updated,
 the deferring to runtime works, and I changed the syntax to `_?a` for a
 hole named "a", `_a` was giving too many collisions with FFI generated
 code. It should now be possible to build stage1, stage2 and all libraries
 with it.

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