Comments on current TypeHoles implementation

[Edward Kmett]

On Wed, Oct 3, 2012 at 11:44 AM, Sean Leather <leather at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20121003/e1293640/attachment.htm>