\chapter{Name, scope and bindings}

\url{http://lrde.epita.fr/~akim/ccmp/lecture-notes/slides/ccmp/names.pdf}

\section{Bindings}

\subsection{Vocabulaire}

\paragraph{Nom/Name/Symbol~:} chaine de caractère, lisible par l'être humain
servant à placer des étiquettes sur quelque chose.

\paragraph{Référence~:} mécanisme permettant d'accéder à une case mémoire.\\

Donnée, quantitée, que l'on peut référencé par une référence ou une
adresse. Cela peut être une variable, pas vraiment un type, pas de fonction,
mais son code oui, pas de namespace.


\paragraph{Identifiant~:} généralement des caractères alphanumériques ou
l'underscore. Généralement, la première lettre est une minuscule et n'est pas
un chiffre qui serait un sel syntaxique. Il n'y a pas d'espaces, sauf en Algol
60 ou en FORTRAN.

Dans certain langage, il y a des limitations sur la taille des identifiants~:
le FORTRAN original était limité à des identifiants de 6 caractères.

Certains langages sont insensible à la case comme l'Ada.

\subsection{}

\paragraph{Durée de vie~:} Temps entre le moment où l'objet est créée et est
détruit. Lié à l'exécution.

Dans certain langage comme Pascal, cette notion est lié à la portée, mais
généralement, c'est différent.

\paragraph{Portée~:} lié au code source, pas vraiment à l'éxécution. L'endroit
où on peut dire qu'à un endroit particulier, tel nom est associé à telle
variable.

\subparagraph{Portée statique~:} quand cela peut être calulé à la
compilation. Dans la plupart des languages (\verb+my+ en Perl, C, Tiger,
Scheme, \ldots)

Cela permet d'effectuer un typage statique et autorise le typage fort.

C'est donc plus rapide, sûr et propre.


\subparagraph{Portée dynamique~:} lorsque cela dépend d'appels
de fonctions et autres.

Dans la plupart des langage de script (Perl \verb+local+, shell, \TeX (voir la
slide 14 pour un exemple de code \TeX~!))

Concrètement, on a un dictonnaire de variable référençant toutes les variables
déjà rencontrée.

\subparagraph{Utilité~:} modularité pour découper le code en morceaux.
Il n'y en a pas en assembleur.

Dans les systèmes de fichiers, cela correspond aux répertoires.

Lorsque l'on a pas de portée, les noms ont une influence globale, c'est assez
difficile à gérer, puisqu'il faurait alors des identifiants ayant des noms
uniques.\\

En interdisant la récurence, on peut se passer de pile d'appel.

\paragraph{Espaces de nom (!= namespaces)~:} par exemple, dans Tiger, on a 3
espaces de nom~: types, fonctions et variables.

En C, il y a deux espaces de noms~: un pour les types et un pour les fonctions
et les variables, car on peut avoir une variable qui est une fonction (pointeur
sur fonction).


\paragraph{Moments de liaison (Binding Time)~:} définit à quel moment une
certaine étape est réalisée.

Plus on fait la liaison tôt, moins le code est flexible, mais plus c'est
efficasse, mais à l'inverse plus on le fait tard, plus c'est réalisé tard, plus
c'est flexible, mais c'est moins efficasse.

Un bon compromis serait sans doute Java ou C\# grâce à l'utilisation de machine
virtuelle qui permet l'introspection ou la compilation à la volée.

Dans Tiger, on fait un certain nombre de liaison~:
\begin{itemize}
  \item Andrew Apple a définit les mots-clefs.
  \item Lorsque l'on programme, on définit les indentifiants
  \item À la compilation, on définit les types, le code des fonctions, \ldots
  \item À l'exécution, on lie les adresses des tableaux (appel à malloc), et
    aux records.
\end{itemize}
Tout ce qui est avant l'exécution est donc la partie statique, après, c'est la
partie dynamique.


\section{Table de symboles}

Cas simple sans portée~: avec tableau associatif~; implémentation très simple~:
\verb+put+ et \verb+get+.\\

Lorsque l'on ajoute la portée, on a besoin de fonctions ou méthodes
\verb+scope_begin ()+ et \verb+scope_end ()+. On pourrait utiliser
\verb+std::stack+, mais si l'on peut référencer un élément d'un autre scope, on
va avoir des problèmes car c'est compliqué de revenir dans les états
d'avant. Le contener \verb+std::slist+ est du coup plus adapté.
