@@ -152,7 +152,9 @@ and $e''$ as long as they are applications, and deduce distinct types for all su

form applications. How to do it precisely is explained in the rest of

the paper but the key ideas are pretty simple and are explained next.

\subsection{Key ideas} First of all, in a strict language we can consider a type as denoting the set of values of that type and subtyping as set-containment of the denoted values.

\subsection{Key ideas}\label{sec:ideas}

First of all, in a strict language we can consider a type as denoting the set of values of that type and subtyping as set-containment of the denoted values.

Imagine we are testing whether the result of an application $e_1e_2$

is of type $t$ or not, and suppose we know that the static types of

$e_1$ and $e_2$ are $t_1$ and $t_2$ respectively. If the application $e_1e_2$ is

In this section we present the formalization of the ideas we hinted in the introduction. We start by the definitions of types. Next we define the language and its reduction semantics. The static semantics is the core of our presentation: we first present a declarative types system which deduces for every well-typed expressions several types and then the algorithms that allow us to decide welltypedness.

In this section we present the formalization of the ideas we hinted in the introduction. We start by the definitions of types. Next, we define the language and its reduction semantics. The static semantics is the core of our presentation: we first present a declarative type system that deduces possibly many types for the well-typed expressions and then the algorithms to decide whether an expression is well-typed or not.

\subsection{Types}

\begin{definition}[Type syntax]\label{def:types} The set of types \types{} is formed by the terms $t$ coinductively produced by the following grammar

\begin{definition}[Types]\label{def:types} The set of types \types{} is formed by the terms $t$ coinductively produced by the following grammar

\[

\begin{array}{lrcl}

\textbf{Types}& t & ::=& b\alt t\to t\alt t\times t\alt t\vee t \alt\neg t \alt\Empty

...

...

@@ -54,7 +54,8 @@ denotes the set of all functions.} and $\Any\to\Empty$ is the set

of functions that diverge on every argument). Type connectives

(\emph{ie}, union, intersection, negation) are interpreted as the

corresponding set-theoretic operators (\emph{eg},~$s\vee t$ is the

union of the values of the two types).

union of the values of the two types). We use $\simeq$ to denote the

symmetric closure of $\leq$: thus $s\simeq t$ means that $s$ and $t$ denote the same set of values and, as such, they are semantically the same type.

\subsection{Syntax}\label{sec:syntax}

The expressions $e$ and values $v$ of our language are the terms inductively generated by the following grammars:

...

...

@@ -161,14 +162,14 @@ core and the use of subtyping given by the following typing rules:

{}

\qquad

\end{mathpar}

These rules are quite standard and do not need any particular explanation. Just notice that we used a classic subsumption rule to embed subtyping in the type system.

These rules are quite standard and do not need any particular explanation. Just notice that we used a classic subsumption rule (\emph{ie}, \Rule{Subs}) to embed subtyping in the type system.

Let us now focus on the unconventional aspects of our system. starting

Let us now focus on the unconventional aspects of our system, starting

from the simplest ones. The first one is that, as explained in

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

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

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

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

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

expressions. Therefore, the type environments in our rules, 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 as follows:\beppe{Changed the name of Occ into Env since it seems more appropriate}

\begin{mathpar}

\Infer[Env]

{}

...

...

@@ -180,21 +181,21 @@ types. This explains why the classic typing rule for variables is replace by the

{\Gamma\vdash e: t_1 \wedge t_2 }

{}

\end{mathpar}

The rule is coupled with the classic intersection introduction rule

The \Rule{Env}rule is coupled with the classic intersection introduction rule

which allow us to deduce for a complex expression the intersection of

the types recorded by the occurrence typing analysis in the

environment $\Gamma$ with the static type deduced for the same

expression by using the other typing rules. This same intersection

rule is also used to infer the second unconventional aspect of our

system, that is the fact that $\lambda$abstractions can have negated

arrow types as long as this negation does not make their type empty:

system, that is, the fact that $\lambda$-abstractions can have negated

arrow types, as long as this negated types do not make their type empty:

Clearly, the expression above is well typed, but the rule \Rule{Abs+}

Clearly, the expression above is well typed, but the rule \Rule{Abs+} alone

is not enough to type it. In particular, according to \Rule{Abs+} we

have to prove that under the hypothesis that $x$ is of type $\Int$ the expression

$\tcase{x}{\Int}{x+1}{\textsf{true}}$ is of type $\Int$, too. That is that under the

$(\tcase{x}{\Int}{x+1}{\textsf{true}})$ is of type $\Int$, too. That is, that under the

hypothesis that x has type $\Int\wedge\Int$ (we apply occurrence

typing) the expression $x+1$ is of type \Int (which is ok) and that under the

typing) the expression $x+1$ is of type \Int{} (which holds) and that under the

hypothesis that $x$ has type $\Int\setminus\Int$, that is $\Empty$

(once more we apply occurrence typing), \textsf{true} is of type \Int

(which is not ok). The problem is that we are trying to type the

second case of a typecase even if we now that there is no chance that

that case will be selected. The fact that it is never selected is witnessed

by the fact that there is a type hypothesis with $\Empty$ type. To

(we apply once more occurrence typing), \textsf{true} is of type \Int{}

(which \emph{does not} hold). The problem is that we are trying to type the

second case of a type-case even if we know that there is no chance that, under the hypothesis that $x$ is of type $\Int$,

that case will be ever selected. The fact that it is never selected is witnessed

by the presence of a type hypothesis with $\Empty$ type. To

avoid this problem (and type the term above) we add the rule

\Rule{Efq} (\emph{ex falso quodlibet}) that allows to deduce any type

for an expression that will never be selected, that is for an

expression whose type environment has an empty assumption:

\Rule{Efq} (\emph{ex falso quodlibet}) that allows the system to deduce any type

for an expression that will never be selected, that is, for an

expression whose type environment contains an empty assumption:

\begin{mathpar}

\Infer[Efq]

{}

{\Gamma, (e:\Empty) \vdash e': t }

{}

\end{mathpar}

Once more, this kind of deduction was already present in~\cite{Frisch2008} to type full fledged overloaded functions, though it was embedded in the typing rule for the type-case. Here we need the more general \Rule{Efq} rule, to ensure the property of subject reduction.\beppe{Example?}

Once more, this kind of deduction was already present in the system

by~\citet{Frisch2008} to type full fledged overloaded functions,

though it was embedded in the typing rule for the type-case. Here we

need the rules \Rule{Efq}, which is more general, to ensure the

property of subject reduction.\beppe{Example?}

Finally, there is one final rule that is missing in our type system and which is the core of our work, the rule for the type-case:\beppe{Changed to \Rule{If} to \Rule{Case}}

Finally, there is one last rule in our type system, the one that

implements occurrence typing, that is, the rule for the

type-case:\beppe{Changed to \Rule{If} to \Rule{Case}}

\begin{mathpar}

\Infer[Case]

...

...

@@ -251,10 +258,10 @@ Finally, there is one final rule that is missing in our type system and which is

{\Gamma\vdash\tcase{e} t {e_1}{e_2}: t'}

{}

\end{mathpar}

The rule checks wheter the expression $e$ whose type is tested is

The rule \Rule{Case}checks whether the expression $e$, whose type is being tested, is

well-typed and then performs the occurrence typing analysis that produces

the environments $\Gamma_i$'s under whose hypothesis the expressions

$e_i$'s are typed. The production of these environments is represented by the judgement

$e_i$'s are typed. The production of these environments is represented by the judgment

$\Gamma\evdash p e t \Gamma_i$ (with $p$ either $+$ or $-$). The

intuition is that when $\Gamma\evdash p e t \Gamma_i$ is provable

then $\Gamma_i$ is $\Gamma$ extended with type hypothesis for all

...

...

@@ -262,9 +269,17 @@ expressions occurring in $e$, type hypothesis that can be deduced

assuming that the test $e\in t$ succeeds (for $p=+$) or fails (for

$p=-$).

All it remains to do is to show how to deduce judgements of the form $\Gamma\evdash p e t \Gamma'$. For that we first have to define how to denote occurrences of an expressions. These are just paths in the syntax trees of the expressions.

Let $e$ be an expression and $\varpi\in\{0,1,l,r,f,s\}^*$ a \emph{path}; we denote $\occ e\varpi$ the occurrence of $e$ reached by the path $\varpi$, that is

All it remains to do is to show how to deduce judgments of the form

$\Gamma\evdash p e t \Gamma'$. For that we first have to define how

to denote occurrences of an expressions. These are just paths in the

syntax trees of the expressions, that is, possibly empty strings of

characters denoting directions starting from the root of the tree (we

use $\epsilon$ for the empty string/path, which corresponds to the

root of the tree).

Let $e$ be an expression and $\varpi\in\{0,1,l,r,f,s\}^*$ a

\emph{path}; we denote $\occ e\varpi$ the occurrence of $e$ reached by

the path $\varpi$, that is

\[

\begin{array}{r@{\downarrow}l@{\quad=\quad}l}

e&\epsilon& e\\

...

...

@@ -279,8 +294,8 @@ undefined otherwise

To ease our analysis we used different directions for each kind of

term. So we have $0$ and $1$ for the function and argument of an

application, $l$ and $r$ for the $l$eft and $r$ight projections of a pair

and $f$ and $s$ for the argument of a $f$irst or a $s$econd projection. The the judgements $\Gamma\evdash p e t \Gamma'$ are deduced by these two rules:

application, $l$ and $r$ for the $l$eft and $r$ight expressions forming a pair

and $f$ and $s$ for the argument of a $f$irst or of a $s$econd projection. The judgments $\Gamma\evdash p e t \Gamma'$ are deduced by these two rules:

\begin{mathpar}

% \Infer[Base]

% { \Gamma \vdash e':t' }

...

...

@@ -301,33 +316,33 @@ and $f$ and $s$ for the argument of a $f$irst or a $s$econd projection. The the

{\Gamma\evdash p e t \Gamma',(\occ e \varpi:t') }

{}

\end{mathpar}

These rules describe how to deduce by occurrence typing the type

environts when checking that an expression $e$ has type $t$: we can

deduce $\Gamma$ all the hypothesis already in $\Gamma$ (rule

\Rule{Base}) and that if we can deduce a given for a particular

occurrence $\varpi$ of the $e$ checked, than we can add this

hypothesis to our type environment (rule \Rule{Path}). The rule

These rules describe how to produce by occurrence typing the type

environments while checking that an expression $e$ has type $t$. They state that $(i)$ we can

deduce from $\Gamma$ all the hypothesis already in $\Gamma$ (rule

\Rule{Base}) and that $(ii)$if we can deduce a given type $t'$for a particular

occurrence $\varpi$ of the expression $e$ being checked, than we can add this

hypothesis to the produced type environment (rule \Rule{Path}). The rule

\Rule{Path} uses a (last) auxiliary judgement $\pvdash{\Gamma} p e t

\varpi:t'$ to deduce the type of the occurrence $\occ e \varpi$ when

checking $e$ against $t$. This rule is subtler than it appears at

first sight, insofar as the deduction of the type for $\varpi$ may use

some hypothesis on $\occ e \varpi$ (in $\Gamma'$) and from an

algorithmic viewpoint this will imply the computation of a fix-point

(see Section~\ref{}). The last ingredient is the deduction of the

checking $e$ against $t$ under the hypotheses $\Gamma$. This rule \Rule{Path} is subtler than it may appear at

first sight, insofar as the deduction of the type for $\varpi$ may already use

some hypothesis on $\occ e \varpi$ (in $\Gamma'$) and, from an

algorithmic viewpoint, this will imply the computation of a fix-point

(see Section~\ref{sec:typenv}). The last ingredient for our type system is the deduction of the

judgements of the form $\pvdash{\Gamma} p e t \varpi:t'$ where

$\varpi$ is an occurrence of$e$. These is given by the following set

$\varpi$ is a path to an expression occurring in$e$. This is given by the following set

of rules.

\begin{mathpar}

\Infer[PIntersect]

{\pvdash\Gamma p e t \varpi:t_1 \\\pvdash\Gamma p e t \varpi:t_2 }

{\pvdash\Gamma p e t \varpi:t_1\land t_2 }

{}

\qquad

\Infer[PSubs]

{\pvdash\Gamma p e t \varpi:t_1 \\ t_1\leq t_2 }

{\pvdash\Gamma p e t \varpi:t_2 }

{}

\qquad

\Infer[PIntersect]

{\pvdash\Gamma p e t \varpi:t_1 \\\pvdash\Gamma p e t \varpi:t_2 }

{\pvdash\Gamma p e t \varpi:t_1\land t_2 }

{}

\\

\Infer[PTypeof]

{\Gamma\vdash\occ e \varpi:t' }

...

...

@@ -345,9 +360,9 @@ of rules.

{}

\\

\Infer[PAppR]

{\pvdash\Gamma p e t \varpi.0:\arrow{t_1}{t_2}\\\pvdash\Gamma p e t \varpi:t_2'\\ t_2\land t_2' \simeq\Empty}

{\pvdash\Gamma p e t \varpi.0:\arrow{t_1}{t_2}\\\pvdash\Gamma p e t \varpi:t_2'}

{\pvdash\Gamma p e t \varpi.1:\neg t_1 }

{}

{t_2\land t_2' \simeq\Empty}

\\

\Infer[PAppL]

{\pvdash\Gamma p e t \varpi.1:t_1 \\\pvdash\Gamma p e t \varpi:t_2 }

...

...

@@ -375,7 +390,41 @@ of rules.

{}

\qquad

\end{mathpar}

Let us comment each rule in detail.

These rules implement the analysis described in

Section~\ref{sec:ideas} for functions and extend it to products. Let

us comment each rule in detail. \Rule{PSubs} is just subsumption for

the deduction $\vdashp$. The rule \Rule{PIntersect} combined with

\Rule{PTypeof} allows the system to deduce for an occurrence $\varpi$

the intersection of the static type of $\occ e \varpi$ (deduced by

\Rule{PTypeof}) and the type deduced for $\varpi$ by the other $\vdashp$ rules. The

rules \Rule{PEps\,$p$} are the starting points of the analysis: when

checking whether $e$ has type $t$ we can assume that $e$ (\emph{ie},

$\occ e\epsilon$) has type $t$ in the positive branch (rule

\Rule{PEps+}) and type $\neg t$ in the negative branch (rule

\Rule{PEps-}). The rule \Rule{PApprR} implements occurrence typing for

the arguments of applications, since it states that if a function maps

arguments of type $t_1$ in results of type $t_2$ and an application of

this function yields results (in $t'_2$) that cannot be in $t_2$

(since $t_2\land t_2' \simeq\Empty$), then the argument of this application cannot be of type $t_1$. \Rule{PAppR} performs the

occurrence typing analysis for the function part of an application,

since it states that if an application has type $t_2$ and the argument

of this application has type $t_1$, then the function in this

application cannot have type $t_1\to\neg t_2$. Rules \Rule{PPair\_}

are straightforward since they state that $i$-th projection of a pair

of type $\pair{t_1}{t_2}$ must be of type $t_i$. So are the last two

rules that essentially state that if $\pi_1 e$ (respectively, $\pi_2

e$) is of type $t'$, then the type of $e$ must be of the form

$\pair{t'}\Any$ (respectively, $\pair\Any{t'}$).

This concludes the presentation of our type system, which satisfies

the property of soundness, deduced, as customary, from the properties

of progress and subject reduction, whose proof is given in the

appendix.

\begin{theorem}[soundness]

For every expression $e$ such that $\varnothing\vdash e:t$ either there

exists a value $v$ of type $t$ such that $e\reduces^* v$ or $e$

diverges.

\end{theorem}

...

...

@@ -390,7 +439,9 @@ Let us comment each rule in detail.

\item type of functions -> type schemes

\item elimination rules (app, proj,if) ->operations on types and how to compute them

\item not syntax directed: rules Subs, Intersect, Env.

\item Compute the environments for occurrence typing. Algorithm to compute $\Gamma\vdash\Gamma$

\end{enumerate}

...

...

@@ -408,7 +459,7 @@ change the definition of typeof to take into account type-schemes for lambda abs

\paragraph{Algorithmic version}

\subsubsection{Type envs for occurrence typing}

\subsubsection{Type environments for occurrence typing}\label{sec:typenv}