On Wed, Oct 3, 2012 at 11:44 AM, Sean Leather
<leather@cs.uu.nl> wrote:
Hi Simon,
Thanks for all your work in getting TypeHoles into HEAD. We really appreciate it.
I was playing around with HEAD today and wanted to share a few observations.
(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.
But with
> f = show undefined
there is a type error because a0 is ambiguous.
We were thinking that it would be better to report the ambiguous type variable first, rather than the hole. In that case, tou can use -fdefer-type-errors to defer the error. Currently, you don't have that option. I can see the argument either way, however, and I'm not sure which is better.
At least in the first case I would actually prefer it not to complain about the ambiguity. The point of putting the hole in is to figure out the type that something going into that location should have and what information I have available to use to plug that hole.
An 'undefined' _is_ ambiguous, but _ is a placeholder for code that presumably will be valid when it gets expanded.
If I have to put a type annotation on it to avoid the compiler dumping out with an error about an ambiguous hole that would seem to me at least to largely defeat the very utility of holes. I would further suspect there are places where you'll be putting holes that have higher rank types, and where undefined might complain.
I largely agree with but don't really have a deep opinion on the other issues you raised, though.
-Edward