<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">
%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}
</pre></body></html>