\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 | ;| ou | = ;| \item une assignation est de la forme | = dans | L'affichage d'une expression à l'écran à l'aide de \\ |afficher (, ...);| Finalement, les boucle |for| sont semblables à celle en python avec comme syntaxe \\ | dans 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}