3.7 KiB
1. Trajectoire d'implémentation
1.1 V1 — V1 REQUIS — FIGÉ
V1 constitue la première implémentation cohérente et réellement utilisable de Saselang, mais reste avant tout une base/POC d'implémentation et de validation. Elle n'est pas la baseline publique de compatibilité durable.
Objectifs :
frontend complet
lexer
parser
AST
analyse sémantique
HIR
Sase IR
interpréteur
backend LLVM
Core V1
SDK initial
manifests et workspaces
gestion des dépendances
outils initiaux
Le compilateur V1 sera écrit dans un langage existant. Le choix entre Rust, Java ou une combinaison avec des générateurs tels que Flex/Bison ou équivalents reste un choix d'implémentation, pas une propriété du langage Saselang.
LLVM est le premier backend compilé de V1.
La conception de Saselang ne doit cependant pas faire de LLVM une dépendance sémantique du frontend.
V1 doit être suffisamment complète pour révéler les erreurs de conception réelles du langage. Des corrections incompatibles restent possibles avant la baseline publique V3 lorsqu'elles sont motivées, documentées et répercutées de façon cohérente dans la Bible, le Core et la toolchain.
1.2 Couverture LLVM — V1 REQUIS — FIGÉ EN PRINCIPE
Le backend natif V1 doit rester suffisamment générique pour exploiter les architectures, formats objet et capacités que LLVM peut représenter.
Cela ne signifie pas que toute cible connue de LLVM est automatiquement une cible officiellement supportée de bout en bout par Saselang V1 : une cible complète peut également nécessiter un ABI, un linker, un sysroot, un runtime et des bibliothèques de plateforme compatibles.
Une cible LLVM non validée peut donc être :
représentable par le backend
mais non officiellement supportée par la toolchain Saselang
1.3 V2 — SELF-HOSTING / SECOND POC
V2 est principalement la génération de self-hosting et le second POC structurel du langage.
Elle a pour objectif de réécrire progressivement en Saselang les composants réalisés en V1 :
compiler frontend
semantic analysis
Sase IR
interpreter
tooling
package/build tooling
Core/SDK lorsque pertinent
Le self-hosting doit révéler les contraintes réelles d'un grand programme Saselang écrit en Saselang lui-même.
Des corrections architecturales incompatibles avec V1 restent acceptables lorsqu'un besoin concret les justifie. V2 n'est cependant pas une excuse pour ajouter des mécanismes spéculatifs ou redéfinir arbitrairement la sémantique.
Une fonctionnalité future peut être réservée avant son implémentation uniquement lorsqu'un besoin réel est déjà identifié et qu'il est utile de protéger son espace syntaxique ou sémantique. Saselang ne réserve pas des mécanismes purement hypothétiques « au cas où ».
1.4 V3+ — BASELINE PUBLIQUE
V3 est envisagée comme la première génération réellement déterminante pour la stabilité publique du langage et de son écosystème.
À partir de cette baseline, la compatibilité :
source
Core
tooling
packages
artifacts
et, lorsque défini, ABI/binaire
doit être protégée beaucoup plus strictement.
Les changements incompatibles deviennent alors des décisions exceptionnelles, versionnées et explicitement justifiées.
À partir de V3+, les efforts pourront également se concentrer sur les autres environnements et backends :
browser runtime / extension
browser chunks/bundling
WebAssembly
JVM
JavaScript
TypeScript
Android packaging
iOS packaging
backends/ABI supplémentaires
outillage avancé
cibles spécialisées
Les décisions browser de cette Bible sont donc des orientations de compatibilité, pas la spécification finale du browser runtime.