### finished Section 2

parent 3ccd510e
 ... ... @@ -10,9 +10,9 @@ In this section we formalize the ideas we outlined in the introduction. We start \] and that satisfy the following conditions \begin{itemize} \item (regularity) the term has a finite number of different sub-terms; \item (contractivity) every infinite branch of a type contains an infinite number of occurrences of the arrow type constructor. \item (regularity) every term has a finite number of different sub-terms; \item (contractivity) every infinite branch of a term contains an infinite number of occurrences of the arrow or product type constructors. \end{itemize} \end{definition} We use the following abbreviations for types: $... ... @@ -30,9 +30,9 @@ set). It also ensures that the binary relation$\vartriangleright \,\subseteq\!\types^{2}$defined by$t_1 \lor t_2 \vartriangleright t_i$,$t_1 \land t_2 \vartriangleright t_i$,$\neg t \vartriangleright t$is Noetherian.\footnote{In a nutshell, we can do proofs of induction on the structure of unions and negations---and, thus, intersections---but arrows, products, and basic types are the base cases for the induction.} t_i$, $\neg t \vartriangleright t$ is Noetherian. This gives an induction principle on $\types$ that we will use without any further explicit reference to the relation. will use without any further explicit reference to the relation.\footnote{In a nutshell, we can do proofs by induction on the structure of unions and negations---and, thus, intersections---but arrows, products, and basic types are the base cases for the induction.} We refer to $b$, $\times$, and $\to$ as \emph{type constructors} and to $\lor$, $\land$, $\lnot$, and $\setminus$ as \emph{type connectives}. ... ... @@ -89,7 +89,7 @@ values. \subsection{Dynamic semantics}\label{sec:opsem} The dynamic semantics is defined as a classic left-to-right cbv reduction for a $\lambda$-calculus with pairs enriched with a specific rule for type-cases. We have the following notions of reduction: The dynamic semantics is defined as a classic left-to-right call-by-value reduction for a $\lambda$-calculus with pairs, enriched with specific rules for type-cases. We have the following notions of reduction: $\begin{array}{rcll} (\lambda^{\wedge_{i\in I}s_i\to t_i} x.e)v &\reduces& e\subst x v\\ ... ... @@ -100,7 +100,7 @@ The dynamic semantics is defined as a classic left-to-right cbv reduction for a$ The semantics of type-cases uses the relation $v\in t$ that we informally defined in the previous section. We delay its formal definition to Section~\ref{sec:type-schemes} (it deals with some corner cases for functional values). Context reductions are definition to Section~\ref{sec:type-schemes} (where it deals with some corner cases for functional values). Context reductions are defined by the following reduction contexts: $\Cx[] ::= [\,]\alt \Cx e\alt v\Cx \alt (\Cx,e)\alt (v,\Cx)\alt \pi_i\Cx\alt \tcase{\Cx}tee ... ... @@ -181,19 +181,21 @@ types. This explains why the classic typing rule for variables is replaced by a { } \end{mathpar} The \Rule{Env} rule is coupled with the standard intersection introduction rule \Rule{Inter} which allow us to deduce for a complex expression the intersection of which allows 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 these negated types do not make their type empty: arrow types, as long as these negated types do not make the type deduced for the function empty: \begin{mathpar} \Infer[Abs-] {\Gamma \vdash \lambda^{\wedge_{i\in I}\arrow {s_i} {t_i}}x.e:t} { \Gamma \vdash\lambda^{\wedge_{i\in I}\arrow {s_i} {t_i}}x.e:\neg(t_1\to t_2) } { (t\wedge\neg(t_1\to t_2))\not\simeq\Empty } \end{mathpar} \beppe{I have doubt: is this safe or should we play it safer and deduce t\wedge\neg(t_1\to t_2)? In other terms is is possible to deduce two separate negation of arrow types that when intersected with the interface are non empty, but by intersecting everything makes the type empty? It should be safe since otherwise intersection would not be admissible in semantic subtyping (see Theorem 6.15 in JACM), but I think we should doube ckeck it.} As explained in Section~\ref{sec:challenges}, we need to be able to deduce for, say, the function \lambda^{\Int\to\Int} x.x a type such as (\Int\to\Int)\wedge\neg(\Bool\to\Bool) (in particular, if this is ... ... @@ -299,8 +301,8 @@ e_0e_1& i.\varpi & \occ{e_i}\varpi\qquad i=0,1\\ 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 left and right expressions forming a pair, and f and s for the argument of a first or of a second projection. Note also that we do not consider occurrnces under \lambdas (since their type is frozen in their annotations) and type-cases (since they reset the analysis).\beppe{Is it what I wrote here true?} and f and s for the argument of a first or of a second projection. Note also that we do not consider occurrences under \lambda's (since their type is frozen in their annotations) and type-cases (since they reset the analysis).\beppe{Is it what I wrote here true?} The judgments \Gamma \evdash e t \Gamma' are then deduced by the following two rules: \begin{mathpar} ... ... @@ -412,7 +414,7 @@ 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 the i-th projection of a pair of type \pair{t_1}{t_2} must be of type t_i. So are the last two that is 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'}). ... ... @@ -573,7 +575,7 @@ denotes functions that will return an integer if applied to an integer, and will return a Boolean if applied to a Boolean. It is possible to compute the domain of such a type (i.e., of the functions of this type), denoted by \code{$$\texttt{dom}(t) = \Int \vee \Bool$$}, $$\dom{t} = \Int \vee \Bool$$, that is the union of all the possible input types. But what is the precise return type of such a function? It depends on what the argument of such a function is: ... ... @@ -629,7 +631,7 @@ takes as input \Gamma, e, and t, and returns an environment that extends \Gamma with hypotheses on the occurrences of e that are the most general that can be deduced by assuming that e\in t succeeds. We start by defining the algorithm for each single occurrence, that is for the deduction of \pvdash \Gamma e t \varpi:t'. This is obtained by defining two mutually recursive functions: We start by defining the algorithm for each single occurrence, that is for the deduction of \pvdash \Gamma e t \varpi:t'. This is obtained by defining two mutually recursive functions \constrf and \env{}{}: \newlength{\sk} \setlength{\sk}{-1.3pt} \begin{eqnarray} ... ... @@ -677,7 +679,7 @@ We start by defining the algorithm for each single occurrence, that is for the d All the functions above are defined if and only if so all their subexpressions are (i.e., \occ e{\varpi.i} must be defined). Each case of the definition of the \constr{}{} function corresponds to the Each case of the definition of the \constrf function corresponds to the application of a logical rule (\emph{cf.} Footnote~\ref{fo:rules}) in the deduction system for \vdashp: case \eqref{uno} corresponds to the application of \Rule{PEps}; case \eqref{due} implements \Rule{Pappl} ... ... @@ -693,18 +695,18 @@ respectively. The other recursive function, \env{}{}, implements the two structural rules \Rule{PInter} and \Rule{PTypeof} by intersecting the type obtained for \varpi by the logical rules, with the static type deduce by the type system of the expression occurring at \varpi. The deduced by the type system of the expression occurring at \varpi. The remaining structural rule, \Rule{Psubs}, is accounted for by the use of the operators \worra{}{} and \boldsymbol{\pi}_i in the definition of \constr{}{}. The notation \tyof{e}{\Gamma} denotes the type that can be deduced for the occurence e under the type environment \Gamma in the algorithmic type system given in Section~\ref{sec:algorules}. That is, \tyof{e}{\Gamma}=\ts if and only if \Gamma\vdashA e:\ts is provable. That is, \tyof{e}{\Gamma}=\ts if and only if \Gamma\vdashA e:\ts is provable. \footnote{Note that the definition is well-founded. This can be seen by analyzing the rule \Rule{Case\Aa}: the definition of \Refine {e,t} \Gamma and \Refine {e,\neg t} \Gamma use \tyof{\occ e{\varpi}}\Gamma, and this is defined for all \varpi since the first premisses of \Rule{Case\Aa} states that \Gamma\vdash e:\ts_0 (and this is possible only if we were able to deduce under the hypothesis \Gamma the type of every occurrence of e.)} \Gamma\vdash e:\ts_0 (and this is possible only if we were able to deduce under the hypothesis \Gamma the type of every occurrence of e.)} It extends the corresponding notation we gave for values in Section~\ref{sec:type-schemes}. It remains to explain how to compute the environment \Gamma' produced from \Gamma by the deduction system for \Gamma \evdash e t \Gamma'. Alas, this is the most delicate part of our algorithm. ... ... @@ -738,8 +740,8 @@ above to a result of \Refinef, and so on. Therefore, ideally our algorithm should compute the type environment as a fixpoint of the function X\mapsto\Refine{e,t}{X}. Unfortunately, an iteration of \Refinef may not converge. As an example consider the (dumb) expression \tcase {x_1x_2}{\Any}{e_1}: if x_1:\Any\to\Any, then every iteration of \Refinef yields for x_1 a type strictly more precise than the {x_1x_2}{\Any}{e_1}{e_2}: if x_1:\Any\to\Any, then every iteration of \Refinef yields for x_1 a type strictly more precise than the type deduced in the previous iteration. The solution we adopt here is to bound the number of iterations to some number n_o. ... ... @@ -755,8 +757,8 @@ From a formal point of view, this means to give up the completeness of the algor \end{array}\right. \end{array}$ Note in particular that $\Refine{e,t}\Gamma$ extends extends $\Gamma$ with hypotheses on the expressions occurring in $e$, since $\dom{\Refine{e,t}\Gamma} = \dom{\RefineStep {e,t}}(\Gamma) = \dom{\Gamma} \cup \{e' \alt \exists \varpi.\ \occ e \varpi \equiv e'\}$. Note in particular that $\Refine{e,t}\Gamma$ extends $\Gamma$ with hypotheses on the expressions occurring in $e$, since $\dom{\Refine{e,t}\Gamma} = \dom{\RefineStep {e,t}(\Gamma)} = \dom{\Gamma} \cup \{e' \alt \exists \varpi.\ \occ e \varpi \equiv e'\}$. In other terms, we try to find a fixpoint of $\RefineStep{e,t}$ but we bound our search to $n_o$ iterations. Since $\RefineStep {e,t}$ is ... ... @@ -774,17 +776,16 @@ type (which is quite rare in practice)\footnote{The only impact of never happens since programming languages test whether a value \emph{is} a function, rather than the type of a given function.}, but also we had to build the expression that causes the divergence in quite an ad hoc way which makes divergence even more unlikely: setting quite an \emph{ad hoc} way which makes divergence even more unlikely: setting an $n_o$ twice the depth of the syntax tree of the outermost type case should capture all realistic cases \beppe{can we give an estimate based on benchmarking the protottype?} should be enough to capture all realistic cases \beppe{can we give an estimate based on benchmarking the prototype?} \subsection{Algorithmic typing rules}\label{sec:algorules} We now have all notions needed for our typing algorithm, which is defined by the following rules. \begin{mathpar} \Infer[Efq\Aa] { } ... ... @@ -847,7 +848,30 @@ should capture all realistic cases \beppe{can we give an estimate {\Gamma \vdashA e_1:\ts_1 \and \Gamma \vdashA e_2:\ts_2} {\Gamma \vdashA (e_1,e_2):{\ts_1}\tstimes{\ts_2}}%\pair{t_1}{t_2}} {(e_1,e_2)\not\in\dom\Gamma} \end{mathpar} The side conditions of the rules ensure that the system is syntax directed, that is, that at most one rule applies when typing a term: priority is given to \Rule{Eqf\Aa} over all the other rules and to \Rule{Env\Aa} over all remaining (logical) rules. Type schemes are used to account the type multiplicity stemming from $\lambda$-abstractions as shown in particular by rule \Rule{Abs\Aa} (in what follows we use the word type'' also for type schemes). The subsumption rule is no longer in the system. It is replaced by: $(i)$ using a union type in \Rule{Case\Aa}, $(ii)$ checking in \Rule{Abs\Aa} that the body of the function is typed by a subtype of the type declared in the annotation, and $(iii)$ using type operators and checking subtyping in the elimination rules \Rule{App\Aa,Proj\Aa}. In particular, for \Rule{App\Aa} notice that it checks that the type of the function is a functional type, that the type of the argument is a subtype of the domain of the function, and then returns the result type of the application of the two types. The intersection rule is replaced by the use of type schemes in \Rule{Abs\Aa} and by the rule \Rule{Env\Aa}. The latter intersects the type deduced for an expression $e$ by occurrence typing and stored in $\Gamma$ with the type deduced for $e$ by the logical rules: this is simply obtained by removing any hypothesis about $e$ from $\Gamma$, so that the deduction of the type $\ts$ for $e$ cannot but end by a logical rule. The system above satisfies the following properties:\beppe{State here soundness and partial completeness}
 ... ... @@ -177,10 +177,10 @@ Text of abstract \ldots. \label{sec:language} \input{language2} {\color{gray} \section{OLD LANGUAGE} \input{language} } %{\color{gray} %\section{OLD LANGUAGE} %\input{language} %} \section{Extensions} \label{sec:extensions} ... ...
 ... ... @@ -122,7 +122,9 @@ \newcommand{\Refine}{\ensuremath{\Refinef_{#1}(#2)}} \newcommand{\RefineStep}{\textsf{RefineStep}_{#1}} \newcommand{\constr}{\textsf{Constr}_{#2}(#1)} \newcommand{\constrf}{\textsf{Constr}} \newcommand{\constr}{\constrf_{#2}(#1)} %\newcommand{\env}{\textsf{Env}_{#1}} \newcommand{\env}{\textsf{Intertype}_{#1}} ... ...
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!