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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
