Comments on current TypeHoles implementation

[Thijs Alkemade]

On 4 okt. 2012, at 23:33, Roman Cheplyaka <roma at 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 sounds. We were hoping to make all holes inside one module 
to be shared and get a unified type, but that turned out to not fit with our 
implementation of holes. Holes are treated as constraints, which apply to 
the type of one function, there's no such thing as a constraint for a whole 
module.

You can also not treat the holes as "fake" top level declarations:

> I guess this is something you can get currently by creating a top-level
> declaration
> 
>  foo = _
> 
> and then using foo in several places.

This example will just result in one hole with type "t". The call locations for 
`foo' have no influence on its type.

If we'd want holes to just be shared within one function, then that is pretty 
easy to do right now. We could turn the definition of a hole in HsExpr into 
`HsHole (Maybe RdrName)' (or whatever String-like type is most 
appropriate), in the renamer, change rnExpr for HsVars to return a hole 
when it can't find it, storing the original name. Then ensure holes with the 
same name interact properly (in canHole), and update the way they are 
printed.

Best regards,
Thijs