seed Lingua: requisiti del prodotto

Questa pagina registra i requisiti di prodotto attivi per seed. Non è una seconda pagina di grammatica o di stato dell'implementazione. Il comportamento del linguaggio normativo vive in seed/docs/lang-spec.md; le dichiarazioni implementate e i livelli target sono disponibili in Stato corrente.

Obiettivo del prodotto

seed è un linguaggio di sistema tipizzato staticamente per programmi nativi che necessitano di:

memoria deterministica e comportamento delle risorse senza un garbage collector;
controlli di sicurezza che rimangono abilitati nelle build ottimizzate;
un modello di proprietà e una superficie linguistica più piccoli rispetto a Rust o C++;
analisi, controllo, compilazione e riutilizzo incrementale rapidi;
accesso esplicito di basso livello quando le astrazioni sicure sono insufficienti;
concorrenza strutturata senza livello di linguaggio async/await.

Il prodotto principale è il software di sistema controllato: CLI strumenti, servizi interni, binary/text elaborazione, librerie native e lavoro indipendente ai livelli di destinazione esplicitamente chiusi dalle porte del compilatore.

Non gol

seed non richiede né promette:

garbage collection, rimozione delle eccezioni, sintassi a vita, macro, classi, ereditarietà, invio virtuale o livello di lingua async/await;
compatibilità con la sintassi legacy seed o backend del compilatore sostituito;
un profilo di ottimizzazione incontrollato che indebolisce silenziosamente la semantica sicura;
superiorità universale delle prestazioni rispetto a C, Rust, Zig, Go o runtime gestiti;
ha ospitato il supporto su un obiettivo semplicemente perché LLVM esiste l'emissione di oggetti;
il self-hosting prima che il compilatore operativo LLVM e l'ecosistema siano stabili.

Requisiti linguistici

Requisito	Criterio di accettazione attuale	Prove
Tipi statici con inferenza	Ogni programma accettato viene digitato prima di MIR; le interfacce pubbliche preservano i tipi	specificazione della lingua e `.sdi` test
Proprietà prevedibile	Copia scalare; le risorse si spostano; clone è esplicito; i proprietari dal vivo puliscono esattamente una volta sulle uscite strutturate	Gates 10–11 e test di proprietà
Prestiti sicuri senza sintassi a vita	Le visualizzazioni hanno la provenienza lexical/input/receiver e non possono sopravvivere allo spazio di archiviazione di backup	ownership/provenance test e interfacce dello schema
Errore di allocazione esplicita	Le API di allocazione sicura restituiscono `result<..., alloc_error>` o un altro errore dichiarato	option/result e test della libreria
Accesso ai dati controllato	Indicizzazione, affettatura, discriminanti e partizioni modificabili sicure convalidano i loro contratti	Gates 6, 16 e 19
Confine non sicuro esplicito	Memoria grezza, puntatori, FFI, chiamate di sistema, unioni, atomi, accesso volatile, spazi di indirizzi e assembly richiedono `unsafe`	contratto di sicurezza e test negativi
Semantica di rilascio deterministica	`--release` e `--release-small` preservano i controlli sicuri a meno che LLVM non li dimostri ridondanti	Gate 13 test di profilo
Concorrenza strutturata	Il lavoro generato drena ai confini lessicali; il trasferimento e la condivisione richiedono capacità	Gate 6 task/runtime test
Guasto ordinario reversibile	Opzioni, risultati, suffisso `?`e i risultati delle attività digitate preservano la proprietà e la pulizia	Gate 6 e Gate 15 test
UTF-8 sorgente e testo	Il testo di origine e di proprietà rifiuta il formato errato UTF-8; la lunghezza in byte e i limiti della libreria Unicode rimangono espliciti	caricatore e test di testo

Modello di memoria

Il modello comune richiesto è:

Copia di valori con capacità di copia.
Le risorse di proprietà si spostano in base all'assegnazione, alle chiamate, ai resi, alle acquisizioni e all'aggregazione costruzione.
Preso in prestito str, []t, e mut []t le visualizzazioni mantengono la provenienza.
.clone() è esplicito e i suoi effetti allocation/retain fanno parte del appalto pubblico.
La pulizia viene eseguita una volta in ordine inverso di inizializzazione riuscita su strutturato esce.
linear t aggiunge un obbligo esattamente una volta senza modificare la rappresentazione.
Le regioni forniscono un'assegnazione verificata del bump lessicale e rifiutano la fuga sicura proprietari, visualizzazioni e puntatori.
Panic, trap e abort non svolgono né eseguono distruttori lessicali.

Gli attuali dettagli operativi sono documentati in Proprietà.

Requisiti del compilatore

Il compilatore operativo è seed/compiler/llvm. La pipeline richiesta è:

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

Il Linux x86-64 la sostituzione self-hosted è una migrazione controllata attiva in roadmap-self-hosted.md. Fino al suo cutover SH20, seed/compiler/llvm rimane il compilatore operativo e l'oracolo semantico. Le altre porte della piattaforma self-hosted vengono rinviate a dopo la prima Linux x86-64 taglio.

Ogni percorso di interfaccia sorgente e eliminato dal sorgente deve superare la stessa tipizzazione, proprietà, provenienza, effetti, pulizia, ABI e controlli del profilo prima della generazione del codice.

Il compilatore deve fornire:

diagnostica umana e JSON con posizioni di origine stabili;
formattazione e semantic/IR modalità di ispezione;
LLVM Emissione IR, oggetto, eseguibile, libreria condivisa e libreria statica su il livello dichiarato di ciascun bersaglio;
profili di rilascio sicuro ed espliciti indipendenti ThinLTO/PGO/static-linking scelte;
compilazione separata tramite validata .sdi interfacce;
destinazione esatta, ABI, profilo di build, profilo di runtime, dipendenza e corpo in linea identità per artefatti riutilizzabili;
rifiuto deterministico di contenuti non validi, obsoleti, incompatibili o corrotti interfacce e voci della cache.

I compilatori OCaml, QBE, stile TCC e assembly-stub sostituiti rappresentano solo la cronologia di compatibilità e non soddisfano i requisiti attuali del prodotto.

Requisiti di runtime e target

Il supporto target deve essere descritto come una matrice di capacità, non come un valore booleano. L'analisi, LLVM, l'oggetto, l'archivio, la libreria condivisa, l'eseguibile, l'esecuzione ospitata, i servizi di runtime, l'FFI, lo scheduler, gli artefatti del pacchetto e l'evidenza di avvio vengono monitorati separatamente.

La matrice canonica è seed/compiler/llvm/tests/GATE14_TARGET_MATRIX.tsv. Linux x86-64 è la destinazione ospitata chiusa principale. Gate 14 è completo dopo la prova nativa macOS x86-64 richiesta; macOS arm64 ha la riga host nativa verificata separatamente e non sostituisce il requisito di chiusura Intel. WebAssembly/WASI è attualmente solo oggetto.

I profili indipendenti e kernel devono dichiarare i servizi runtime disponibili. Gli effetti di allocazione, blocco, panico, I/O, rete e pianificazione possono essere utilizzati solo quando il profilo selezionato li fornisce.

Requisiti della biblioteca

Il nucleo linguistico rimane piccolo. File, rete, analisi, formattazione, raccolte, attività e wrapper di sistema sono librerie ordinarie con interfacce esplicite anziché integrate nascoste.

Il set di repository operativi si trova sotto seed/compiler/llvm/libs ed è documentato in Riferimento libreria. Le biblioteche devono:

esporre proprietà, provenienza, mutazione, allocazione, panico, blocco e effetti non sicuri nel loro signatures/interfaces;
preferire wrapper sicuri rispetto al runtime grezzo o alle operazioni FFI;
restituire errori digitati per errori recuperabili;
preservare la pulizia esatta per i valori parzialmente inizializzati e spostati;
evitare di presentare le API Grove legacy come componenti integrati del compilatore corrente.

L'albero grove/ di livello superiore più grande è un corpus di compatibilità e porting finché un singolo pacchetto non passa il compilatore operativo e riceve un contratto manifest/interface corrente.

Requisiti degli strumenti

L'avvio del repository e il compilatore diretto insieme devono supportare:

controllare, creare, eseguire e testare i flussi di lavoro;
risoluzione riproducibile delle dipendenze, file di lock e cache;
riutilizzo object/interface incrementale con invalidazione esatta;
convalida dei pacchetti e dichiarazioni della piattaforma per i pacchetti FFI;
Diagnostica LSP, formattazione, linting e documentazione generata;
installazione transazionale user/system e disinstallazione con riconoscimento dei riferimenti;
consumo di librerie statiche e dinamiche senza semantica dipendente dalla sorgente scorciatoie.

L'eseguibile seed --help rimane autorevole per i flag del compilatore diretto. Il riferimento linguistico documenta l'avvio del repository.

Requisiti di prestazione e qualità

Le dichiarazioni sulle prestazioni richiedono prove controllate. Gli attuali cancelli di chiusura impongono:

un budget di scalabilità per il controllo completo di 100.000 linee;
corpora di confronto equivalenti C/Rust per runtime, avvio, RSS, artefatto dimensione, analisi, allocazione, raccolte, networking e attività;
comportamento del profilo sicuro piuttosto che semantica solo benchmark non controllata;
normale e ASan/UBSan convalida di compiler/runtime unità binarie;
metodologia di benchmark che distingue il tempo di carico di lavoro da quello a livello di suite tempo di compilazione, RSS, LOC e dimensione dell'artefatto.

L'attuale snapshot multilingue è in Benchmarks. Si tratta di un corpus misurato a livello locale, non di una classifica a livello linguistico.

Lacune attuali del prodotto

Le principali lacune rimanenti nei prodotti sono:

Gate 14 chiusura nativa macOS x86-64 e prova più ampia della portabilità ospitata;
porting o sostituzione di pacchetti Grove legacy con pacchetti in linguaggio pulito;
ampiezza dell’ecosistema e distribuzione stabile da parte di terzi;
IDE, debugger, formattatore e perfezionamento degli strumenti operativi;
ottimizzatore e prove applicative oltre i cancelli controllati del compilatore;
cronologia della produzione e garanzie di compatibilità tra le versioni.

I nuovi requisiti dovrebbero essere aggiunti qui solo quando descrivono l'intento del prodotto. La grammatica appartiene alla specifica della lingua, lo stato di implementazione a status.mde il lavoro del compilatore pianificato in seed/compiler/llvm/ROADMAP.md.