123 lines
3.2 KiB
Markdown
123 lines
3.2 KiB
Markdown
# 4. Couches de l'écosystème V1
|
|
|
|
## 4.1 Saselang Language — V1 REQUIS — FIGÉ
|
|
|
|
Le langage comprend notamment :
|
|
|
|
```text
|
|
grammaire
|
|
types primitifs
|
|
types nominaux
|
|
fonctions/méthodes
|
|
classes
|
|
structs
|
|
interfaces
|
|
enums
|
|
unions
|
|
tuples
|
|
generics
|
|
contrôle de flux
|
|
erreurs/exceptions/faults
|
|
opérateurs
|
|
unsafe
|
|
scope
|
|
visibilité
|
|
imports
|
|
compilation conditionnelle structurelle
|
|
```
|
|
|
|
## 4.2 Saselang Core — V1 REQUIS — À FINALISER
|
|
|
|
Le Core est minimal et contient les types fondamentaux non primitifs nécessaires au langage.
|
|
|
|
Les types compiler-known doivent rester rares.
|
|
|
|
Candidats actuellement nécessaires ou fortement retenus :
|
|
|
|
```text
|
|
Object
|
|
String
|
|
Result<T>
|
|
Result<T,E>
|
|
Error
|
|
ResultError
|
|
Exception
|
|
Fault
|
|
Option<T>
|
|
Nullable<T>
|
|
Range<T>
|
|
RangeIterable<T>
|
|
RangeStep<T,Step>
|
|
RangeReverse<T>
|
|
RangeReverseStep<T,Step>
|
|
RangeProgression<T,Step>
|
|
PartialOrdering
|
|
Ordering
|
|
Comparable<T>
|
|
Comparator<T>
|
|
Op...
|
|
Iterable<T>
|
|
Iterator<T>
|
|
View<T>
|
|
Collection<T>
|
|
List<T>
|
|
Set<T>
|
|
Map<K,V>
|
|
Array<T>
|
|
StaticArray<T,N>
|
|
TypeInfo
|
|
ExitCode
|
|
```
|
|
|
|
Le fait d'être compiler-known ne transforme pas un type en primitive.
|
|
|
|
Les primitives peuvent exposer des membres standard définis par le Core sans devenir des classes. Les conversions numériques standard constituent un exemple important : leur surface API appartient au Core, tandis que le compilateur ne connaît que les règles de typage, les contrats d'intrinsics et les opérations Sase IR nécessaires à leur validation et à leur lowering.
|
|
|
|
Une capacité Core peut être conditionnée par un target lorsqu'elle ne peut raisonnablement pas être garantie partout. Une optimisation matérielle ne suffit pas à rendre une capacité conditionnelle si une implémentation logicielle conforme est raisonnable. L'absence d'une capacité réellement requise doit être diagnostiquée à la compilation pour le target choisi.
|
|
|
|
## 4.3 Saselang SDK — V1 REQUIS — À FINALISER
|
|
|
|
Le SDK fournit les fonctionnalités de bibliothèque qui ne justifient pas une sémantique spéciale du compilateur :
|
|
|
|
```text
|
|
collections concrètes/spécialisées au-delà des contrats fondamentaux Core
|
|
encodages explicites
|
|
regex
|
|
filesystem
|
|
networking
|
|
process
|
|
concurrence
|
|
math
|
|
algèbre
|
|
FFI helpers
|
|
plateforme
|
|
```
|
|
|
|
Le découpage exact Core/SDK doit être finalisé avant gel de l'API V1.
|
|
|
|
## 4.4 Bibliothèques officielles `.saselib` — DIRECTION FIGÉE
|
|
|
|
Au-delà du Core et du SDK, l'écosystème Saselang peut fournir des familles de bibliothèques officielles distribuées au format `.saselib`.
|
|
|
|
Aucune notion spécifique d'« addon » n'est introduite.
|
|
|
|
Ces bibliothèques restent optionnelles et versionnées indépendamment lorsque leur fonction ne justifie pas une présence obligatoire dans le SDK.
|
|
|
|
Leur nom peut refléter directement la famille fonctionnelle concernée. Une famille de moteur embarqué inspirée de MapDB peut ainsi employer des noms du type :
|
|
|
|
```text
|
|
saselang/mapdb*
|
|
```
|
|
|
|
sans obligation de la cacher derrière une hiérarchie générique `saselang/storage*`.
|
|
|
|
Le même principe s'applique aux futurs portages/réimplémentations spécialisés.
|
|
|
|
## 4.5 Runtime réduit — V1 REQUIS — FIGÉ EN PRINCIPE
|
|
|
|
Une application native simple ne doit pas être forcée d'embarquer un runtime monolithique.
|
|
|
|
Les services runtime doivent être ajoutés par capacités réelles.
|
|
|
|
---
|