-
Hi all! I am trying to understand how F* manages type inference for unifying branches of a case split. In particular, how it manages to avoid variable escape for dependent types. Consider the following:
emacs mode correctly reports |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Hi @gancherj, you are right, there are two subtyping constraints as you have written. When typechecking the For the F* then collects all subtyping constraints for F* then tries a widening heuristic, and solves When There is a third case here that I will just mention If we annotate the return type of |
Beta Was this translation helpful? Give feedback.
Hi @gancherj, you are right, there are two subtyping constraints as you have written.
When typechecking the
match
term here, F* creates a fresh unification variableb |- ?u:Type
for the type of thematch
. The gamma for the unification variable?u
is justb
, i.e. b is the only free variable that may occur in the solution of?u
.For the
then
branch, F* creates a subtyping constrainta:nat{a == x + 1} <: ?u
, and similarlya:nat{a == z + 1} <: ?u
for theelse
branch. Since these are rigid-flex subtyping constraints, F* defers solving them until it has typechecked the whole term, this is so that it can collect other constraints on say?u
; in this case though these are the only two.F* then col…