# Holes in GHC

Simon Peyton-Jones simonpj at microsoft.com
Tue Aug 21 19:14:07 CEST 2012

Can you give me read/write access to your github repo?  I'm simonpj on github.
It would make things easier if you could merge with HEAD so that I don't have to mess around moving libraries back in time.

------------------------------
You've put "LANGUAGE Holes" in TcErrors which means I can't bootstrap.

------------------------------
You have this in your patch file, which can't be right
+  | CHoleCan {
+      cc_ev       :: CtEvidence,
+      cc_hole_ty  :: TcTauType, -- Not a Xi! See same not as above
+      cc_depth    :: SubGoalDepth        -- See Note [WorkList]
+    }
+
\end{code}

\begin{code}
@@ -933,6 +940,9 @@ ctPred (CTyEqCan { cc_tyvar = tv, cc_rhs = xi })
ctPred (CFunEqCan { cc_fun = fn, cc_tyargs = xis1, cc_rhs = xi2 })
= mkTcEqPred (mkTyConApp fn xis1) xi2
ctPred (CIrredEvCan { cc_ty = xi }) = xi
+ctPred (CHoleCan { cc_flavor = fl, cc_hole_ty = xi })
+  = xi
+

since c_flavor isn't a field of CHoleCan.

-----------------------

| The 3 currently remaining issues:
|
| - Free type variables are not tidied consistently. For every one of
| these hole warnings, the same TidyEnv is reused, without taking the
| updates from the other holes into account. I'm pretty sure I know where
| this happens and how I could fix it.

This should be easy.
* TcErrors.reportUnsolved uses tyVarsOfWC to find the free type variables
of unsolved constraints
* It then uses tidyFreeTyVars to assign them names
* And that gives an env used in tidying.

So it should just work.  I hope you are letting the various 'tidy' calls in TcErrors do the work.

| - What I thought would be the local environment doesn't actually seem
| to be it. The holes store in their origin the result of getLclTypeEnv'
| at their location, but as the Note [Bindings with closed types] says,
| the TopLevelFlag of these don't actually differentiate the top level
| from the non-top level bindings. I think it would be more helpful to
| only show the non-top level bindings at the hole's location, any hints
| about how to obtain just these would be appreciated.

In this context "local" means "this module" rather than "not top level".  Use isExternalName to distinguish top-level things from nested things.

| - The holes do not have very accurate source location information, like
| some other errors have. The hole has its origin, ("test2.hs:3:16"), but
| somehow not something like: "In the expression: folder _ x _, In an
| equation for test': test x = foldr _ x _". Help with how that is
| supposed to work would also be appreciated.

That's odd.  Every Wanted constraint has a WantedLoc (TcRnTypes), which includes a [ErrCtxt], which is that stack of "In ..; In... " stuff you see.

Code looks plausible.