You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in-- Perhaps we need to compare the kinds up to holes also?
(TForall() n k hs, TForall() m l ht)
holepunch s t = (s, t)
Now consider the definition
foo : ∀a:* . ?
foo = ? : ∀b:* . ?
which is creatable by
in type, insert a forall which automatically writes * for the kind
in term, create an annotation and then a forall
What should happen if we change the kind of b to a hole?
Currently this creates a term which is not type-correct, so smartholes kicks in and gives
foo : ∀a:* . ?
foo = {? ? : ∀b:? . ? ?}
but perhaps it would be more intuitive and more consistent to consider these two annotations consistent, giving
foo : ∀a:* . ?
foo = ? : ∀b:? . ?
Note that one level down we have that the following is type-correct (with no non-empty holes!)
bar : Int -> ?
bar = ? : ? -> ?
Whilst I think that this would be straightforward to implement, and it seems like it would be a good idea, I have not thought about it enough to convince myself that there are no lurking pitfalls.
The text was updated successfully, but these errors were encountered:
I'd say it's not obvious where the mismatch stems from, so this sounds like something we should do (unless of course we get rid of KHole completely - discussed as unlikely recently in #1095 (comment), but I note that #108 is still open).
For reference in the sequel, consider the following two snippets:
Firstly, how we typecheck an embedding of a synthesisable term in a checkable position
primer/primer/src/Primer/Typecheck.hs
Lines 794 to 799 in 1ab647e
(ignore the fact that smartholes may transform
e
intoe'
for our current purposes)The definition of
t ~ t'
primer/primer/src/Primer/Typecheck.hs
Lines 956 to 980 in 1ab647e
Now consider the definition
which is creatable by
*
for the kindWhat should happen if we change the kind of
b
to a hole?Currently this creates a term which is not type-correct, so smartholes kicks in and gives
but perhaps it would be more intuitive and more consistent to consider these two annotations consistent, giving
Note that one level down we have that the following is type-correct (with no non-empty holes!)
Whilst I think that this would be straightforward to implement, and it seems like it would be a good idea, I have not thought about it enough to convince myself that there are no lurking pitfalls.
The text was updated successfully, but these errors were encountered: