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

Comment(by simonpj@…):

 commit 8a9a7a8c42da3adb603f319a74e304af5e1b2128
 {{{
 Author: Simon Peyton Jones <simo...@microsoft.com>
 Date:   Mon Sep 17 13:31:14 2012 +0100

     Add type "holes", enabled by -XTypeHoles, Trac #5910

     This single commit combines a lot of work done by
     Thijs Alkemade <thijsalkem...@gmail.com>, plus a slew
     of subsequent refactoring by Simon PJ.

     The basic idea is
     * Add a new expression form "_", a hole, standing for a not-yet-
 written expression
     * Give a useful error message that
        (a) gives the type of the hole
        (b) gives the types of some enclosing value bindings that
            mention the hole

     Driven by this goal I did a LOT of refactoring in TcErrors, which in
 turn
     allows us to report enclosing value bindings for other errors, not
 just
     holes.  (Thijs rightly did not attempt this!)

     The major data type change is a new form of constraint
       data Ct = ...
                   | CHoleCan {
                       cc_ev       :: CtEvidence,
                       cc_hole_ty  :: TcTauType,
                       cc_depth    :: SubGoalDepth }

     I'm still in two minds about whether this is the best plan. Another
     possibility would be to have a predicate type for holes, somthing like
        class Hole a where
          holeValue :: a

     It works the way it is, but there are some annoying special cases for
     CHoleCan (just grep for "CHoleCan").

  compiler/deSugar/Coverage.lhs      |    1 +
  compiler/deSugar/DsExpr.lhs        |    2 +
  compiler/hsSyn/HsExpr.lhs          |    3 +
  compiler/main/DynFlags.hs          |    4 +-
  compiler/rename/RnExpr.lhs         |   11 +-
  compiler/typecheck/Inst.lhs        |   31 ++--
  compiler/typecheck/TcBinds.lhs     |   90 ++++----
  compiler/typecheck/TcCanonical.lhs |    9 +-
  compiler/typecheck/TcEnv.lhs       |   21 ++-
  compiler/typecheck/TcErrors.lhs    |  443
 ++++++++++++++++++++++--------------
  compiler/typecheck/TcExpr.lhs      |    9 +
  compiler/typecheck/TcHsSyn.lhs     |    3 +
  compiler/typecheck/TcMType.lhs     |   14 +-
  compiler/typecheck/TcRnMonad.lhs   |   35 ++-
  compiler/typecheck/TcRnTypes.lhs   |   96 +++++---
  compiler/typecheck/TcRules.lhs     |   28 ++-
  compiler/typecheck/TcSMonad.lhs    |   36 ++--
  compiler/typecheck/TcSimplify.lhs  |  110 ++++------
  compiler/typecheck/TcUnify.lhs     |    2 -
  compiler/types/Type.lhs            |   18 +-
  20 files changed, 565 insertions(+), 401 deletions(-)
 }}}

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

_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to