compilation/rapport/rapport.tex

\documentclass{article}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[french]{babel}
\usepackage[pdftex]{graphicx}
\usepackage{amsmath, amsfonts, amssymb, amsthm}
\usepackage{fullpage}
\usepackage[inline]{enumitem}
\usepackage{hyperref}
\usepackage{fancyvrb}

\title{Rapport du projet de compilation \\ Umons 2024-2025}
\author{Debucquoy Anthony}

\DefineShortVerb{\|}

\begin{document}

\maketitle

\newpage

\tableofcontents

\newpage

\section*{Préface}

Ce document retrace le développement d'un compilateur de \textit{\textbf{S}imple \textbf{P}rogramme
en \textbf{F}rançais} (SPF) dans le cadre du projet de compilation de L'\textit{Université de Mons}.

Ce projet est supposé être réalisé en groupe. Mais lorsque les consignes du projet été données,
j'ai rapidement souhaité me faire une idée de son ampleur en tentant une première version.
En restant sur ma lancée je suis arrivé très rapidement à un résultat satisfaisant à mes yeux et
pratiquement fonctionnelle (non exempt de bugs évidement). J'ai alors fait la demande à \textit{Mr.
DECAN Alexandre} notre assistant et la personne référente du projet.
Celui-ci m'a confirmé que je pourrais accomplir ce projet par moi-même.

\section{Consigne}

Il nous est demandé de développer un interpréteur pour le langage \textbf{SPF}, un langage de
programmation \textit{faiblement et statiquement typé} dans lequel les instructions sont en
français.

Voici une liste semi-exhaustive de ce qui nous est demandé.

\begin{itemize}
	\item Les lignes commençant par le caractère |#| sont ignorés
	\item Les instruction se termine par le caractère |;|
	\item les types suivants doivent être implémentés:
		\begin{enumerate*}
		\item |entier| 
		\item |texte|
		\item |liste|
		\item |booléen|
		\end{enumerate*}
	\item une déclaration est de la forme |<type> <nom>;| ou |<type> <nom> = <expression>;|
	\item une assignation est de la forme |<nom> = <expression;|
	\item Les noms de variables peuvent contenir des accents
	\item Il est possible de créer une liste d'éléments consécutive avec |[a:b]| où a et b sont
		les bornes de la liste 
\end{itemize}

Le langage contient également de nombreux opérateurs qui ne sont pas tous présents dans ce document,
car ils sont similaires à la majorité des langages. Il est cependant à noter que les mots sont traduit
de l'anglais au français. Par exemple, |true| deviens |vrai| en SPF.
On remarque également que l'accès à la liste commence avec un indice de 1. Ainsi, l'accès au deuxième
élément de la liste l (|liste l = [a, b, c];|) devra être effectué à l'aide de l'expression
|l[2]| et retournera l'élément  |b|
L'ajout d'élément dans une liste se fait à l'aide de l'instruction\\
|ajouter <expression> dans <variable>|
L'affichage d'une expression à l'écran à l'aide de \\
|afficher <expression> (, <expression> ...);|
Finalement, les boucle |for| sont semblables à celle en python avec comme syntaxe \\
|<type> <variable> dans <expression> faire{...}|
On remarquera aussi que pour les variables initialisées dans les tests et boucles sont limités à leurs
portées.

\section{Grammaire}

% – Une description de la grammaire implémentée et des points sensibles
% la concernant;

J'ai tenté d'inclure un maximum d'éléments vu en cours dans la grammaire. Ça n'était pas le cas dans
un premier temps quand je tentais encore de voir l'étendue des capacités de la librairie et la grammaire a
donc été modifiée avec le temps. Je l'ai aussi réalisée bien avant que nous n'ayons vu tout le
contenu du cours. Je n'avais pas encore vu les grammaires LALR. Je pense malgré tout que
ça n'aurait pas changé grand chose à l'approche que j'ai actuellement.

Le programme est constitué d'instruction consécutive. La première ligne est donc naturellement.
\begin{Verbatim}[samepage=true, frame=single]
start: (instruction)*
\end{Verbatim}
où les instructions sont de la forme
\begin{Verbatim}[samepage=true, frame=single]
instruction: declaration ";"
           | assignation ";"
           | SHOW_KW expression ("," expression)* ";" -> afficher
           | ADD_KW expression "dans" VARIABLE ";" -> append
           | controls
\end{Verbatim}

Nous avons donc les 5 grandes catégories qui sont représentées par des instructions qui sont
terminées par un |;| (ou non dans le cas des instructions de contrôle)

Dans le but de respecter la consigne, le projet s'est déroulé avec l'option stricte activée tout le
long du développement. Ce qui m'a empêché de rédiger une grammaire ambigüe. Néanmoins, dans un
premier temps ma grammaire ne respectais pas du tout la priorité des opérateurs.
Après relecture du cours, j'ai pu ordonner mes opérateurs dans un tableau et ai réécrit ma grammaire
pour qu'elle soit non récursive gauche et que l'ordre des opérateurs soit respecté.

Pour lever la récursivité gauche, j'ai ajouté les analogues à chaque opérateur avec un u à la fin
(l'idée était d'avoir un \textbf{u} pour \textbf{u}nembiguoused mais par la suite je me suis rendu
compte que ce nom n'était pas très descriptif. Néanmoins, je ne l'ai pas changé par manque
d'imagination probablement.)

\begin{Verbatim}[samepage=true, frame=single]
logical: comparison logicalu?
logicalu: AND_OP logical
        | OR_OP logical
\end{Verbatim}

Le reste du fichier est relativement standard et facile à comprendre.

\section{Approche}

% – Une explication de votre approche pour gérer :
% ∗Les variables, leur déclaration, leur type et l’affichage via --trace;
% ∗Le test conditionnel de la forme si/sinon;
% ∗La boucle tant que;
% ∗La boucle pour chaque, incluant la gestion de la variable temporaire.

Ma première étape fut de prendre note de toutes les fonctions à implémenter dans le projet pour
pouvoir m'y référer au fur et à mesure (Figure~\ref{fig:notebook})

\begin{figure}[h]
	\centering
	\includegraphics[width=0.8\textwidth]{images/notebook.jpg}
	\caption{Note avant projet.}
	\label{fig:notebook}
\end{figure}

Je souhaitais faire un système séparé pour gérer les variables. Au lieu de l'inclure dans le même
fichier, il m'a semblé judicieux d'en faire un système indépendant. (|./modules/Variables.py|)
Ce module est pratiquement un simple dictionnaire où les clés sont les noms des variables et les
valeurs sont des dictionnaires eux même contenant le type en clé et la valeur en valeur. Ce système
permet de rapidement trouver une variable dans le dictionnaire tout en gardant les informations sur
son contenue.

Le fait d'en faire un module séparé permet de bien définir toutes les interactions possibles avec
celle-ci (set, get, define, ...) tout en laissant la possibilité d'inclure des fonctionnalités
dynamiques (trace, dump, ...). Ce fût l'un des premiers élément développé qui est resté opérationnel
le long du projet.

Par la suite je me suis demandé comment devrais-je gérer les \textit{scope}. En effet, une
variable crée dans une boucle ne devrait, par exemple par rester disponible après la portée de
celle-ci. Je n'avais pas envisagé ce scénario au début de mon implémentation et j'ai donc trouvé
comme solution de faire une copie de mes variables disponibles avant le début de ma boucle et de les
restituer après.

Pour les tests conditionnel dans les boucles et les branchements, j'ai pu profiter de la puissance
de lark. \`A l'aide de |self.visit_children(el)|, et par effet cascade, cette expression sera
évaluée a |vrai| ou |faux|. En fonction de sa valeur et ainsi m'appuyer sur celle-ci pour
demander à python de faire mes branchements. J'ai été agréablement surpris de constater que cette expression
peut être évaluée plusieurs fois. Ce qui implique que ça ne pose pas de problème pour les boucles
|tant que|. Il suffit de faire correspondre les valeurs au code python.

Pour la gestion d'erreurs, j'ai, dans un premier temps, implémenté toutes les erreurs demandées dans
un module séparé. Par la suite, comme ces erreurs sont des classes, j'ai implémenté une classe
parent qui permet un affichage uniforme à l'aide de la méthode |__str__| qui lit l'attribut |msg|
(le message à afficher) et |errorline| (le numéro de ligne). Il suffit alors d'appeler ces erreurs
lorsqu'elle se produise.

\section{Erreurs}

% – Une description brève des erreurs connues et des solutions envisagées;

Je n'ai pour, l'instant pas trouvé d'erreurs évidentes. Lorsque c'était le cas, je me suis empressé de
tenter de les corriger et pour l'instant ça n'a pas été trop compliqué au point que je ne le mette
de côté.

\section{Difficultés}

% – Une brève présentation des difficultés rencontrées et des solutions
% implémentées/envisagées;

Le projet s'est principalement passé sans difficultés particulières. J'ai passé un petit moment à
faire en sorte que ma grammaire soit sans ambigüité et que l'ordre des opérateurs soit correcte.

\section{Utilisation de l'IA}

Lorsque je travaille pour apprendre je ne souhaite en général pas utiliser d'IA dans le but de me
former mieux. Il m'arrive plus d'utiliser cet outil dans le but de me faciliter la tache pour un
travail fastidieux que je suis certains de savoir faire et dont je \textbf{peux} vérifier la fiabilité par
moi-même.

Ceci dis, lors de l'élaboration de ce projet, je me suis vu utiliser l'IA à un moment. J'ai tenté de
donner ma grammaire déjà écrite à chatgpt (modèle GPT-4o à travers \url{https://duck.ai/} ) en lui
demandant de me générer une série de programmes utilisant ce langage qui pourraient me servir de
test. L'objectif était d'avoir plus d'exemples de programmes que ceux données par la consigne.

Néanmoins, après très peu de temps je, me suis ravisé et ai simplement ignoré la réponse donnée, car les
propositions de programmes étaient bien trop simple et ne tentaient pas du tout de "piéger" mon
implémentation.

Pour être tout à fait transparent, c'est la seule et unique utilisation de l'IA que j'ai faite jusqu'à
maintenant, mais je compte utiliser LanguageTool à la fin de la rédaction de ce rapport pour m'aider
à corriger les éventuelles fautes commises dans ce document.

\section{Répartition du travail}

Comme précisé dans la préface de ce document, je me suis chargé de l'intégralité du projet. J'ai
commencé par me faire la main avec la librairie proposée (lark) par le tutoriel du parser json.
Ensuite le projet s'est très vite mis en place. Plusieurs révisions ont été nécessaires pour faire
correspondre le projet aux attentes, vous pouvez les consulter dans l'historique du repo git à
l'adresse \url{https://git.herisson.ovh/tonitch/compilation}

\end{document}