RÉFÉRENCE VITTE / Organisation

Modules et visibilité

Les modules donnent des chemins aux déclarations et définissent quels noms les autres parties du programme peuvent importer.

Niveau de garantieUn import qualifié est compilé et exécuté ; chaque variante d’import/export n’a pas la même preuve.

Source de référence : grammar/vitte.ebnf · modules/core/README.md · modules/json/DOCUMENTATION.md

Nommer un module

space outils::calcul;

La grammaire permet des segments séparés par :: ou /. Le manifeste JSON documente :: comme syntaxe de chemin de module. Garde les noms de fichier, le chemin logique space, les imports et le manifeste du paquet cohérents.

Importer

use core::types::option::{Option, option_some};
use outils::calcul as calcul;
use outils::math::*;

use prend un chemin, un alias, un groupe de noms ou un glob. Les alias donnent un nom local ; les imports globaux font entrer plusieurs symboles dans la portée et peuvent rendre leur provenance ambiguë. Préfère les imports explicites dans une API que d’autres personnes doivent relire.

Exporter

export const REPONSE: i64 = 42;
export proc calculer() -> i64 { return REPONSE; }
export { REPONSE, calculer };

La grammaire fournit des formes d’export de déclaration et des listes d’exports. Le compilateur a des limites sur certains réexports ; un nom accessible localement n’est pas nécessairement réexportable depuis un autre module.

Résolution et visibilité

Un nom qualifié comme json::parser::parser donne la provenance d’une déclaration. L’importeur recherche les modules dans des racines configurées. Le CLI documente notamment VITTE_MODULE_PATH pour ajouter des racines et --manifest-path/--project-root pour préciser le projet.

La documentation de core indique que les imports doivent actuellement venir du chemin complet : core::prelude ne fournit pas une façade complète par réexport. Pour diagnostiquer un import, vérifie successivement le chemin logique, la racine de résolution, l’existence du fichier et l’export du symbole utilisé.

Organisation de paquet

Le paquet JSON fournit un exemple de manifeste package.toml avec nom, version, fichier d’entrée, racine du module et syntaxe de chemin. Consulte sa documentation de paquet pour l’installation et l’utilisation de VITTE_MODULE_PATH.

Vérification des constructions de module

Construction	EBNF	Analyseur et résolution	Compilation constatée
`space chemin;`	Décrite, avec segments `::` ou `/`.	Acceptée dans les fixtures de modules/parité.	Oui : des modules avec chemins déclarés sont compilés dans les suites runtime.
`use chemin` et appel qualifié	Décrits.	Import résolu par le test d’import natif/bootstrap.	Oui : `llvm_imports_runtime.vit` importe un module, appelle ses procédures et s’exécute.
Alias `use chemin as nom`	Décrit.	Accepté dans le fichier runtime d’import.	Oui : l’alias `imported` est utilisé pour des appels compilés et exécutés.
Imports groupés et glob	Décrits dans la production `use`.	Les fixtures d’import couvrent plusieurs formes, mais chaque variante n’a pas été lancée comme programme runtime dans l’audit.	Non prouvé pour tous les groupes/globs ; consulter les fixtures d’import/visibilité.
`export` de déclaration	Décrit.	Exercé par les modules de test et l’analyse sémantique.	Des valeurs exportées sont importées dans les tests runtime ; toutes les déclarations ne sont pas couvertes.
Réexport avec alias ou chemin	La grammaire décrit les formes d’export.	Le pipeline de CLI route les alias d’export vers la compatibilité ; le parseur bootstrap documente le rejet de certains réexports de module.	Non prouvé en exécution pour les réexports généraux.
Imports qualifiés ambigus	La forme syntaxique de l’import existe.	La cible `import_collision/modules_main.vit` est explicitement ignorée dans `test-sema`, car la résolution sémantique des collisions qualifiées reste incomplète.	Non confirmé ; un nom importé en collision ne doit pas être considéré comme résolu de façon garantie.
Racines de projet et manifeste	Hors grammaire du langage.	Options CLI documentées ; exemples dans les tests de projet/modules.	La résolution de module est exécutée par une fixture ; chaque combinaison de manifeste/racine n’est pas couverte.

Cette table distingue une syntaxe acceptée d’un module effectivement résolu. Voir la matrice globale du compilateur et la fiche CLI.