We consider \True, \Any and $\lnot\True$ as candidate types for
\texttt{x} which, in turn allows us to deduce a precise type given in the table. Finally, thanks to this rule it is no longer necessary to force refinement by using a type case. As a consequence we can define the functions \texttt{and\_} and \texttt{xor\_} more naturally as:
\texttt{x} which, in turn allows us to deduce a precise type given in the table. Finally, thanks to this rule it is no longer necessary to use a type case to force refinement. As a consequence we can define the functions \texttt{and\_} and \texttt{xor\_} more naturally as:
\begin{alltt}\color{darkblue}\morecompact
let and_ = fun (x : Any) -> fun (y : Any) -> not_ (or_ (not_ x) (not_ y))
let xor_ = fun (x : Any) -> fun (y : Any) -> and_ (or_ x y) (not_ (and_ x y))
@@ -41,3 +41,4 @@ pair. It is therefore unclear whether their systems allows one to
write predicates over list types (e.g., test whether the input
is a list of integers), which we can easily do thanks to our support
for recursive types.\beppe{On peut dire plus? More generally, while their system refines only the type of variables, and only when they occur in some chosen contexts, our approach lifts this limitation on contexts and also refines the types of arbitrary expressions.}
\beppe{Est-ce vrai que: As far as we know, a code analysis such as the one performed by Code 8 for DOM objects is out of reach of the current occurrence typing state of the art.}