\section{Properties of the Algorithm} %TODO: how are the challenges solved: Describe this in the last chapter with examples! \section{Soundness}\label{sec:soundness} \section{Completeness}\label{sec:completeness} The algorithm can find a solution to every program which the Unify by Plümicke finds a correct solution aswell. It will not infer intermediat type like $\wctype{\rwildcard{X}}{Pair}{\rwildcard{X},\rwildcard{X}}$. There is propably some loss of completeness when capture constraints get deleted. This happens because constraints of the form $\tv{a} \lessdotCC \exptype{C}{\wtv{x}}$ are kept as long as possible. Here the variable $\tv{a}$ maybe could hold a wildcard type, but it gets resolved to a $\generics{\type{A} \triangleleft \type{N}}$. This combined with a constraint $\type{N} \lessdot \wtv{x}$ looses a possible solution. This is our result: \begin{verbatim} class List { void addTo(List l){ l.add(this.get()); } } \end{verbatim} $ \tv{l} \lessdotCC \exptype{List}{\wtv{y}}, \type{X} \lessdot \wtv{y} $ But the most general type would be: \begin{verbatim} class List { void addTo(List l){ l.add(this.get()); } } \end{verbatim} \subsection{Discussion Pair Example} \begin{verbatim} Pair make(List l){ ... } boolean compare(Pair p) { ... } List l; Pair p; compare(make(l)); // Valid compare(p); // Error \end{verbatim} Our type inference algorithm is not able to solve this example. When we convert this to \TamedFJ{} and generate constraints we end up with: \begin{lstlisting}[style=tamedfj] let m = let x = l in make(x) in compare(m) \end{lstlisting} \begin{constraintset}$ \wctype{\rwildcard{X}}{List}{\rwildcard{X}} \lessdot \ntv{x}, \ntv{x} \lessdotCC \exptype{List}{\wtv{a}} \exptype{Pair}{\wtv{a}, \wtv{a}} \lessdot \ntv{m}, %% TODO: Mark this constraint \ntv{m} \lessdotCC \exptype{Pair}{\wtv{b}, \wtv{b}} $\end{constraintset} $\ntv{x}$ will get the type $\wctype{\rwildcard{X}}{List}{\rwildcard{X}}$ and from the constraint $\wctype{\rwildcard{X}}{List}{\rwildcard{X}} \lessdot \exptype{List}{\wtv{a}}$ \unify{} deducts $\wtv{a} \doteq \rwildcard{X}$ leading to $\exptype{Pair}{\rwildcard{X}, \rwildcard{X}} \lessdot \ntv{m}$. Finding a supertype to $\exptype{Pair}{\rwildcard{X}, \rwildcard{X}}$ is the crucial part. The correct substition for $\ntv{m}$ would be $\wctype{\rwildcard{X}}{Pair}{\rwildcard{X}, \rwildcard{X}}$. But this leads to additional branching inside the \unify{} algorithm and increases runtime. %We refrain from using that type, because it is not denotable with Java syntax. %Types used for normal type placeholders should be expressable Java types. % They are not! The prefered way of dealing with this example in our opinion would be the addition of a multi-let statement to the syntax. \begin{lstlisting}[style=letfj] let x : (*@$\wctype{\rwildcard{X}}{List}{\rwildcard{X}}$@*) = l, m = make(x) in compare(make(x)) \end{lstlisting} We can make it work with a special rule in the \unify{}. But this will only help in this specific example and not generally solve the issue. A type $\exptype{Pair}{\rwildcard{X}, \rwildcard{X}}$ has atleast two immediate supertypes: $\wctype{\rwildcard{X}}{Pair}{\rwildcard{X}, \rwildcard{X}}$ and $\wctype{\rwildcard{X}, \rwildcard{Y}}{Pair}{\rwildcard{X}, \rwildcard{Y}}$. Imagine a type $\exptype{Triple}{\rwildcard{X},\rwildcard{X},\rwildcard{X}}$ already has % TODO: how many supertypes are there? %X.Triple <: X,Y.Triple <: %X,Y,Z.Triple % TODO example: \begin{lstlisting}[style=java] Triple sameL(List l) Triple sameP(Pair l) void triple(Triple tr){} Pair p ... List l ... make(t) { return t; } triple(make(sameP(p))); triple(make(sameL(l))); \end{lstlisting} \begin{constraintset} $ \exptype{Triple}{\rwildcard{X}, \rwildcard{X}, \rwildcard{X}} \lessdot \ntv{t}, \ntv{t} \lessdotCC \exptype{Triple}{\wtv{a}, \wtv{b}, \wtv{b}}, \\ (\textit{This constraint is added later: } \exptype{Triple}{\rwildcard{X}, \rwildcard{Y}, \rwildcard{Y}} \lessdot \ntv{t}) $ % Triple <. t % ( Triple <. t ) <- this constraint is added later % t <. Triple % t =. x.Triple \end{constraintset} \section{Conclusion and Further Work} % we solved the problems given in the introduction (see examples TODO give names to examples) The problems introduced in the openening \ref{challenges} can be solved via our \unify{} algorithm (see examples \ref{example1} and \ref{example2}). As you can see by the given examples our type inference algorithm can calculate type solutions for programs involving wildcards. Going further we try to proof soundness and completeness for \unify{}. % The tricks are: % \begin{itemize} % \item Erasing wildcards by setting $\type{U} \doteq \type{L}$ % \end{itemize} % Improvements: % \begin{itemize} % \item Straightforward algorithm. Less data types used. Only two sort of constraints. % \end{itemize} % \subsection{Problems} % The algorithm is lacking completeness. % \begin{verbatim} % void m(List a){} % m2(l){ % l.add("String"); % } % \end{verbatim} %COnstraints: %l <. List %String <. a