Comments on current TypeHoles implementation
Roman Cheplyaka
roma at ro-che.info
Fri Oct 5 09:24:44 CEST 2012
* Roman Cheplyaka <roma at ro-che.info> [2012-10-05 10:22:23+0300]
> * Simon Peyton-Jones <simonpj at microsoft.com> [2012-10-05 07:14:36+0000]
> > | Sounds cool. I would also expect that if you have several occurences of
> > | the same unbound identifier, then it gets a unified type.
> >
> > I thought about this, but I think not. Consider
> >
> > f x1 = _y
> > g x2 = _y
> >
> > Do you want _y and _y to be unified, so that f and g are no longer polymorphic? I think not. Any more than the "_" holes we have now are unified.
>
> Do you mean polymorphism in their argument? Why would it go away?
>
> I would expect the functions to get types `a -> c` and `b -> c`
> respectively, and `c` to be reported as the type of the hole.
Ah, I see. Since `c` is universally quantified, it means different
things for f and g. Good point.
Roman
More information about the Glasgow-haskell-users
mailing list