### finished example 14

parent 4bdf9ce9
 ... ... @@ -72,7 +72,7 @@ if (if (is_int x) is True then (is_string y) else false) is True then add x (strlen y) else 0 \end{lstlisting} & \end{lstlisting} &\medskip\vfill $(\Int \to \String \to \Int) \land (\Int \to \lnot \String \to 0))~\land$\newline $(\lnot \Int \to \String \to 0) \land (\lnot \String \to 0)$ (identical to example 5) ... ... @@ -81,7 +81,7 @@ $(\lnot \Int \to \String \to 0) \land (\lnot \String \to 0)$ let example8 = fun (x : Any) -> if or_ (is_int x) (is_string x) is True then true else false \end{lstlisting} & \end{lstlisting} &\smallskip\vfill $(\Int \to \True)\land(\String \to \True)~\land$\newline $(\lnot(\String\lor\Int)\to \False)$ \\\hline ... ... @@ -91,7 +91,7 @@ let example9 = fun (x : Any) -> if (if is_int x is True then is_int x else is_string x) is True then f x else 0 \end{lstlisting} & \end{lstlisting} &\smallskip\vfill $(\Int \to \Int) \land (\String \to \Int)~\land$\newline $(\lnot (\String\lor\Int)\to 0)$ \\\hline ... ... @@ -113,7 +113,7 @@ let example11 = fun (p : (Any, Any)) -> let example12 = fun (p : (Any, Any)) -> if is_int (fst p) is True then true else false \end{lstlisting} & \vfill \end{lstlisting} &\medskip \vfill $((\Int,\textsf{Any}) -> \True) \land ((\lnot \Int,\textsf{Any}) -> \False) )$ \\\hline 13 & \begin{lstlisting} ... ... @@ -128,16 +128,15 @@ $(\lnot \Int \to \textsf{Any} \to 3)$ 14 & \begin{lstlisting} let example14_alt = fun (input : Int | String) -> fun (extra : (Any, Any)) -> if (input, is_int (fst extra)) is (Int, True) then add input (fst extra) else if (input, is_int (fst extra)) is (Any,True) then add (strlen input) (fst extra) else 0 \end{lstlisting} & \vfill $(\Int \to (\Int,\textsf{Any}) \to \Int) ~\land~ (\Int \to (\lnot \Int, \textsf{Any}) \to 0) ~\land~$\newline $(\String \to (\Int,\textsf{Any}) \to \Int) ~\land~ (\String \to (\lnot \Int, \textsf{Any}) \to 0)$ if and2_((is_int input),(is_int (fst extra))) is True then add input (fst extra) else if (is_int input,is_int (fst extra)) is (Any,True) then add (strlen input) (fst extra) else 0\end{lstlisting} & \medskip\medskip\vfill $(\Int \to ((\Int,\textsf{Any}) \to \Int) \wedge ((\lnot\Int,\textsf{Any}) \to 0))\wedge$\newline $(\String \to ((\Int,\textsf{Any}) \to \Int) \wedge ((\lnot\Int,\textsf{Any}) \to 0))$ \\\hline \end{tabular} } ... ...
 ... ... @@ -227,37 +227,36 @@ of the example is to show that indeed, the function is ill-typed {\definecolor{lightgray}{gray}{.8} \color{lightgray}OLD VERSION %% {\definecolor{lightgray}{gray}{.8} %% \color{lightgray}OLD VERSION The original Example~14 could be written in our syntax as: \begin{alltt}\color{darkblue} let example14_orig = fun (input : Int | String) -> fun (extra : (Any, Any)) -> if (input, is_int (fst extra)) is (Int, True) then add input (fst extra) else if is_int (fst extra) is True then add (strlen input) (fst extra) else 0 \end{alltt} Notice, in the version above the absence of an occurrence of \texttt{input} in the second \texttt{if} statement. Indeed, if the first test fails, it is either because \texttt{is\_int (fst extra)} is not \texttt{True} (i.e., if \texttt{fst extra} is not an integer) or because \texttt{input} is not an integer. Therefore, in our setting, the type information propagated to the second test is : $\texttt{(input, is\_int (fst extra))} \in \lnot (\Int, \True)$, that is $\texttt{(input, is\_int (fst extra))} \in (\lnot\Int, \True)\lor(\Int, \False)$. Therefore, the type deduced for \texttt{input} in the second branch is $(\String\lor\Int) \land (\lnot\Int \lor \Int) = \String\lor\Int$ which is not precise enough. By adding an occurrence of \texttt{input} in our \texttt{example14\_alt}, we can further restrict its type typecheck the function. Lifting this limitation through a control-flow analysis is part of our future work. } %% The original Example~14 %% could be written in our syntax as: %% \begin{alltt}\color{darkblue} %% let example14_orig = fun (input : Int | String) -> %% fun (extra : (Any, Any)) -> %% if (input, is_int (fst extra)) is (Int, True) then %% add input (fst extra) %% else if is_int (fst extra) is True then %% add (strlen input) (fst extra) %% else 0 %% \end{alltt} %% Notice, in the version above the absence of an occurrence of \texttt{input} in %% the second \texttt{if} statement. Indeed, if the first test fails, it is either %% because \texttt{is\_int (fst extra)} is not \texttt{True} (i.e., if %% \texttt{fst extra} is not an integer) or because \texttt{input} is not an %% integer. Therefore, in our setting, the type information propagated to the %% second test is : $\texttt{(input, is\_int (fst extra))} \in \lnot (\Int, %% \True)$, that is $\texttt{(input, is\_int (fst extra))} \in (\lnot\Int, %% \True)\lor(\Int, \False)$. Therefore, the type deduced for \texttt{input} in the second %% branch is $(\String\lor\Int) \land (\lnot\Int \lor \Int) = %% \String\lor\Int$ which is not precise enough. By adding an occurrence of %% \texttt{input} in our \texttt{example14\_alt}, we can further restrict its type %% typecheck the function. Lifting this limitation through a control-flow analysis %% is part of our future work. %% } The original Example~14 could be written in our syntax as: The original Example~14 of~\citet{THF10} can be written in our syntax as: \begin{alltt}\color{darkblue} let example14 = fun (input : Int|String) -> fun (extra : (Any, Any)) -> ... ... @@ -268,8 +267,9 @@ could be written in our syntax as: else 0 \end{alltt} where \code{and2\_} is the uncurried version of the \code{and\_} function in \eqref{and+}. Our system rejects this expression while the system in~\cite{THF10} function we defined in \eqref{and+} and \code{is\_int} is the fuction defined in the third row of Table~\ref{tab:implem}. Our system rejects the expression above, while the system in~\cite{THF10} correctly infers the the function always return an integer. The reason why our system rejects it is because the type it deduces for the occurrence of \code{input} in the 6th line of the code ... ... @@ -291,12 +291,11 @@ is $\code{(input, is\_int(fst\,extra))} \in whether \code{is\_int(fst\,extra)} holds or not, then we could deduce that the following occurrence of \code{input} is of type$\lnot\Int$. But since \code{input} does not occur in the test, this is not done. Instead, the type deduced refinement of the type of \code{input} is not done. Instead, the type deduced for \code{input} in the second branch is$(\String\lor\Int) \land (\lnot\Int \lor \Int) = \String\lor\Int$which is not precise enough to type the application \code{strlen\;input}. Although unsatisfactory, it not difficult to patch this example in our system: it suffices to test enough to type the application \code{strlen\;input}. It not difficult to patch, alas unsatisfactorly, this example in our system: it suffices to test dummily in the second \code{if} the whole argument of \code{and2\_}, without really checking its first component: \begin{alltt}\color{darkblue} ... ... @@ -309,10 +308,10 @@ without really checking its first component: else 0 \end{alltt} Even if the type of \code{is\_int\,input} is not really tested (any result will have the same effect) its presence in the test triggers the result will produce the same effect) its presence in the test triggers the refinement of the type of the last occurrence of \code{input}, which type checks with the (quite precise) type shown in the entry 14 of Table~\ref{tab:implem2}. Table~\ref{tab:implem2}, type that is equivalent to$\Int\vee\String \to ((\Int,\textsf{Any}) \to \Int) \wedge ((\lnot\Int,\textsf{Any}) \to 0)\$. Lifting this limitation through a control-flow analysis is part of our future work. ... ...
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!