Au septième jour de l'audit exhaustif, nous avions atteint les fonctions intégrées. La spécification de FLIN promet des centaines de fonctions natives -- manipulation de chaînes, opérations mathématiques, prédicats de dates, transformations de listes, vérification de types, validation, formatage et encodage. La question n'était pas de savoir si ces fonctions existaient dans le code Rust. La question était de savoir si elles étaient accessibles depuis l'endroit où les développeurs FLIN en ont réellement besoin : à l'intérieur des templates.
Le problème d'accessibilité des templates
L'analyse des lacunes a révélé une asymétrie frappante. Au niveau du bytecode, FLIN avait implémenté environ 95 % de ses fonctions spécifiées -- 350+ opérations natives prêtes à être exécutées. Mais au niveau des templates, où les développeurs écrivent leur logique UI, seules 17 fonctions étaient accessibles -- environ 12 % de ce qui était disponible.
Le modèle d'exécution de FLIN a deux contextes. Dans le contexte bytecode, les appels de fonctions passent par le registre de fonctions -- une table de recherche complète. Dans le contexte template, les appels passent par l'évaluateur d'expressions du moteur de rendu -- un bloc match dans renderer.rs qui ne gère que les fonctions avec des bras match explicites.
Implémentation des fonctions P0 manquantes
Douze fonctions de formatage et prédicats de dates n'étaient implémentées nulle part. Un nouveau module src/vm/builtins/formatting.rs a été créé avec format_number, format_currency, slugify et d'autres. Le module time.rs a été étendu avec is_past, is_future, is_today, is_this_week, time_quarter et d'autres.
Exposer plus de 70 fonctions aux templates
Le travail restant était de câbler les fonctions bytecode existantes au moteur de rendu des templates, en ajoutant des bras match pour chaque catégorie de fonctions : chaînes (30 fonctions), mathématiques (12), dates (12), listes, types, validation, encodage et formatage.
Le total après la session 266 : 87+ fonctions accessibles depuis les templates, contre 17 auparavant. L'accessibilité des templates est passée de 12 % à plus de 66 %.
Le trio pluck, group_by et compact
Trois nouvelles fonctions de liste méritaient une mention spéciale car elles répondaient à des schémas de templates courants nécessitant auparavant des solutions de contournement verbeuses :
flin// Avant : extraire un seul champ d'une liste d'entités
// Nécessitait une itération manuelle
// Après : un appel de fonction
names = pluck(users, "name")
by_department = group_by(employees, "department")
valid = compact(items)L'audit des fonctions a mis en lumière un schéma que nous avions vu tout au long du développement de FLIN : les fonctionnalités étaient implémentées quand elles étaient nécessaires pour l'objectif d'une session spécifique, mais le câblage pour les rendre universellement accessibles était souvent reporté. L'audit l'a détecté, et une seule session a comblé le fossé.
Après la session 266, le compteur de tests s'élevait à 3 117 -- tous passants.
Ceci est la partie 150 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [149] Le plan de correction de l'audit - [150] Audit des fonctions, jour 7 terminé (vous êtes ici) - [151] Audit de la persistance de base de données