Dernieres modifs

This commit is contained in:
Mysaa 2022-06-24 20:53:37 +02:00
parent 51670b501d
commit c91bc559b9
Signed by: Mysaa
GPG Key ID: 7054D5D6A90F084F

View File

@ -30,6 +30,7 @@
\newcommand{\bigO}{\mathcal{O}}
\newcommand{\longdash}{\:\textrm{---}\:}
\newcommand{\methprec}[1]{\prec\mkern-8mu\left[\fj{#1}\right]}
\newcommand\hole{\left[\raisebox{-0.25ex}{\scalebox{1.2}{$\cdot$}}\right]}
@ -50,6 +51,7 @@
\newtheorem{theorem}{Théorème}
\newtheorem{definition}{Definition}
\newtheorem{property}{Propriété}
\tcbuselibrary{fitting}
@ -92,7 +94,7 @@
identifierstyle=\idstyle,
mathescape=true
}
\newcommand{\fj}[1]{\text{\lstinline[language=FeatherweightJava,mathescape=true]|#1|}}
\newcommand{\fj}[1]{\text{\textnormal{\lstinline[language=FeatherweightJava,mathescape=true]|#1|}}}
\newcounter{fjargcount}
\newcommand{\fjparamattributes}[2][Object]{
@ -972,7 +974,155 @@
On pourrait vouloir palier ce problème en comparant les méthodes sur les valeurs «infinies» qu'elles produisent, mais de la même façon, les \textit{class tables} ne sont alors jamais équivalentes sous l'angle de \fj{Static.get}, mais elles sont parfois équivalentes (comme sous $TI_1$).
L'exemple $TI_2$ et $TI_2'$ nous indique qu'on ne peut pas se contenter de comparer les valeurs de sortie sur les fields laissés apparents par la test interface.
\subsection{Encore quelques critiques sur la définition de l'équivalence de classes}
Je vais encore apporter une critique à la définition de l'équivalence de classes avec les Test Interfaces. Ce ne sont pas ces dernières le problème, mais plutôt la définition du préordre qui en suit. En effet, cette définition «teste» les class table sur toutes les valeurs possibles, et y impose donc des contraintes. Ainsi, deux objets au nom de classes différent seront nécessairement distincts.
En effet, les deux class tables données \textsc{Figure \ref{classeq:ex}} ne sont pas équivalentes pour la \textit{test interface} donnée (l'expression \fj{new Static().true()}) premet de les distinguer, car \fj{new Bool()} est différent de \fj{new Other()}.
Cependant, on pourrait souhaiter que ces classes soient équivalentes, en effet, le nom de la classe est la seule chose qui permet de les différencier car la classe \fj{Bool} de la première class table est en tout point similaire à la classe \fj{Other} de la seconde ! Un programme qui utiliserai la librairie n'aurait jamais à utiliser le nom de la classe du programme et ne saurait distinguer la valeur renvoyée par \fj{Static.true} dans la première class table et dans la seconde.
\begin{figure}
\begin{multicols}{2}
\begin{fjlisting}
\fjclass{Static}{}{
\method{Bool}{true}{}{new Bool()}
\method{Bool}{false}{}{new Other()}
}
\fjclass{Bool}{}{
\method{Object}{ite}{Object t, Object f}{return t}
}
\fjclass[Bool]{Other}{}{
\method{Object}{ite}{Object t, Object f}{return f}
}
\end{fjlisting}
\columnbreak
\begin{fjlisting}
\fjclass{Static}{}{
\method{Bool}{true}{}{new Other()}
\method{Bool}{false}{}{new Bool()}
}
\fjclass{Bool}{}{
\method{Object}{ite}{Object t, Object f}{return f}
}
\fjclass[Bool]{Other}{}{
\method{Object}{ite}{Object t, Object f}{return t}
}
\end{fjlisting}
\end{multicols}
\begin{fjlisting}
Static()
Static: Bool true()
Static: Bool false()
Bool \{\}
Bool: Object ite(Object,Object)
\end{fjlisting}
\label{classeq:exmpl}
\caption{Deux classes que l'on aimerait équivalentes}
\end{figure}
Afin d'agrandir notre opérateur de préordre $\prec$, nous pouvons non plus comparer les \textit{class tables} sur toutes les valeurs, mais peut-être seulement sur celles \textbf{constructibles} dans la \textit{test interface}, plus celles \textbf{constructibles} par la class table de test.
\subsection{Renforcement du préordre sur les \textit{class tables}.}
On définit d'abort la grammaire des valeurs à trous. On peut la définir comme les expressions à trou, mais en enlevant toutes les règles n'étant pas \fj{new}. On les notera souvent par la lettre $\hbar$ Par exemple, \fj{new C([.],new S(new S([.],new G()),[.]))} est une valeur à trois trous. Les valeurs sont bien évidemment identifiées à des valeurs à zéro trous.
On définit alors le préordre sur deux programmes $(CT_1,e_1) \prec (CT_2,e_2)$ par
$$\forall \hbar \forall \overline{e'} \quad \left(e_1 \rightarrow_{CT_1}^* \hbar\left[\overline{e'}\right] \implies \exists \overline{e''}\quad e_2 \rightarrow_{CT_2}^* \hbar \left[\overline{e''}\right]\right)$$
On peut ainsi redéfinir la comparaison de deux class tables globalement ou sur une méthode:
$$CT_1 \prec CT_2 \iff \forall e \quad (e,CT_1)\prec(e,CT_2)$$
$$CT_1 \methprec{Class.meth} CT_2 \iff \forall \overline{p}\forall \overline{v} \quad (e,CT_1)\prec (e,CT_2) \text{} e=\fj{new Class(}\overline{p}\fj{).meth(}\overline{v}\fj{)}$$
\begin{property}
$$\forall \hbar \forall \overline{e} \quad \hbar\left[\overline{e}\right]\rightarrow e' \implies \exists \overline{e''}\quad e' = \hbar\left[\overline{e''}\right]$$
On peut prouver cette propriété inductivement en montrant qu'une expression ayant un nœud \fg\fj{new}\og{} en nœud racine se réduira forcément en une expression ayant un nœud racine du même type.
\end{property}
\begin{property}
$$CT_1\prec_{\text{new}}CT_2 \implies CT_1 \prec_{\text{old}}CT_2$$
Il s'agit d'une particularisation, puisque qu'une valeur est une valeur à trou sans trou.
\end{property}
\begin{property}[Context Lemma]
L'objectif de cette nouvelle définition était d'obtenir une sorte de \textit{context lemma}, puisque nous comparrons les expressions sur «toutes les valeurs qu'elles pourraient renvoyer».
\begin{gather*}
\forall CT \forall e_1,e_2\forall (h,CT_c)\\
(e_1,CT)\prec(e_2,CT) \implies (h[e_1],CT \oplus CT_c)\prec(h[e_2],CT \oplus CT_c)
\end{gather*}
\end{property}
Nous allons le montrer en deux temps. Commençons par décomposer l'opérateur $\prec$, et à changer l'ordre des opérateurs:
\begin{gather*}
\forall CT\forall e_1,e_2 \forall CT_c \\
\left(\forall \hbar\quad e_1 \rightarrow^* \hbar\left[\overline{e'}\right] \implies \exists \overline{e''}\quad e_2 \rightarrow^* \hbar\left[\overline{e''}\right]\right) \implies \\
\left(\forall h \forall \hbar \quad h\left[e_1\right] \rightarrow^* \hbar\left[\overline{e'}\right] \implies \exists \overline{e''}\quad h\left[e_2\right] \rightarrow^* \hbar\left[\overline{e''}\right]\right)
\end{gather*}
On va déjà montrer le théorème en ajoutant comme contrainte que la réduction $h\left[e_1\right] \rightarrow^* \hbar\left[\overline{e'}\right]$ s'effectue sans application de méthode (\textsc{R-Meth}) à un appel à méthode contenu dans $h$. (C'est à dire que les appels à méthode de $h$ ne «servent à rien», ils pourraient être remplacés par \fj{null} sans modifier la réduction).
Supposons alors $H_0:\quad \left(\forall \hbar\quad e_1 \rightarrow^* \hbar\left[\overline{e'}\right] \implies \exists \overline{e''}\quad e_2 \rightarrow^* \hbar\left[\overline{e''}\right]\right)$
Montrons ce résultat par \textbf{induction} sur $h$.
\paragraph{Premier cas: $\hbar = \hole$}
Alors on note $\overline{e''} = \left[e_2\right]$ et donc $e_2 \rightarrow^* e_2 = \hbar\left[\overline{e''}\right]$
\paragraph{Sinon} alors on a nécessairement $\hbar = \fj{new D(}\hbar_1,\hbar_2,\dots,\hbar_k\fj{)}$. On note alors $\hbar\left[\overline{e_1'}\right] = \fj{new C(}\hbar_i\left[\overline{e}^i\right]\fj{)}$
\underline{$h = \hole$}
On applique dirèctement $H_0$
\underline{$h = \fj{new D(}e_1,\dots,e_{i-1},h',e_{i+1},\dots,e_k'\fj{)}$}
Alors, \fj{D}=\fj{C} et $k'=k$ car $\fj{new D(...)} \rightarrow^* \fj{new C(...)}$
Aussi, on a pour chaque $i$, $e_1^i \rightarrow^* \hbar_i\left[\overline{e'}^i\right]$
Donc $h\left[e_2\right] = \fj{new C(}e_1^1,...,e_{i-1},h'\left[e_2\right],e_{i+1},...,e_1^k\fj{)}$
Donc $h\left[e_2\right]\rightarrow^*\fj{new C(}\hbar_1\left[\overline{e'}^1\right],\dots,h'\left[e_2\right],\dots,\hbar_k\left[\overline{e'}^k\right]\fj{)}$
Or, $h'\left[e_1\right] \rightarrow^*\hbar_i\left[\overline{e'}^i\right]$, qui n'utilise pas de réduction de méthode (car sinon, la réduction de $h\left[e_1\right]$ en utiliserai).
Donc, en appliquant l'hypotèse d'induction à $h'$, on obtient que $h'\left[e_2\right] \rightarrow^*\hbar_i\left[\overline{e''}\right].$
Donc $h\left[e_2\right] \rightarrow^* \fj{new C(}\hbar_1\left[\overline{e'}^1\right],\dots,\hbar_i\left[\overline{e''}\right],...,\hbar_k\left[\overline{e'}^k\right]\fj{)} = \hbar\left[\overline{e''}'\right]$
\underline{$h = h'\fj{.f}$}
Alors, $h'\left[e_1\right] \rightarrow^* \fj{new D(}e_1^1,\dots,e_1^{k'}\fj{)}$, et donc:
$$h\left[e_1\right] \rightarrow^* \fj{new D(}e_1^1,\dots,e_1^{k'}\fj{).f} \rightarrow e_1^i \rightarrow^* \hbar\left[\overline{e'}\right]$$
Donc $h'\left[e_1\right] \rightarrow^* \fj{new D(}e_1^1,\dots,e_1^{k'}\fj{)} \rightarrow^* \fj{new D(}e_1^1,\dots,\underbrace{\hbar\left[\overline{e'}\right]}_{\text{$i$ème pos}},\dots,e_1^{k'}\fj{)} = \hbar'\left[e_1^1,\dots,\overline{e'},\dots,e_1^{k'}\right]$
En appliquant l'hypotèse de récurrence à $h'$ et $\hbar'$, dont la réduction ne contient toujours pas d'appel à méthode (on observe une sous-réduction), on obtient $h\left[e_2\right] = h'\left[e_2\right]\fj{.f} \rightarrow^* \hbar'\left[\overline{e''}\right]\fj{.f}$
Donc $h\left[e_2\right] \rightarrow^* \hbar\left[\overline{e''}'\right]$
\underline{$h = h'\fj{.meth(}\overline{e}\fj{)}$ ou $h = e\fj{.meth(}\overline{e},h',\overline{e}\fj{)}$}
Ce cas est impossible, car alors, pour se résoudre en une expression de type \fj{new} (ici, $\hbar\left[\overline{e'}\right]$), il faudrait nécessairement un appel à méthode, ce qui n'est pas présent dans la réduction par hypothèse.
On a donc démontré le lemme pour tous les cas, il nous manque d'inclure les appels à méthode.
\paragraph{Mélange de réduction} Soient $h$ et $\hbar$ tels que $h\left[e_B\right] \rightarrow^*\hbar\left[\overline{e'}\right]$ sans autre contrainte. Alors, on peut changer l'ordre des étapes (voire en supprimer) afin d'obtenir une réduction
$$h\left[e_B\right] \rightarrow^*_{\text{\textsc{R-Meth}}} h'\left[e_1\right] \underbrace{\rightarrow^*}_{\text{sans appel à méthode dans $h'$}}\hbar\left[\overline{e'}\right]$$
\subsection{Tentative de limitation des class tables}
Nous allons dans cette section essayer de prouver le théorème avec plusieurs class tables en les empêchant d'utiliser des fields non présents dans la test interface.
%TODO here