### Typos in practical, removed work done from conclusion, and related work.

parent 0b71098c
 ... @@ -48,10 +48,9 @@ let not_ = fun (x : Any) -> ... @@ -48,10 +48,9 @@ let not_ = fun (x : Any) -> $(\Keyw{True}\to\Keyw{False})\land(\lnot\Keyw{True}\to\Keyw{True})$\\\hline $(\Keyw{True}\to\Keyw{False})\land(\lnot\Keyw{True}\to\Keyw{True})$\\\hline 5 & 5 & \begin{lstlisting} \begin{lstlisting} let or_ = fun (x : Any) -> let or_ = fun (x : Any) -> fun (y: Any) -> if x is True then (fun (y : Any) -> true) if x is True then true else fun (y : Any) -> else if y is True then true else false if y is True then true else false \end{lstlisting} \end{lstlisting} &\smallskip\vfill &\smallskip\vfill $(\True\to\Any\to\True)\land(\Any\to\True\to\True)\land$\newline $(\True\to\Any\to\True)\land(\Any\to\True\to\True)\land$\newline ... @@ -77,18 +76,15 @@ let f = fun (x : Any) -> fun (y : Any) -> ... @@ -77,18 +76,15 @@ let f = fun (x : Any) -> fun (y : Any) -> \end{lstlisting}& \end{lstlisting}& $(\Int \to (\Int \to 2) \land (\lnot\Int \to 1 \lor 3) \land (\Bool \to 1) \land$\newline $(\Int \to (\Int \to 2) \land (\lnot\Int \to 1 \lor 3) \land (\Bool \to 1) \land$\newline \hspace*{1cm}$(\lnot(\Bool \lor \Int) \to 3) \land \hspace*{1cm}$(\lnot(\Bool \lor \Int) \to 3) \land (\lnot\Bool \to 2\lor3))$\newline (\lnot\Bool \to 2\lor3))$~~$\land$\newline $\land$\newline $(\Char \to (\Int \to 2) \land (\lnot\Int \to 2) \land (\Bool \to 2) \land$\newline $(\Char \to (\Int \to 2) \land (\lnot\Int \to 2) \land (\Bool \to 2) \land$\newline \hspace*{1cm}$(\lnot(\Bool \lor \Int) \to 2) \land \hspace*{1cm}$(\lnot(\Bool \lor \Int) \to 2) \land (\lnot\Bool \to 2))$\newline (\lnot\Bool \to 2))$~~$\land$\newline $\land$\newline% $(\lnot(\Int \lor \Char) \to (\Int \to 2) \land$(\lnot(\Int \lor \Char) \to (\Int \to 2) \land (\lnot\Int \to 3) \land$\newline (\lnot\Int \to 3) \land$\newline \hspace*{0.2cm}$(\Bool \to 3) \land(\lnot(\Bool \lor \Int) \to 3) \hspace*{0.2cm}$(\Bool \to 3) \land(\lnot(\Bool \lor \Int) \to 3) \land (\lnot\Bool \to 2 \land (\lnot\Bool \to 2 \lor 3))$\newline \lor 3))$~~$\land \ldots$ (two other redundant cases ommitted) $\land \ldots$ (two other redundant cases ommitted) % \newline % \newline % $(\lnot\Char \to (\Int \to 2) \land (\lnot\Int \to 1 \lor 3) \land (\Bool \to 1 \lor 3) \land$\newline % $(\lnot\Char \to (\Int \to 2) \land (\lnot\Int \to 1 \lor 3) \land (\Bool \to 1 \lor 3) \land$\newline % \hspace*{1cm}$(\lnot(\Bool \lor \Int) \to 3) \land % \hspace*{1cm}$(\lnot(\Bool \lor \Int) \to 3) \land ... @@ -110,13 +106,12 @@ let test_3 = f nil nil ... @@ -110,13 +106,12 @@ let test_3 = f nil nil 8 & 8 & \begin{lstlisting} \begin{lstlisting} type Document = { nodeType=9 ..} type Document = { nodeType=9 ..} and Element = { nodeType=1, and Element = { childNodes=NodeList, childNodes = NodeList .. } nodeType=1 ..} and Text = { nodeType=3, and Text = { isElementContentWhiteSpace=Bool, isElementContentWhiteSpace=Bool nodeType=3, ..} .. } and Node = Document | Element | Text and Node = Document | Element | Text and NodeList = Nil | (Node, NodeList) and NodeList = Nil | (Node, NodeList) let is_empty_node = fun (x : Node) -> let is_empty_node = fun (x : Node) -> if x.nodeType is 9 then false if x.nodeType is 9 then false ... ...
 ... @@ -3,19 +3,15 @@ typing, extended it to record types and a proposed a couple of novel ... @@ -3,19 +3,15 @@ typing, extended it to record types and a proposed a couple of novel applications of the theory, namely the inference of applications of the theory, namely the inference of intersection types for functions and a static analysis to reduce the number of intersection types for functions and a static analysis to reduce the number of casts inserted when compiling gradually-typed programs. casts inserted when compiling gradually-typed programs. One of the by products of our work is the ability to define type One of the by-products of our work is the ability to define type predicates such as those used in \cite{THF10} as plain function and predicates such as those used in \cite{THF10} as plain function and have the inference procedure deduce automatically the correct have the inference procedure deduce automatically the correct overloaded function type. overloaded function type. There is still a lot of work to do to fill the gap with real-word There is still a lot of work to do to fill the gap with real-word programming languages. Some of it should be quite routine such as the programming languages. For example, our analysis cannot handle flow of handling of more complex information. kinds of checks (e.g., generic Boolean expression, multi-case In particular, the result of a type test can flow only to the branches type-checks) and even encompass sophisticated type matching as the one performed by the CDuce language. Some other will require more work. For example, our analysis cannot handle flow of information. In particular, the result of a type test can flow only to the branches but not outside the test. As a consequence the current system cannot but not outside the test. As a consequence the current system cannot type a let binding such as \code{ type a let binding such as \code{ %\begin{alltt}\color{darkblue} %\begin{alltt}\color{darkblue} ... ...
 ... @@ -5,7 +5,7 @@ system of Section~\ref{sec:static}. In particular, as we ... @@ -5,7 +5,7 @@ system of Section~\ref{sec:static}. In particular, as we explained in Section~\ref{ssec:algorithm}, in the absence of type explained in Section~\ref{ssec:algorithm}, in the absence of type schemes it is not always possible to prove that $\forall v, \forall t, schemes it is not always possible to prove that$\forall v, \forall t, v \in t \text{~or~} v \not\in \lnot t$. Since this property cease v \in t \text{~or~} v \not\in \lnot t$. Since this property cease to hold only for $\lambda$-abstractions, then not using type schemes to hold only for $\lambda$-abstractions, then not using type schemes yields less precise typing only for tests $\ifty{e}t{e_1}{e_2}$ where $e$ yields less precise typing only for tests $\ifty{e}t{e_1}{e_2}$ where $e$ has a functional type, that is, the value tested will be a $\lambda$-abstraction. has a functional type, that is, the value tested will be a $\lambda$-abstraction. This seems like a reasonable compromise between the This seems like a reasonable compromise between the ... @@ -40,10 +40,10 @@ type ... @@ -40,10 +40,10 @@ type $(\Int\to\Int)\land(\Bool\to\Bool)\land(\Bool\vee\Int\to\Bool\vee\Int)$ $(\Int\to\Int)\land(\Bool\to\Bool)\land(\Bool\vee\Int\to\Bool\vee\Int)$ with a redundant arrow. Here we can see that since we deduced with a redundant arrow. Here we can see that since we deduced the first two arrows $(\Int\to\Int)\land(\Bool\to\Bool)$, and since the first two arrows $(\Int\to\Int)\land(\Bool\to\Bool)$, and since the union of their domain exactly covers the domain the third arrow, the union of their domain exactly covers the domain of the third arrow, the latter is not needed. Code~2 shows what happens when the argument the latter is not needed. Code~2 shows what happens when the argument of the function is left unannotated (i.e., it is annotated by the top of the function is left unannotated (i.e., it is annotated by the top type \Any, written \texttt{Any} in our implementation). Here type \Any, written \texttt{Any} in our implementation). Here type-checking and refinement also work as expected, but the function type-checking and refinement also work as expected, but the function only type checks if all cases for \texttt{x} are covered (which means only type checks if all cases for \texttt{x} are covered (which means that the function must handle the case of inputs that are neither in \Int{} that the function must handle the case of inputs that are neither in \Int{} ... @@ -58,17 +58,20 @@ a particular type, are just plain functions with an intersection ... @@ -58,17 +58,20 @@ a particular type, are just plain functions with an intersection type inferred by the system of Section~\ref{sec:refining}. We next define Boolean connectives as overloaded type inferred by the system of Section~\ref{sec:refining}. We next define Boolean connectives as overloaded functions. The \texttt{not\_} connective (Code~4) just tests whether its functions. The \texttt{not\_} connective (Code~4) just tests whether its argument is the Boolean \texttt{true} by testing that it belongs to argument is the Boolean \texttt{true} by testing that it belongs to the singleton type \True{} (the type whose only value is \texttt{true}) returning \texttt{false} for it and \texttt{true} for any other value (recall that $\neg\True$ is equivalent to $\texttt{Any\textbackslash}\True$). It works on values of any type, but we could restrict it to Boolean values by simply annotating the parameter by \Bool{} (which in CDuce is syntactic sugar for \True$\vee$\False) yielding the type $(\True{\to}\False)\wedge(\False{\to}\True)$. the singleton type \True{} (the type whose only value is The \texttt{or\_} connective (Code~5) is defined as a \texttt{true}) returning \texttt{false} for it and \texttt{true} for curried function, that first type cases on its argument. Depending any other value (recall that $\neg\True$ is equivalent to on this first type it may return either a constant function that returns $\texttt{Any\textbackslash}\True$). It works on values of any type, \texttt{true} for every input, or, a function that but we could restrict it to Boolean values by simply annotating the discriminates on its argument (which is the second argument of the parameter by \Bool{} (which in CDuce is syntactic sugar for \texttt{or\_}) and returns \texttt{true} or \texttt{false} \True$\vee$\False) yielding the type accordingly. Again we use a generalized version of the $(\True{\to}\False)\wedge(\False{\to}\True)$. The \texttt{or\_} connective (Code~5) is straightforward as far as the code goes, but we see that the overloaded type precisely capture all the possible cases. Again we use a generalized version of the \texttt{or\_} connective that accepts and treats any value that is not \texttt{or\_} connective that accepts and treats any value that is not \texttt{true} as \texttt{false} and again, we could restrict the \texttt{true} as \texttt{false} and again, we could easily restrict the domain to \Bool{} if we want. domain to \Bool{} if desired. To showcase the power of our type system, and in particular of To showcase the power of our type system, and in particular of the $\worra{}{}$'' the $\worra{}{}$'' ... @@ -117,8 +120,8 @@ nodes. This splits, at the type level, the case for the \Keyw{Element} ... @@ -117,8 +120,8 @@ nodes. This splits, at the type level, the case for the \Keyw{Element} type depending on whether the content of the \texttt{childNodes} field type depending on whether the content of the \texttt{childNodes} field is the empty list or not. is the empty list or not. Our implementation features one last improvement that allows us Our implementation features one last enhancement that allows us further improve the precision of the inferred type. to further improve the precision of the inferred type. Consider the definition of the \texttt{xor\_} operator (Code~9). Consider the definition of the \texttt{xor\_} operator (Code~9). Here the rule~[{\sc AbsInf}+] is not sufficient to precisely type the Here the rule~[{\sc AbsInf}+] is not sufficient to precisely type the function, and using only this rule would yield a type function, and using only this rule would yield a type ... @@ -156,7 +159,7 @@ since, \texttt{or\_} has type\\ ... @@ -156,7 +159,7 @@ since, \texttt{or\_} has type\\ \centerline{$(\True\to\Any\to\True)\land(\Any\to\True\to\True)\land \centerline{$(\True\to\Any\to\True)\land(\Any\to\True\to\True)\land (\lnot\True\to\lnot\True\to\False)$} (\lnot\True\to\lnot\True\to\False)$} We consider \True, \Any and $\lnot\True$ as candidate types for 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{or\_} 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 force refinement by using a type case. As a consequence we can define the functions \texttt{and\_} and \texttt{xor\_} more naturally as: \begin{alltt}\color{darkblue}\morecompact \begin{alltt}\color{darkblue}\morecompact let and_ = fun (x : Any) -> fun (y : Any) -> not_ (or_ (not_ x) (not_ y)) 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)) let xor_ = fun (x : Any) -> fun (y : Any) -> and_ (or_ x y) (not_ (and_ x y)) ... ...
 Occurrence typing is for variables in TypeScript, also paths in Flow. STRESS THE USE OF INTERSECTIONS AND UNIONS. ACTUALLY SPEAK OF UNION AND NEGATION (UNION FOR ALTERNATIVES, NEGATION FOR TYPING THE ELSE BRANCH AND THEREFORE WE GET INTERSECTION FOR FREE) \kim{ \citet{THF10} extend to selectors, logical connectives, paths, and user I don't really know about these:\\ Occurrence typing is for variables in TypeScript, also paths in Flow. STRESS THE USE OF INTERSECTIONS AND UNIONS. ACTUALLY SPEAK OF UNION AND NEGATION (UNION FOR ALTERNATIVES, NEGATION FOR TYPING THE ELSE BRANCH AND THEREFORE WE GET INTERSECTION FOR FREE) extend to selectors, logical connectives, paths, and user defined predicates. defined predicates. [IMPORTANT: check the differences with what we do here] [IMPORTANT: check the differences with what we do here] State what we capture already, for instance lists since we have product and recursive types. State what we capture already, for instance lists since we have product and recursive types. } Occurrence typing was introduced by \citet{THF08} and further advanced in \cite{THF10} in the context of the Typed Racket language. This latter work in particular is close to ours, with some key differences. The work of \cite{THF10} defines $\lambda_{TR}$, a core calculus for typed racket. In this language types are annotated by logical propositions that records the type of the input depending on the (Boolean) value of the output. For instance, the type of the {\tt number?} function states that when the output is {\tt true}, then the argument has type {\tt Number}, and when the output is false, the argument does not. Such information is used selectively in the then'' and else'' branches of a test. One area where this work goes further than ours is that the type informations also flows outside of the tests to the surrounding context. In contrast, our type system only refine the type of variables strictly in the branches of a test. However using semantic-subtyping as a foundation we believe our approach has several merrits over theirs. First, in our case, type predicates are not built-in. A user may define any type predicate she wishes by using an overloaded function, as we have shown in Section~\ref{sec:practical}. Second, in our setting, {\em types\/} play the role of formulæ. Using set-theoretic types, we can express the complex types of variables without resorting to a meta-logic. This allows us to type all but one of their key examples (with the notable exception of their Example~8 which uses the propgation of type information outside of the branches of a test). Also, while they extend their core calculus with pairs, they only provide a simple {\tt cons?} predicate that allows them to test whether some value is a pair. It is therefore unclear whether their systems allows one to write predicates over list types ({\em .e.g\/} test whether the input is a list of integers), which we can easily do thanks to our support for recursive types. \ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!