# 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 :

```text
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 :

```text
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 :

```text
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é :

```text
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 :

```text
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.

---