2006 Scheme and Functional Programming Papers, University of

component types and checking that they both have type *.
The rule [C-Let] compiles the term let x = v : S in t by recursively
compiling v, S and t in appropriate environments.
The rules for function application are more interesting.
The rule [C-App1] compiles an application t 1 t 2 by compiling
the function t 1 to some term t ′ 1 of some type U. The type
U may be a function type embedded inside refinements. In
order to extract the actual type of the parameter to the
function, we use unrefine to remove any outer refinements
of U before checking the type of the argument t 2 against the
expected type. Formally, unrefine is defined as follows:
unrefine : Term → Term
unrefine(x:S → T ) = x:S → T
unrefine(Refine T f) = unrefine(T )
unrefine(S) = unrefine(S ′ ) if S −→ S ′
The last clause permits S to be simplified via evaluation
while removing outer refinements. Given the expressiveness
of the type system, this evaluation may not converge within
a given time bound. Hence, to ensure that our compiler
accepts all (arbitrarily complicated) well-typed programs,
the rule [C-App2] provides a backup compilation strategy for
applications that requires less static analysis, but performs
more dynamic checking. This rule checks that the function
expression has the most general function type Dynamic →
Dynamic, and correspondingly coerces t 2 to type Dynamic,
resulting in an application with type Dynamic.
The rules defining the compilation and checking judgment
E ⊢ s ↩→ t ↓ T
illustrate the key ideas of hybrid type checking. The rules
[CC-Ok] and [CC-Chk] compile the given term and check
that the compiled term has the expected type T via the
algorithmic subtyping judgment
E ⊢ a alg S