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
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
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 —
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
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
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
