
%PASTEX:FIGDIR=figs
\documentclass[12pt,a4paper]{article}

\usepackage[latin1]{inputenc} % 8 bits
\usepackage[francais]{babel}  % francais
\usepackage{graphics}
\usepackage{latexsym}
\usepackage{here}
\usepackage{color}

%\input{commandes}
%\input{algoenv}
%\input{save_paper}

\sloppy

\title{LPP-v6 -- Notes Développeur}
\author{P.Raymond}
\date{}

\begin{document}

\maketitle
\tableofcontents
%\clearpage

\section{Ligne de commande et analyse syntaxique}

\subsection{Fichiers acceptés}

Les fichiers supportés sont~:
\begin{itemize}
\item Les fichiers \verb|foo.lus| à la syntaxe Lustre-v6 comportant un ensemble
de déclarations de packages et de modules.
\item Les fichiers \verb|foo.lus| contenant uniquement un corps de
package à la syntaxe v6~;
un tel fichier est considéré comme la déclaration implicite d'un package
dont le nom est \verb|foo|, et dont tous les items sont exportés (\verb|provided|). 
\end{itemize}

Restrictions/à faire~:
\begin{itemize}
\item pour l'instant on prend un seul fichier, mais ça sera facilement adaptable
\end{itemize}

\subsection{Analyse syntaxique}

Elle produit un ensemble de déclarations de packages et de modèles
dans une structure syntaxique abstraite (module \verb|Syntaxe|),
qui constitue le {\bf source brut}.

\section{Analyse des déclarations}

C'est la première phase de compilation qui consiste à vérifier la cohérences
des déclaration modulo l'organisation en ``name-space'' (les packages).

Cette phase produit une nouvelle version du source (module \verb|SrcTab|)~:
\begin{itemize}
\item unicité des déclarations de modèles et de packages 
\item instanciation (purement syntaxique) des modèles
\item identification des items exportés et de leurs définitions
abstraites (e.g. un type fourni par un package est présenté abstrait
pour les utilisation extérieures).
\end{itemize} 

Au final on a une table de sources bien organisée (\verb|SrcTab|) mais
qui renvoie encore à des infos purement syntaxiques (\verb|Syntaxe|),
voir figure~\ref{srctab}~:
\begin{itemize}
\item les trois tables d'export (const, type, oper) sont indéxées
par des identificateurs absolus (pack+nom) et pointent sur 
des définitions éventuellement abstraites~: c'est la seule vision
qu'on en a de l'extérieur, et l'analyse doit être faite uniquement
modulo cette info.
\item la table des définitions de pack, chacun comportant 
ses tables d'items (const, type, oper)~; les idents sont relatifs
et les définitions concrêtes.
\end{itemize}

\begin{figure}
\begin{center}
\input{srctab.pdf_t}
\caption{La table des sources}
\label{srctab}
\end{center}
\end{figure}


\section{Compilation à la demande}

Une compilation modulaire, package par package, est pratiquement 
impossible~:
\begin{itemize}
\item comment générer du code pour des n\oe uds paramétrés ?
\item comment faire du type-checking générique pour des tableaux
dont on ne connaît pas la taille ?
\item et encore plus dur, comment traiter la récursivité statique ?
\end{itemize}

La solution la plus raisonable semble de faire une compilation à
la demande~:
\begin{itemize}
\item on part d'un n\oe ud principal à compiler, dont tous les éventuels
arguments statiques sont connus (en particulier la taille effective des tableaux
manipulés),
\item on ``tire'' récursivement sur les dépendances pour compiler tous
les items nécessaires à ce n\oe ud (ça comprend les types, les constantes statiques,
les n\oe uds internes utilisés).
\end{itemize}

\paragraph{Remarque.} Un point n'est pas très clair~:
est-il intéressant de faire malgrès tout une analyse préliminaire 
indépendante d'un main particulier~?

Dans Lpp4x, c'est ce qu'on appelait le ``typage de surface''~: 
ça vérifiait les références, et faisait un typage approché, où, en particulier,
la taille des  tableaux était abstraite.

\subsection{Items syntaxiques vers items effectifs}

C'est la terminologie hérité de Lpp4x~:  la compilation consiste
à associer à des items syntaxiques (types, consts, nodes) des
items effectifs (c'est-à-dire compilés).

\subsection{Compile Task}

Pour implémenter la compilation à la demande, on met en \oe uvre un mécanisme
de ``tâches de compilation''. Chaque tâche est identifiée parfaitement par~:
\begin{itemize}
\item l'item à traiter (type, const, n\oe ud),
\item le contextes (table de symboles) dans lequel on doit traiter.
\end{itemize}

Il faut bien différencier~:
\begin{itemize}
\item la recherche d'infos {\em utilisateur} pour un item,
\item la compilation effective de l'item.
\end{itemize}
Par exemple, la compilation d'un n\oe ud peut nécessiter des infos
sur un type dans le contexte de compilation de ce n\oe ud.
Supposons qu'il s'agisse d'un type importé d'un package (soit \verb|Pa::ty|)~:
\begin{itemize}
\item on cheche l'info accessible sur le type depuis le contexte actuel~;
supposons que le type soit laissé abstrait dans la table provides de \verb|Pa|,
la compilation du n\oe ud courant doit se faire avec cette seule info
(\verb|Pa::ty| est un type abstrait),
\item parallèlement, on stocke dans les tâches de compilation à effectuer la
compilation effective de \verb|Pa::ty|, dans le contexte du pack \verb|Pa|.
\end{itemize}



\end{document}
