Comments on current TypeHoles implementation

[Simon Peyton-Jones]

Thanks for all your work in getting TypeHoles into HEAD. We really appreciate it.

Great - maybe you can develop it further.


(2) There is a strange case where an error is not reported for a missing type class instance, even though there is no (apparent) relation between the missing instance and the hole. (This also relates to the connection to `undefined', but less directly.)

Yes; GHC classifies type errors into two groups:

*         insoluble (eg Int~Bool) are definitely wrong

*         unsolved (eg Eq a) might be ok if (say) the context changed
If there are any insolubles (anywhere), error messages about unsolved constraints are suppressed.  This is usually good; it focuses your attention on definite errors first.  Let's call the suppressed errors "suppressed erorrs".

Now, holes are classified as "insoluble" at the moment, and that's why all other unsolved errors are suppressed.


At the moment, if you way -XTypeHoles you get only a warning even though it's really an error.  Moreover it's weird that the warning suppresses other error messages.

So I propose to change it so that -XTypeHoles gives an error message (for holes); and you can use -fdefer-type-errors to defer it.

In doing this I also realised that with -fdefer-type-errors you only get warnings for the things that would previously have been errors; you don't get warnings for "supressed errors".  And that's arguably bad, since you don't know about all the errors you are deferring to runtime.  So I've changed it so that with -fdefer-type-errors you get *all* errors as warnings (no supression).

(1) One of the ideas we had was that a hole `_' would be like `undefined' but with information about the type and bindings. But in the current version, there doesn't appear to be that connection. This mainly applies to ambiguous type variables.

Consider:
> f = show _
The hole has type a0.

You get this, which seems reasonable, no?  (I've changed the wording slightly.)

Foo.hs:5:12:
    Found hole `_' with type a0
    Where: `a0' is an ambiguous type variable
    In the first argument of `show', namely `_'
    In the expression: show _
    In an equation for `f': f x = show _

(3) In GHCi, I see that the type of the hole now defaults. This is not necessarily bad, though it's maybe not as useful as it could be.

Yes... if there are insolubles around then doing defaulting isn't going to help, and might confuse matters.  I'll change that.

(5) There are some places where unnecessary parentheses are used when pretty-printing the code:

That's easily fixed thanks.

I'll think about GHCi separately.

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20121004/84f37237/attachment-0001.htm>