
\newcommand\teamName{Spades}

\newcommand\CTintroduction{
Les langages de programmation modernes sont de plus en plus complexes,
et s’exécutent dans des environement de plus en plus divers.
%
L’utilisation de langages de script
(JavaScript, Python, R, \etc)
s’est ainsi imposée dans de nombreux domaines,
notamment en statistiques et sur le web,
mais aussi dans des \textbf{systèmes embarqués}~\cite{espruino, tessel, kinomajs}.
Le cas des systèmes embarqués est assez inattendu puisqu’un tel environement
est typiquement très contraint en ressources
(en particulier en temps d’exécution, en mémoire, et en énergie),
alors que les langages de script sont justement assez peu prédictifs dans ces domaines.
% On recense ainsi plus de deux millions d’utilisateurs de R,
% notamment dans tous les domaines % basés sur la
% statistiques (biologie, finance, \etc).
% De son côté, JavaScript est le premier langage sur GitHub,
% comptabilisant plus de 320~000 projets actifs~\cite{githut}.

Les langages de script se caractérisent par une
\textbf{sémantique complexe} composée de très nombreux comportements spéciaux.
Ces comportements spéciaux tendent à artificiellement produire un résultat
en cas d’erreur. % dans les cas où le programme comporte des erreurs,
% là où des compilateurs pour d’autres langages
% refuseraient la compilation.
Par exemple, en JavaScript, si une expression de la forme \texttt{x + y}
apparait dans un contexte où \texttt{x} et \texttt{y} sont des tableaux,
de nombreuses fonctions vont être appellées
(par exemple \texttt{Array.prototype.toString}).
Ces fonctions peuvent provoquer toutes sortes d’effets de bords
et sont redéfinissables à n’importe quel point du programme.
Il est probable que l’expression \texttt{x + y} dans un tel environnement
soit une erreur de programmation,
mais cette expression va bien retourner un résultat.
Ce résultat sera souvent faux,
mais pourrait par hasard ressembler au résultat attendu
et ainsi ne pas être détecté.
%
% Cela pose un vrai problème de \textbf{gestion des fautes}~:
% dans le contexte du web,
% une faute d’un programme distant peut se répercuter sur le programme client
% et provoquer un cas particulier qui n’avait pas été prévu.
% Ainsi, une faute sur un serveur peut provoquer un comportement inattendu côté client.

Pris à part, chacun de ces comportements spéciaux ne pose pas de problème fondamental.
Le problème est que les langages de script sont en général
composés de centaines de tels cas particuliers.
Ces comportements spéciaux étant souvent méconnus des développeurs~\cite{RInferno},
il y a un \textbf{besoin d’analyse} pour ces langages de programmation.
%
Mais
ces comportements spéciaux complexifient énormément l’analyse de programmes.
Il arrive qu’ils soient ignorés ou simplifiés par les analyseurs.
Malheureusement, ces hypothèses de recherche
% sur l’utilisation pratique de ces fonctionnalités
correspondent rarement aux usages pratiques~\cite{RichardsHBV11}.
%
Il y a donc un écart entre ce que l’on attend des analyseurs
et leur garanties réelles.

Pour contrer cela,
des modèles plus récents cherchent à couvrir la totalité du langage,
y compris ses comportements spéciaux.
C’est ainsi l’approche de JSCert~\cite{popl14jscert} et CoqR~\cite{bodin2018R}
(voir fiches~\hyperref[fiche:jscert]{1} et \hyperref[fiche:coqr]{2}),
mais aussi de nombreux autres travaux~\cite{memarian2016into, bogdanas2015k, CompCert}.
Ces modèles formels de langages se distinguent par leur grande taille.
Ainsi JSCert totalise plus de 900~règles de dérivation,
et CoqR l’équivalent de plus de 2~000.
%
Cette imposante quantité de règles est directement liée aux comportements spéciaux.
Cela a deux conséquences majeures.
% toutes deux liées au fait que la base de code de confiance
% (trusted code base) est mécaniquement plus importante.
%
D’une part, il est plus difficile de faire \emph{confiance} à ces formalisations,
ce qui nécessite des méthodologies particulières pour les valider.
Ces méthodologies sont tout le cœur de travail derrière JSCert et CoqR,
et l’assistant de preuve Coq y est fondamental
pour pouvoir transmettre cette confiance aux analyses dérivées.
%
D’autre part, utiliser ces formalisations en pratique demande un effort conséquent,
limitant très fortement les analyses possibles à partir de ces modèles.

La construction de telles analyses est donc complexe,
mais elles s’appliquent directement aux \textbf{systèmes réels}~:
ces modèles complexes correspondent précisément à des contextes industriels,
et non à une simplification de ces derniers.
Cela implique des contraintes de recherche très spécifiques.
En particulier, les analyses doivent \textbf{passer à l’échelle}
vis-à-vis de la complexité des langages de programmation,
et non plus seulement vis-à-vis de la taille des programmes analysés.

Les \textbf{sémantiques squelettiques} (voir fiche~\hyperref[fiche:skel]{3})
visent exactement à résoudre ce problème de passage à l’échelle
vis-à-vis de la complexité des sémantiques.
Ce formalisme propose en effet un cadre \emph{simple} dans lequel exprimer des sémantiques,
mais surtout des interprétations de ces dernières,
ainsi que leurs preuves de correction.
Ces interprétations peuvent ensuite servir comme base pour des analyses de programme.
% Ce formalisme est dependant nouveau.
Ce programme de recherche vise à développer ce formalisme,
en particulier en l’adaptant aux problématiques des systèmes embarqués~:
\begin{itemize}
  \item En développant les fondements théoriques des sémantiques squelettiques,
    notamment vis-à-vis des analyses de coûts (en mémoire, énergie, ou temps d’exécution),
  \item En travaillant à des compilations sous contraintes de sémantiques squelettiques,
  \item En appliquant le formalisme des sémantiques squelettiques à des cas d’analyse concrets.
\end{itemize}
}

\newcommand\CTprojet{
\subsection{Fondements théoriques des sémantiques squelettiques}

Comme indiqué dans la fiche~\hyperref[fiche:skel]{3},
un choix caractéristique des sémantiques squelettiques
est d’être simple. % le plus simple possible.
% quitte à ce qu’il soit plus difficile de les construire.
Ceci facilite grandement la construction générale d’interprétations,
et donc d’analyses.
Cependant, les sémantiques squelettiques n’ont pour l’instant été
associées qu’à un unique type d’analyses
(une sous-classe de l’interprétation abstraite),
et ce de manière assez théorique.
% mais rend la construction de sémantiques squelettiques plus complexe.
Ce premier axe consiste donc à développer ces analyses.
Les analyses présentées ci-dessous bénéficieront naturellement
d’informations plus précises sur les programmes,
et pourront donc parfois se compléter.
Les liens entre ces différentes analyses me semblent
donc aussi importants que les analyses elle-mêmes.

\FixTooMuchSpaceBeforeParagraph{}
\paragraph{Coûts en temps et énergie}
Les systèmes embarqués critiques ont de plus en plus besoin d’estimer les coûts d’exécution
des programmes exécutés.
% Cependant, ces systèmes sont aussi soumis à la tendance de l’augmentation de complexité
% des sémantiques ---
% des langages comme Java étant maintenant disponibles pour de très nombreux systèmes embarqués.
Spécifier des coûts concrets (en temps d’exécution ou en énergie) est tout à fait exprimable
sous la forme d’une interprétation pour sémantique squelettique,
par le biais d’une trace d’exécution.
Il est ensuite possible d’abstraire ces coûts concrets pour former des analyses.
Cependant,
les abstractions sur ces coûts~\cite{negi2003accurate, theiling2000fast, maroneze2014formally}
sont en général complexes.
J’aimerais formaliser des analyses de coût déjà existantes
dans le contexte des sémantiques squelettiques.
Cette voie me semble intéressante sur le long terme,
tant pour appliquer le formalisme des sémantiques squelettiques dans un nouveau contexte
que pour offrir de nouveaux outils d’analyse de programmes.

\FixTooMuchSpaceBeforeParagraph{}
\paragraph{Logique de séparation}
La logique de séparation~\cite{ishtiaq2001bi, berdine2005smallfoot}
a montré pouvoir raisonner efficacement sur des structures complexes
et représente ainsi un objectif important pour la formalisation d’analyses.
Cette logique a de plus été récemment généralisée par Iris~\cite{jung2017iris},
qui est rapidement devenue une référence.
Iris est formalisée en Coq,
mais sa partie sémantique n’a pas été conçue pour des langages complexes~:
le langage le plus complexe formalisé dans Iris
est à ma connaissance RustBelt~\cite{jung2017rustbelt}
et ne contient que 30~règles de dérivations (à comparer aux 900 règles de JSCert).
Les sémantiques squelettiques pourraient fournir à moyen terme
un cadre formel intéressant pour la partie sémantique d’Iris,
permettant de passer à l’échelle sur des langages de programmation complexes.

\FixTooMuchSpaceBeforeParagraph{}
\paragraph{Hyperpropriétés de programme}
J’ai participé à des travaux préliminaires sur le déterminisme des sémantiques squelettiques.
Le déterminisme est une propriété très différente de l’interprétation abstraite~:
là où l’interprétation abstraite cherche à trouver ce que toutes les branches ont en commun,
le déterminisme pousse au contraire à trouver des différences entre branches
(notamment dans leurs hypothèses).
Malgré ces différences, j’ai trouvé des solutions pour construire
une interprétation de sémantiques squelettiques
exprimant une version forte du déterminisme.
Cela semble indiquer que cette direction de recherche est intéressante,
bien qu’orthogonale aux autres analyses.
À plus long terme,
le déterminisme se généralise aux hyperpropriétés de programmes~\cite{clarkson2010hyperproperties},
qui visent à comparer différentes exécutions possibles d’un même programme.
C’est une classe de propriétés assez large, qui inclut par exemple la non-interférence,
l’exécution en temps ou énergie constante,
mais aussi certains types de correction fonctionnelle de programme,
comme la symétrie ou l’associativité de certaines fonctions.

\subsection{Compilation de sémantiques squelettiques}

La compilation s’exprime assez facilement dans le formalisme des sémantiques squelettiques~:
une interprétation squeletique peut prendre la forme de n’importe quel objet mathématique,
et rien ne l’interdit d’être elle-même une représentation
de la sémantique dans un autre formalisme,
ou même d’être un compilateur pour le langage formalisé.
J’ai déjà conçu un prototype d’un tel compilateur vers le langage While
exprimé sous la forme d’une interprétation squelettique.
Cet axe consiste à explorer les compilations de sémantiques squelettiques
vers différents formats et sous différentes contraintes.

% La simplicité des sémantiques squelettiques
% simplifie leur compilation vers différents formalismes~:
% elle permet en effet de se concentrer sur la structure principale
% et non sur les cas particuliers.
% %
% Ceci autorise la prise en compte de nombreuses contraintes
% lors de la compilation
% tout en passant à l’échelle vis-à-vis de la complexité
% de la sémantique du langage considéré.

\FixTooMuchSpaceBeforeParagraph{}
\paragraph{Langages intermédiaires}
De nombreux projets d’analyses~\cite{besson2010certified, fragoso2017javert}
se concentrent sur des langages intermédiaires.
Ces langages intermédiaires ont une sémantique beaucoup plus
simple que le langage d’origine, ce qui simplifie les analyses.
%
Certains de ces langages intermédiaires sont génériques~\cite{gillian},
et partagent ainsi beaucoup de similarités avec les sémantiques squelettiques.
% De même qu’il est possible de construire une interprétation d’une sémantique squelettique
% vers un autre formalisme,
% il est aussi possible de concevoir une interprétation
% produisant un compilateur,
% et en particulier un compilateur vers un de ces langages intermédiaires génériques.
Il semble naturel de construire une interprétation squelettique
construisant des compilateurs vers ces langages génériques,
puis vérifier la correction de ces compilateurs à l’aide des
outils de preuve fournis par les sémantiques squelettiques.
Un tel compilateur permettra de comparer voire lier des analyses provenant d’autres travaux,
évitant l’isolation de ces différents travaux.


\FixTooMuchSpaceBeforeParagraph{}
\paragraph{Le formalisme~\(\mathbb{K}\)~\cite{rosu-serbanuta-2010-jlap}}
Ce formalisme a pris beaucoup d’importance
grâce à plusieurs formalisations ambitieuses~\cite{kjs, bogdanas2015k}.
Cependant, \(\mathbb{K}\) étant lui-même assez complexe~\cite{li2018isak},
il est difficile de réutiliser ces sémantiques dans d’autres contextes
que ceux prévus par les outils associés.
%
Au contraire, la simplicité des sémantiques squelettiques
simplifie leur analyse,
mais aussi leur compilation.
%
En particulier, il est envisageable de compiler des sémantiques squelettiques
vers~\(\mathbb{K}\).
Ceci permettrait de faire un lien direct entre les deux formalismes
et leurs analyses respectives.
% évitant leurs isolements respectifs.

Réciproquement, il me semble intéressant de pouvoir compiler
(un sous-ensemble de) \(\mathbb{K}\) vers les sémantiques squelettiques.
Les sémantiques squelettiques permettant de contrôler précisément leur degré d’abstraction,
il me semble fondamental qu’une telle compilation puisse aussi abstraire des parties
de la sémantique compilée.
Par exemple, la formalisation KJS~\cite{kjs} de JavaScript en~\(\mathbb{K}\)
spécifie complètement les nombres flottants, comme il est d’usage en~\(\mathbb{K}\).
Dans les sémantiques squelettiques, il est au contraire courant d’abstraire les flottants,
de façon à pouvoir implémenter des versions concrètes et abstraites adaptées de leurs opérations.
Ce choix de degré d’abstraction dans un tel compilateur vers~\(\mathbb{K}\)
me parait important et peut amener à des développements intéressants.

\FixTooMuchSpaceBeforeParagraph{}
\paragraph{Compilation à coûts prédictifs}
Les systèmes embarqués sont souvent soumis à des contraintes fortes en termes de coûts
(en mémoire, énergie, ou temps d’exécution).
Il est donc important que les programmes s’exécutant sur ces derniers soient associés
à des coûts prédictifs.
De tels compilateurs existent déjà~\cite{andalam2010predictable},
mais ils sont associés à un langage source particulier,
souvent bas-niveau.
Les généraliser dans le cadre des sémantiques squelettiques permettrait
de construire un compilateur général prenant en compte ces coûts,
y compris pour des langages complexes tels JavaScript.
% (tant qu’il sera fournit une sémantique squelettique).
Un tel compilateur pourra être relié avec les analyses en coûts et en énergie
proposés dans le premier axe~:
une telle preuve semble en effet s’inscrire dans le mécanisme de preuve
de cohérence d’interprétations squelettiques.

\FixTooMuchSpaceBeforeParagraph{}
\paragraph{Compilation générale}
Les langages cibles des différents compilateurs décrits ci-dessus
ont en général une sémantique assez simple.
Il est ainsi envisageable de construire une sémantique squelettique pour ces langages.
%
Compiler une sémantique squelettique vers cet autre langage,
puis composer la sémantique squelettique associée à ce même langage
permettrait de produire une nouvelle sémantique squelettique très différente
de la sémantique initiale.
On a donc une transformation de sémantiques squelettiques % vers sémantique squelettique
qui modifie complètement leur structure.
%
Les sémantiques squelettiques ayant été conçues pour faciliter les preuves,
cela semble indiquer qu’il existe un moyen d’exprimer dans le cas général
le comportement d’un compilateur,
sans sortir du formalisme des sémantiques squelettiques.
Un tel résultat permettrait sur le long terme de guider la preuve d’un compilateur,
y compris pour des langages à la sémantique complexe.
%
À plus court terme, les transformations de sémantiques squelettiques
peuvent s’avérer utiles~:
j’ai déjà mis en avant des règles de réécriture sur ces sémantiques
qui ne modifient pas la sémantique concrète,
mais améliorent la précision de la sémantique abstraite.
%
Une étude approfondie de telles règles de réécriture apporterait
de nouveaux outils théoriques au formalisme.

% \FixTooMuchSpaceBeforeParagraph{}
% \paragraph{Interpréteurs monadiques}
% Les projets JSCert et CoqR ont tout deux un interpréteur monadique.
% Dans le cadre du projet JSExplain~\cite{chargueraud2018jsexplain},
% il a été montré qu’un tel interpréteur
% peut être reformulé de plusieurs manières différentes mais équivalentes.
% J’aimerais donc construire un compilateur de tels interpréteurs monadiques
% vers des sémantiques squelettiques, à la manière de JSExplain.
% Ce projet conduira ainsi à moyen terme à une sémantique squelettique
% correspondant à JSCert et CoqR,
% ce qui permettra à plus long terme d’appliquer les résultats
% de l’article original~\cite{bodin2019skeletal}
% (notamment sur l’interprétation abstraite)
% à des langages complexes comme R.
% Il n’existe actuellement quasiment pas d’analyseur
% pour~R~\cite{RInferno} malgré son usage important~:
% un tel projet aura donc mécaniquement des retombées directes sur l’industrie.


\subsection{Application des sémantiques squelettiques}

Les sémantiques squelettiques étant assez jeunes,
elles sont restées pour l’instant assez théoriques.
J’aimerais appliquer ce formalisme dans des cas concrets.
Ces cas d’applications permettront d’évaluer mes travaux dans des systèmes réels.

\FixTooMuchSpaceBeforeParagraph{}
\paragraph{WebAssembly}
Je travaille actuellement à une formalisation en Coq
de WebAssembly~\cite{watt2018mechanising}.
Je souhaite que cette formalisation soit entre autres
exprimée sous la forme d’une sémantique squelettique.
WebAssembly est en effet assez différent
des langages considérés jusque là pour les sémantiques squelettiques,
étant basé sur une machine à pile.
WebAssembly est de plus un langage à la complexité assez faible,
ce qui facilite l’expérimentation.
Ceci permettra de tester l’expressivité des sémantiques squelettiques
dans un cadre différent, et donc d’évaluer la pertinence de ces dernières.

\FixTooMuchSpaceBeforeParagraph{}
\paragraph{Interpréteurs monadiques}
Les projets JSCert et CoqR ont tout deux un interpréteur monadique.
Dans le cadre du projet JSExplain~\cite{chargueraud2018jsexplain},
il a été montré qu’un tel interpréteur
peut être reformulé de plusieurs manières différentes mais équivalentes.
J’aimerais donc construire un compilateur de tels interpréteurs monadiques
vers des sémantiques squelettiques, à la manière de JSExplain.
Ce projet conduira ainsi à moyen terme à une sémantique squelettique
correspondant à JSCert et CoqR,
ce qui permettra à plus long terme d’appliquer les résultats
de l’article original~\cite{bodin2019skeletal}
(notamment sur l’interprétation abstraite)
à des langages complexes comme R.

\FixTooMuchSpaceBeforeParagraph{}
\paragraph{Systèmes temps-réels}
Toujours afin de tester l’expressivité des sémantiques squelettiques,
je compte formaliser un langage synchrone,
par exemple Lustre,
dans le cadre des sémantiques squelettiques.
Un tel projet de formalisation pourra se faire
en se basant sur un interpréteur monadique.
L’analyse de programmes synchrones étant très différente
de l’analyse de programmes plus classiques,
cette direction de recherche aboutira naturellement à des analyses spécifiques
pour les sémantiques squelettiques de tels langages.
En particulier,
la compilation d’un langage synchrone vient avec beaucoup de contraintes
en terme de temps d’exécution~:
cette direction de recherche pourra servir de cas d’application
pour la compilation de sémantiques squelettiques sous contraintes.
}

\newcommand\CTintegration{
  Je pense que les sémantiques squeletiques,
  de part leur capacité à formaliser des langages très complexes
  tout en assurant une grande capacité d’analyse,
  fournissent une approche différente de la conception de langages de programmation.
  Je pense en particulier qu’il est possible de les utiliser
  pour concevoir des langages de programmation exprimant
  \emph{conjointement} la sémantique et le temps d’exécution des programmes,
  ce qui est un des objectifs de l’équipe Spades.

  L’étude des coûts en temps et en énergie~\cite{andalam:hal-00842368, wang:hal-01412100}
  est un des thèmes de recherche de l’équipe qui m’intéresse beaucoup.
  En particulier, l’expertise d’Alain Girault~\cite{andalam2010predictable}
  en compilation sous contraintes
  sera très précieuse pour construire des compilations squeletiques à coûts prédictifs.
  Les analyses génériques de temps d’exécution
  de Pascal Fradet et Sophie Quinton~\cite{fradet2018generic}
  m’intéressent aussi,
  et il me semble intéressant de lier ses formalisations Coq
  avec celle des sémantiques squeletiques.

  J’apporte enfin à l’équipe mon expertise Coq,
  qui vient compléter l’expertise locale.
}

