Comments on current TypeHoles implementation
thijsalkemade at gmail.com
Fri Oct 5 00:13:35 CEST 2012
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
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
> 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
More information about the Glasgow-haskell-users