TypeHoles: errors, warnings, and deferring
2012-10-05 12:55:27 GMT
(I'm starting a new thread to focus on just this issue.)
(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).
- A hole report is a warning.
- Any type error "caused" by a hole is also a warning.
- All other type errors are treated normally (e.g. errors are not deferred unless -fdefer-type-errors is used, insoluble errors suppress unsolved, and errors suppress warnings).
- Convenience: You don't need -fdefer-type-errors when working with holes. One of our goals was to allow you to focus on the holes while trusting the program to be well-typed. Consequently, you use -fdefer-type-errors only if you want *all* errors to be deferred.
- Information: You get more information by including the type errors caused by the hole. For example, the type of the hole in `show _` (e.g. `a0'), is not that useful on its own, but the additional warning of the missing instance (`Show a0`) is quite useful. If you were to suppress this warning, we would be missing crucial evidence for what you could use to fill the hole.
- Surprise: If you replace a hole with `undefined' in the current implementation, you would be surprised by suddenly seeing new errors that you might not expect. If all of those errors were instead treated as warnings with the hole present, you would know what to expect.
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users <at> haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users