RE: Comments on current TypeHoles implementation

2012-10-04 Thread Simon Peyton-Jones
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

Re: Comments on current TypeHoles implementation

2012-10-04 Thread Edward Kmett
I really like this proposal. -Edward On Thu, Oct 4, 2012 at 5:40 AM, Simon Peyton-Jones simo...@microsoft.comwrote: There is also the small matter, in this example, of distinguishing which `_' is which. The description works, but you have to think about it. I don't have an immediate and

Re: Comments on current TypeHoles implementation

2012-10-04 Thread Nicolas Frisby
tl;wr Variables and holes should have disparate syntax, so that code is easy to locally parse. Simon, your proposal is very crisp from the GHC implementor's perspective, but I think it might be harmful from the user's perspective. My premise is that free variables — which are normally fatal —

Re: Comments on current TypeHoles implementation

2012-10-04 Thread Roman Cheplyaka
I don't see why it is an issue. You should never encounter holes in the released code. The only source of holes should be stuff that you just wrote. With this proposal not only you get an error for the unbound variable (as you'd get before), but GHC even tells you the type of a thing that you

Re: Comments on current TypeHoles implementation

2012-10-04 Thread Thijs Alkemade
On 4 okt. 2012, at 23:33, Roman Cheplyaka r...@ro-che.info wrote: Sounds cool. I would also expect that if you have several occurences of the same unbound identifier, then it gets a unified type. We have actually tried to do it this way for a pretty long time. But it's not as easy as it

Re: Comments on current TypeHoles implementation

2012-10-04 Thread Nicolas Frisby
On Thu, Oct 4, 2012 at 4:28 PM, Roman Cheplyaka r...@ro-che.info wrote: I don't see why it is an issue. You should never encounter holes in the released code. The only source of holes should be stuff that you just wrote. With this proposal not only you get an error for the unbound variable (as