FLIN supporte quatre formes d'imports (simple, nommé, avec alias, namespace) et trois formes d'exports (pub, re-exports nommés, re-exports wildcard). Les mots-clés de modules sont des « mots-clés doux » qui peuvent aussi être utilisés comme identifiants.
La résolution de chemins suit trois règles : les chemins relatifs (./, ../) résolvent depuis le répertoire du fichier courant, les chemins absolus sont utilisés tels quels, et les chemins de paquets résolvent depuis la racine du projet. Le cache de modules garantit que chaque fichier est parsé exactement une fois. Les dépendances circulaires sont détectées et rejetées comme erreurs dures.
L'idée critique de la Session 129 : FLIN inline le code importé directement dans le programme principal avant la compilation. Après l'inlining, le compilateur voit un seul programme sans instructions d'import. Le vérificateur de types valide tous les noms. Le générateur de code émet du bytecode pour le programme combiné. Aucune frontière de module n'existe à l'exécution.
Le système de modules transforme FLIN d'un langage pour applications mono-fichier en un langage pour de vrais projets, avec zéro surcharge à l'exécution.
Ceci est la partie 178 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 : - [177] L'extension VSCode pour FLIN - [178] Le système de modules et les imports (vous êtes ici) - [179] Littéraux de templates et formatage de chaînes