seed Langue — Exigences du produit

Cette page enregistre les exigences du produit actif pour seed. Il ne s'agit pas d'une deuxième page de grammaire ou de statut d'implémentation. Le comportement linguistique normatif vit dans seed/docs/lang-spec.md; les revendications mises en œuvre et les niveaux cibles sont disponibles dans Statut actuel.

Objectif du produit

seed est un langage système typé statiquement pour les programmes natifs nécessitant :

mémoire déterministe et comportement des ressources sans garbage collector ;
des contrôles de sécurité qui restent activés dans les versions optimisées ;
un modèle de propriété et une surface de langage plus petits que Rust ou C++ ;
analyse rapide, vérification, compilation et réutilisation incrémentielle ;
accès explicite de bas niveau lorsque les abstractions sécurisées sont insuffisantes ;
concurrence structurée sans niveau de langage async/await.

Le produit principal est le logiciel de systèmes contrôlés : CLI outils, services internes, binary/text le traitement, les bibliothèques natives et le travail autonome aux niveaux cibles explicitement fermés par les portes du compilateur.

Non-buts

seed n’exige ni ne promet :

garbage collection, déroulement des exceptions, syntaxe à vie, macros, classes, héritage, répartition virtuelle ou niveau de langue async/await;
compatibilité avec la syntaxe seed héritée ou avec les backends de compilateur remplacés ;
un profil d'optimisation non contrôlé qui affaiblit silencieusement la sémantique sûre ;
supériorité universelle des performances par rapport aux environnements d'exécution C, Rust, Zig, Go ou gérés ;
support hébergé sur une cible simplement parce que l'émission d'objet LLVM existe ;
l'auto-hébergement avant que le compilateur et l'écosystème opérationnels LLVM ne soient stables.

Exigences linguistiques

Exigence	Critère d'acceptation actuel	Preuve
Types statiques avec inférence	Chaque programme accepté est tapé avant MIR ; les interfaces publiques préservent les types	spécification de la langue et `.sdi` essais
Propriété prévisible	Copie des scalaires ; les ressources bougent ; le clone est explicite ; les propriétaires en direct nettoient exactement une fois sur les sorties structurées	Gates 10-11 et tests de propriété
Emprunt sécurisé sans syntaxe à vie	Les vues portent la provenance lexical/input/receiver et ne peuvent pas survivre au stockage de sauvegarde	ownership/provenance tests et interfaces de schéma
Échec d'allocation explicite	Les API d'allocation sécurisée renvoient `result<..., alloc_error>` ou une autre erreur déclarée	option/result et tests de bibliothèque
Accès aux données vérifié	L'indexation, le découpage, les discriminants et les partitions mutables sécurisés valident leurs contrats	Gates 6, 16 et 19
Limite dangereuse explicite	La mémoire brute, les pointeurs, les FFI, les appels système, les unions, les atomes, l'accès volatile, les espaces d'adressage et l'assemblage nécessitent `unsafe`	contrat de sécurité et tests négatifs
Sémantique de version déterministe	`--release` et `--release-small` préservent la sécurité des contrôles à moins que LLVM ne prouve leur redondance	Gate 13 tests de profil
Concurrence structurée	Le travail généré s'écoule aux limites lexicales ; le transfert et le partage nécessitent des capacités	Gate 6 task/runtime essais
Panne ordinaire récupérable	Options, résultats, suffixe `?`et les résultats des tâches saisis préservent la propriété et le nettoyage	Gate 6 et Gate 15 épreuves
UTF-8 source et texte	Le texte source et le texte détenu sont rejetés mal formés. UTF-8; la longueur en octets et les limites de la bibliothèque Unicode restent explicites	tests de chargeur et de texte

Modèle de mémoire

Le modèle commun requis est :

Copie des valeurs pouvant être copiées.
Les ressources détenues se déplacent lors de l'affectation, des appels, des retours, des captures et du regroupement construction.
Emprunté str, []t, et mut []t les vues conservent leur provenance.
.clone() est explicite et ses effets allocation/retain font partie du marché public.
Le nettoyage s'exécute une fois dans l'ordre inverse d'initialisation réussie sur structuré sorties.
linear t ajoute une obligation unique sans changer de représentation.
Les régions fournissent une allocation de bosses lexicales vérifiées et refusent de s'échapper en toute sécurité propriétaires, vues et pointeurs.
La panique, le piège et l'abandon ne déroulent pas et n'exécutent pas de destructeurs lexicaux.

Les détails opérationnels actuels sont documentés dans Ownership.

Exigences du compilateur

Le compilateur opérationnel est seed/compiler/llvm. Son pipeline requis est :

source → lexer/parser → semantic graph → typed HIR/CFG
       → ownership/provenance/effects/loans → cleanup planning/verification
       → MIR → target layout/ABI → verified low MIR → LLVM

Le Linux x86-64 le remplacement auto-hébergé est une migration fermée active sous roadmap-self-hosted.md. Jusqu'à son basculement SH20, seed/compiler/llvm reste le compilateur opérationnel et l’oracle sémantique. Les autres ports de plateforme auto-hébergés sont reportés après le premier Linux x86-64 basculement.

Chaque chemin d'interface source et élidé par la source doit transmettre les mêmes types de typage, de propriété, de provenance, d'effets, de nettoyage, ABI et vérifications de profil avant la génération de code.

Le compilateur doit fournir :

diagnostics humains et JSON avec emplacements sources stables ;
modes de formatage et d'inspection semantic/IR ;
LLVM Émission IR, objet, exécutable, bibliothèque partagée et bibliothèque statique à le niveau déclaré de chaque cible ;
profils de libération sûrs et indépendants explicites ThinLTO/PGO/static-linking choix ;
compilation séparée via des interfaces .sdi validées ;
cible exacte, ABI, profil de construction, profil d'exécution, dépendance et corps en ligne identité pour les artefacts réutilisables ;
rejet déterministe des éléments malformés, périmés, incompatibles ou corrompus interfaces et entrées de cache.

Les compilateurs OCaml, QBE, de style TCC et assembly-stub remplacés sont uniquement un historique de compatibilité et ne satisfont pas aux exigences actuelles du produit.

Exigences d'exécution et de cible

La prise en charge des cibles doit être décrite comme une matrice de capacités et non comme un booléen. L'analyse, LLVM, l'objet, l'archive, la bibliothèque partagée, l'exécutable, l'exécution hébergée, les services d'exécution, le FFI, le planificateur, les artefacts de package et les preuves de démarrage sont suivis séparément.

La matrice canonique est seed/compiler/llvm/tests/GATE14_TARGET_MATRIX.tsv. Linux x86-64 est la principale cible hébergée fermée. Gate 14 est terminé après les preuves natives macOS x86-64 requises ; macOS arm64 a sa ligne d'hôte natif vérifiée séparément et ne remplace pas l'exigence de fermeture Intel. WebAssembly/WASI est actuellement réservé aux objets.

Les profils autonomes et du noyau doivent déclarer leurs services d'exécution disponibles. Les effets d'allocation, de blocage, de panique, I/O, de mise en réseau et de planification ne peuvent être utilisés que lorsque le profil sélectionné les fournit.

Exigences de la bibliothèque

Le noyau linguistique reste restreint. Les fichiers, la mise en réseau, l'analyse, le formatage, les collections, les tâches et les wrappers système sont des bibliothèques ordinaires avec des interfaces explicites plutôt que des éléments intégrés cachés.

L'ensemble de référentiels opérationnels se trouve sous seed/compiler/llvm/libs et est documenté dans Library Reference. Les bibliothèques doivent :

exposer la propriété, la provenance, la mutation, l’allocation, la panique, le blocage et effets dangereux dans leur signatures/interfaces;
préférez les wrappers sécurisés aux opérations d'exécution brutes ou FFI ;
renvoyer les erreurs tapées en cas d'échec récupérable ;
conserver un nettoyage exact pour les valeurs partiellement initialisées et déplacées ;
évitez de présenter les anciennes API Grove comme éléments intégrés du compilateur actuel.

L'arborescence grove/ de niveau supérieur plus grande est un corpus de compatibilité et de portage jusqu'à ce qu'un package individuel passe par le compilateur opérationnel et reçoive un contrat manifest/interface actuel.

Exigences en matière d'outillage

Le lanceur de référentiel et le compilateur direct doivent prendre en charge :

vérifier, créer, exécuter et tester les flux de travail ;
résolution reproductible des dépendances, fichiers de verrouillage et caches ;
réutilisation incrémentielle de object/interface avec invalidation exacte ;
validation des packages et déclarations de plate-forme pour les packages FFI ;
Diagnostics LSP, formatage, peluchage et documentation générée ;
installation transactionnelle user/system et désinstallation prenant en compte les références ;
consommation de bibliothèque statique et dynamique sans sémantique dépendante de la source raccourcis.

L'exécutable seed --help fait toujours autorité pour les indicateurs directs du compilateur. Language Reference documente le lanceur de référentiel.

Exigences de performance et de qualité

Les allégations de performance nécessitent des preuves contrôlées. Les portes de fermeture actuelles appliquent :

un budget d'évolutivité de contrôle complet de 100 000 lignes ;
Corpus de comparaison équivalents C/Rust pour l'exécution, le démarrage, RSS, l'artefact taille, analyse, allocation, collections, mise en réseau et tâches ;
un comportement de profil sûr plutôt qu'une sémantique non contrôlée uniquement de référence ;
validation normale et ASan/UBSan des binaires de l'unité compiler/runtime ;
méthodologie de référence qui distingue le temps de charge de travail du niveau de la suite temps de compilation, RSS, LOC et taille des artefacts.

L'instantané multilingue actuel se trouve dans Benchmarks. Il s’agit d’un corpus mesuré localement et non d’un classement à l’échelle d’une langue.

Lacunes actuelles des produits

Les principales lacunes restantes du produit sont :

Gate 14 Fermeture native macOS x86-64 et preuves de portabilité hébergées plus larges ;
porter ou remplacer les anciens packages Grove par des packages en langage clair ;
l'étendue de l'écosystème et la distribution stable par des tiers ;
IDE, débogueur, formateur et polissage des outils opérationnels ;
preuves d'optimisation et d'application au-delà des portes contrôlées du compilateur ;
historique de production et garanties de compatibilité entre les versions.

De nouvelles exigences doivent être ajoutées ici uniquement lorsqu'elles décrivent l'intention du produit. La grammaire appartient à la spécification du langage, l'état de mise en œuvre dans status.md, et le travail prévu du compilateur dans seed/compiler/llvm/ROADMAP.md.