Résolution des noms : Pourquoi les scope graphs changent la donne pour les outils dev modernes

Votre IDE devine en un clin d'œil ce que désigne myVariable dans console.log(myVariable). Il le colore, vérifie les fautes de frappe. De la magie ? Non. C'est la name resolution à l'œuvre. Et c'est le point le moins standardisé en conception de langages.

Le casse-tête du name binding

On sait décrire la syntaxe avec des grammaires sans ambiguïté. Mais pour lier un nom à sa déclaration ? Aucune norme universelle.

Dans votre code :

• Une variable masque celle d'un scope parent.
• Un import rend accessibles des noms externes.
• Les types imposent des règles supplémentaires.
• Chaque langage gère ça à sa sauce.

Résultat : compilateurs, linters et interpréteurs codent tout différemment. Pas de langage commun pour en parler.

Les scope graphs à la rescousse

Les scope graphs résolvent ça. Un cadre mathématique et visuel, indépendant des langages.

L'idée clé : modéliser les faits de name binding avec quatre briques :

• Declarations : où un nom naît (var x = 5, function foo()).
• References : où on l'utilise (console.log(x)).
• Scopes : zones qui définissent un contexte de noms.
• Edges : liens entre scopes (parent-enfant, imports...).

La résolution ? Une recherche dans le graphe : de la référence à la déclaration.

Exemple concret

Prenez ce JavaScript :

const greeting = "Hello";

function greet(name) {
  const greeting = "Hi"; // masque le greeting extérieur
  console.log(greeting + " " + name);
}

greet("World");

Le scope graph montre :

1. Scope global avec le premier greeting.
2. Scope de fonction avec le second greeting.
3. La référence dans console.log pointe sur le inner (shadowing).

Précis. Réutilisable par n'importe quel outil.

Plus que des schémas

Les scope graphs ne s'arrêtent pas au dessin. Ils boostent les outils :

Outils multi-langages : Un calcul de résolution universel. Paramétrez les règles du graphe, et ça marche pour tout langage. Type checking incrémental ? Compilation parallèle ? IDE ? Une seule implémentation suffit.

Mises à jour live : L'IDE recalcule seulement les changements. Pas tout le projet.

Sécurité parallèle : Les "scope states" évitent les bugs en multi-thread.

Optimisation interpréteurs : Modèles mémoire dérivés directement. Correct et rapide.

Spoofax en action

Spoofax, un workbench pour langages, l'applique. Déclarez vos règles de binding. Spoofax génère IDE et interpréteurs. Parfait pour un DSL interne.

À quoi ça vous sert ?

Si vous codez des apps web classiques, c'est abstrait. Mais si vous êtes :

• Designer de langages ou DSL.
• Développeur IDE pour autocomplétion/refactoring.
• Auteur d'outils (linters, formatters).
• Ingénieur compilateurs pour du type checking optimisé.
• Créateur DevTools pour du debug avancé.

Les scope graphs structurent le chaos du name binding.

Vision d'ensemble

Ça dépasse les papiers académiques. Aujourd'hui, on crée des langages spécialisés : DSL config, query languages, scripts custom.

Pour la name resolution, choisissez : bidouilles dispersées ou cadre solide comme les scope graphs. Le premier est rapide au début. Le second grandit avec vos projets.

La communauté PLT a peaufiné ça des années. Les scope graphs, c'est la best practice actuelle. Comprenez-les pour mieux utiliser vos outils quotidiens.

Pour des outils web au top, maîtrisez les bases des langages. La name resolution forge des API solides, des modules clairs et du code durable.