Type environment when reporting holes
This is a sequel to #8191 (closed). Consider
{-# LANGUAGE TypeHoles #-}
u1 = 0
u2 = 0
u3 = 0
u4 = 0
u5 = 0
u6 = 0
f :: a -> (a -> b) -> b
f x y = _b
v1 = 0
v2 = 0
v3 = 0
v4 = 0
v5 = 0
v6 = 0
Compile with -fno-max-relevant-binds
and see
Relevant bindings include
v6 :: a0 (bound at THoles.hs:18:1)
v5 :: a1 (bound at THoles.hs:17:1)
v4 :: a2 (bound at THoles.hs:16:1)
v3 :: a3 (bound at THoles.hs:15:1)
v2 :: a4 (bound at THoles.hs:14:1)
v1 :: a5 (bound at THoles.hs:13:1)
f :: a -> (a -> b) -> b (bound at THoles.hs:11:1)
x :: a (bound at THoles.hs:11:3)
y :: a -> b (bound at THoles.hs:11:5)
The list is inverted: v6
is first, while it was last. If we do not use -fno-max-relevant-binds
then local parameters x
and y
are not visible at all, but they are the most important data.
Another aspect is that we see v1, v2
but not u1, u2
. I'm not sure what is a good solution here. Display everything? Only N bindings above f
and N bindings below f
? People usually write code top to bottom, so preceding bindings should be more useful in general than following ones.
I think this case deserves some attention because it will often occur in practice (putting a hole in any large file).
Trac metadata
Trac field | Value |
---|---|
Version | 7.7 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler (Type checker) |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |