On 4 okt. 2012, at 23:33, Roman Cheplyaka
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