...) which are values of basic types (we use $\basic{c}$ to denote the

basic type of the constant $c$); $x$ ranges over variables; $(e,e)$

...

...

@@ -168,7 +168,7 @@ The first one is that, as explained in

Section~\ref{sec:challenges}, our type assumptions are about

expressions. Therefore, in our rules the type environments, ranged over

by $\Gamma$, map \emph{expressions}---rather than just variables---into

types. This explains why the classic typing rule for variables is replaced by a more general \Rule{Env} rule defined below:\beppe{Changed the name of Occ into Env since it seems more appropriate}

types. This explains why the classic typing rule for variables is replaced by a more general \Rule{Env} rule defined below:

can be deduced by TypeScript and Flow only if they are instructed to do so: the

can be deduced by these languages only if they are instructed to do so: the

programmer has to explicitly annotate \code{foo} with the

type \eqref{tyinter}: we did it in \eqref{foo2} using Flow---the TypeScript annotation for it is much hevier. But this seems like overkill, since a simple

type \eqref{tyinter}: we did it in \eqref{foo2} using Flow---the TypeScript annotation for it is much hevier. But this seems like overkill, since a simple

analysis of the body of \code{foo} in \eqref{foo} shows that its execution may have

two possible behaviors according to whether the parameter \code{x} has

type \code{number} or not (i.e., \code{(number$\vee$string)$\setminus$number}, that is \code{string}), and this is

type \code{number} or not (i.e., or \code{(number$\vee$string)$\setminus$number}, that is \code{string}), and this is

should be enough for the system to deduce the type \eqref{tyinter}

even in the absence the annotation given in \eqref{foo2}.

...

...

@@ -48,14 +48,16 @@ function.

We start by considering the system where $\lambda$-abstractions are

typed by a single arrow and later generalize it to the case of

intersections of arrows. First, we define the auxiliary judgement

\begin{displaymath}

\Gamma\vdash e\triangleright\psi

\end{displaymath}

%\begin{displaymath}

\(

\Gamma\vdash e\triangleright\psi

\)

%\end{displaymath}

where $\Gamma$ is a typing environement, $e$ an expression and $\psi$

a mapping from variables to sets of types. Intuitively $\psi(x)$is

the set of all the types of all the occurrences of $x$ in $e$. This

a mapping from variables to sets of types. Intuitively $\psi(x)$denotes

the set that contains the types of all the occurrences of $x$ in $e$. This

judgement can be deduced by the following deduction system

that collects type information on the variablelambdaabstracted

that collects type information on the variables that are $\lambda$-abstracted

(i.e., those in the domain of $\Gamma$, since lambdas are our only

binders):

\begin{mathpar}

...

...

@@ -131,7 +133,7 @@ following rule

Note the invariant that the domain of

$\psi$ is always equal to the

domain of $\Gamma$ restricted to variables.

Simply put, this rule first collect all possible types that are deduced

Simply put, this rule first collects all possible types that are deduced

for a variable $x$ during typing and then uses them to re-type the body

of the lambda under this new refined hypothesis for the type of

$x$. The re-typing ensures that that the type soundness property

...

...

@@ -174,16 +176,16 @@ function.

we could do the same (by collecting type scheme) in $\psi$ but we

then need to choose a candidate in the type scheme \ldots}

In a nutshell, what we have done is that when we have to type a

In a nutshell, what we have done is that in order to type a

function we use the type-cases on its parameter to partition the

domain of the function and test it on the single partitions rather

than on the union thereof. Of course we could use a much finer

domain of the function and we type-check the function on the single partitions rather

than on the union thereof. Of course, we could use much a finer

partition: the finest (but impossible) one is to check the function

against the singleton types of all its input. But a finer partition

would not probably return much better information since most

partitions would collapse on the same return type: typecase on the

parameter are those that may do a difference, returning different

types for different partitions thus yield more precise typing.

against the singleton types of all its inputs. But any finer partition

would not in general return much better information, since most

partitions would collapse on the same return type: type-cases on the

parameter are the tipping points that are likely make a difference, by returning different

types for different partitions thus yielding more precise typing.