stan/Ecoop2024_TIforWildFJ
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Recap

Browse Source
This commit is contained in:
Andreas Stadelmeier 2024-03-11 13:17:41 +01:00
parent 9daf5ce8ef
commit f6cb46af4a
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
introduction.tex
View File

@ -245,9 +245,15 @@ why do we need a lessdotCC constraint
\dbox{Eine dashbox!} \dbox{Eine dashbox!}
input is e.m(e); input is e.m(e);
\begin{recap}\textbf{TI for FGJ without Wildcards:} \begin{recap}\textbf{TI for FGJ without Wildcards:}
The type inference algorithm for Featherweight Generic Java \cite{TIforFGJ} (called \TFGJ{}) is complete and sound.
It is able to find a type solution for a Featherweight Generic Java program, which has no type annotations at all,
if there is any.
It's only restriction is that no polymorphic recursion is allowed.
\TFGJ{} generates subtype constraints $(\type{T} \lessdot \type{T})$ consisting of named types and type placeholders.
- usually the type of e must be subtypes of the method parameters - usually the type of e must be subtypes of the method parameters
- in case of a polymorphic method: type placeholders resemble type parameters - in case of a polymorphic method: type placeholders resemble type parameters
\end{recap} \end{recap}
Most
involving wildcards: involving wildcards:
- depending on the type of e a capture conversion must be applied first - depending on the type of e a capture conversion must be applied first
- the captured type N must be a subtype of the method parameters - the captured type N must be a subtype of the method parameters