Machines d'état d'évaluation

Statut documentaire : architecture — voir Maturité et preuves.

Le moteur FPLN utilise une architecture de machines d'état pour piloter l'évaluation des expressions.

Table d'exécution

Conceptuellement, le moteur résout une fonction d'évaluation à partir de deux coordonnées :

(expression type, evaluation state) -> evaluation function

Une expression peut donc être reprise à un état différent après l'évaluation d'une dépendance.

Environnements dynamique et local

Le moteur possède deux plages de stratégies correspondantes aux environnements d'évaluation dynamique et local. Une famille d'expressions peut partager le même protocole entre les deux modes ou enregistrer des comportements distincts.

Cette propriété est importante pour comprendre pourquoi l'évaluation ne se réduit pas à un simple visiteur récursif de l'AST.

Protocoles spécialisés

Le moteur prévoit plusieurs formes d'enregistrement :

• pré/post-évaluation pour les expressions simples à deux phases ;
• application avec phases supplémentaires pour l'appel fonctionnel ;
• push-down automaton pour les formes nécessitant une troisième étape structurée ;
• pattern matching avec états explicitement indexés ;
• automate générique pour les familles ayant leur propre séquence d'états.

Piles et contexte

L'évaluation s'appuie sur un contexte qui transporte notamment :

• une pile d'exécution ;
• une pile de données ;
• l'environnement courant ;
• le graphe conceptuel disponible ;
• le processus courant lorsqu'il existe ;
• les informations d'erreur et de diagnostic.

L'état de l'automate et les piles forment ensemble le protocole de reprise.

Pourquoi cette architecture est utile

Elle facilite :

1. la composition d'expressions de paradigmes différents ;
2. l'évaluation différée ;
3. l'application partielle ;
4. les opérations structurées sur collections ;
5. le pattern matching ;
6. le diagnostic précis d'une évaluation en cours ;
7. l'évolution du moteur sans transformer chaque nouvelle expression en cas spécial global.

Frontière publique

Les mécanismes décrits ici sont des invariants architecturaux. Les identifiants des classes, tableaux et fonctions internes peuvent évoluer et ne doivent pas être utilisés par une application.