seed Idioma — Requisitos do Produto

Esta página registra os requisitos do produto ativo para seed. Não é uma segunda página de gramática ou status de implementação. O comportamento da linguagem normativa reside em seed/docs/lang-spec.md; as reivindicações implementadas e os níveis-alvo estão em Status Atual.

Objetivo do produto

seed é uma linguagem de sistemas de tipo estaticamente para programas nativos que precisam:

memória determinística e comportamento de recursos sem coletor de lixo;
verificações de segurança que permanecem habilitadas em compilações otimizadas;
um modelo de propriedade e superfície de linguagem menores do que Rust ou C++;
análise rápida, verificação, compilação e reutilização incremental;
acesso explícito de baixo nível quando as abstrações seguras são insuficientes;
simultaneidade estruturada sem nível de linguagem async/await.

O principal produto é o software de sistemas controlados: CLI ferramentas, serviços internos, binary/text processamento, bibliotecas nativas e trabalho independente nos níveis de destino explicitamente fechados pelas portas do compilador.

Não-objetivos

seed não exige nem promete:

coleta de lixo, desenrolamento de exceção, sintaxe vitalícia, macros, classes, herança, despacho virtual ou nível de linguagem async/await;
compatibilidade com sintaxe seed herdada ou back-ends de compilador substituídos;
um perfil de otimização não verificado que enfraquece silenciosamente a semântica segura;
superioridade universal de desempenho sobre C, Rust, Zig, Go ou tempos de execução gerenciados;
suporte hospedado em um destino apenas porque LLVM existe emissão de objeto;
auto-hospedagem antes que o compilador LLVM operacional e o ecossistema estejam estáveis.

Requisitos de idioma

Requisito	Critério de aceitação atual	Evidência
Tipos estáticos com inferência	Todo programa aceito é digitado antes do MIR; interfaces públicas preservam tipos	especificação de linguagem e `.sdi` testes
Propriedade previsível	Cópia escalar; movimentação de recursos; clone é explícito; proprietários ao vivo limpam exatamente uma vez em saídas estruturadas	Gates 10–11 e testes de propriedade
Empréstimo seguro sem sintaxe vitalícia	As visualizações têm origem lexical/input/receiver e não podem sobreviver ao armazenamento de apoio	ownership/provenance testes e interfaces de esquema
Falha de alocação explícita	APIs de alocação segura retornam `result<..., alloc_error>` ou outro erro declarado	option/result e testes de biblioteca
Acesso aos dados verificado	Indexação segura, fatiamento, discriminantes e partições mutáveis validam seus contratos	Gates 6, 16 e 19
Limite inseguro explícito	Memória bruta, ponteiros, FFI, syscalls, uniões, atômicos, acesso volátil, espaços de endereço e montagem requerem `unsafe`	contrato de segurança e testes negativos
Semântica de liberação determinística	`--release` e `--release-small` preservam verificações seguras, a menos que LLVM prove que são redundantes	Gate 13 testes de perfil
Simultaneidade estruturada	O trabalho gerado drena nos limites lexicais; transferência e compartilhamento exigem recursos	Gate 6 task/runtime testes
Falha comum recuperável	Opções, resultados, postfix `?`e os resultados da tarefa digitada preservam a propriedade e a limpeza	Gate 6 e Gate 15 testes
UTF-8 fonte e texto	Texto de origem e de propriedade rejeitado malformado UTF-8; o comprimento de bytes e os limites da biblioteca Unicode permanecem explícitos	testes de carregador e texto

Modelo de memória

O modelo comum necessário é:

Cópia de valores com capacidade de cópia.
Os recursos próprios movem-se em atribuições, chamadas, devoluções, capturas e agregações construção.
Emprestado str, []te mut []t as vistas mantêm a proveniência.
.clone() é explícito e seus efeitos allocation/retain fazem parte do contrato público.
A limpeza é executada uma vez na ordem reversa de inicialização bem-sucedida em estruturas saídas.
linear t adiciona uma obrigação exatamente uma vez sem alterar a representação.
As regiões fornecem alocação de colisão lexical verificada e rejeitam o escape seguro proprietários, visualizações e ponteiros.
Pânico, armadilha e aborto não desenrolam nem executam destruidores lexicais.

Os detalhes operacionais atuais estão documentados em Ownership.

Requisitos do compilador

O compilador operacional é seed/compiler/llvm. Seu pipeline necessário é:

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

O Linux x86-64 a substituição auto-hospedada é uma migração fechada ativa em roadmap-self-hosted.md. Até sua transição para SH20, seed/compiler/llvm continua sendo o compilador operacional e o oráculo semântico. Outras portas de plataforma auto-hospedadas são adiadas até depois da primeira Linux x86-64 transição.

Cada fonte e caminho de interface com origem excluída devem passar pela mesma digitação relevante, propriedade, procedência, efeitos, limpeza, ABI e verificações de perfil antes da geração do código.

O compilador deve fornecer:

diagnóstico humano e JSON com locais de origem estáveis;
formatação e semantic/IR modos de inspeção;
LLVM IR, objeto, executável, biblioteca compartilhada e emissão de biblioteca estática em o nível declarado de cada alvo;
perfis de liberação segura e independência explícita ThinLTO/PGO/static-linking escolhas;
compilação separada por meio de interfaces .sdi validadas;
destino exato, ABI, perfil de construção, perfil de tempo de execução, dependência e corpo embutido identidade para artefatos reutilizáveis;
rejeição determinística de conceitos malformados, obsoletos, incompatíveis ou corrompidos. interfaces e entradas de cache.

Os compiladores substituídos OCaml, QBE, estilo TCC e assembly-stub são apenas históricos de compatibilidade e não atendem aos requisitos atuais do produto.

Requisitos de tempo de execução e destino

O suporte alvo deve ser descrito como uma matriz de capacidade, não como um booleano. Análise, LLVM, objeto, arquivo, biblioteca compartilhada, executável, execução hospedada, serviços de tempo de execução, FFI, agendador, artefatos de pacote e evidências de inicialização são rastreados separadamente.

A matriz canônica é seed/compiler/llvm/tests/GATE14_TARGET_MATRIX.tsv. Linux x86-64 é o principal destino hospedado fechado. Gate 14 é concluído após a evidência nativa macOS x86-64 necessária; macOS arm64 tem sua linha de host nativo verificada separadamente e não substitui o requisito de fechamento da Intel. WebAssembly/WASI atualmente é apenas objeto.

Perfis independentes e de kernel devem declarar seus serviços de tempo de execução disponíveis. Os efeitos de alocação, bloqueio, pânico, I/O, rede e agendamento só podem ser usados quando o perfil selecionado os fornecer.

Requisitos da biblioteca

O núcleo da linguagem permanece pequeno. Arquivos, redes, análise, formatação, coleções, tarefas e wrappers de sistema são bibliotecas comuns com interfaces explícitas em vez de recursos internos ocultos.

O conjunto de repositórios operacionais está sob seed/compiler/llvm/libs e está documentado em Referência da Biblioteca. As bibliotecas devem:

expor propriedade, proveniência, mutação, alocação, pânico, bloqueio e efeitos inseguros em seu signatures/interfaces;
prefira wrappers seguros em vez de tempo de execução bruto ou operações FFI;
retornar erros digitados para falha recuperável;
preservar a limpeza exata para valores parcialmente inicializados e movidos;
evite apresentar APIs Grove herdadas como integrações do compilador atual.

A árvore grove/ de nível superior maior é um corpus de compatibilidade e portabilidade até que um pacote individual passe pelo compilador operacional e receba um contrato manifest/interface atual.

Requisitos de ferramentas

O inicializador de repositório e o compilador direto juntos devem suportar:

verificar, construir, executar e testar fluxos de trabalho;
resolução de dependências reproduzíveis, arquivos de bloqueio e caches;
reutilização incremental de object/interface com invalidação exata;
validação de pacotes e declarações de plataforma para pacotes FFI;
Diagnóstico LSP, formatação, linting e documentação gerada;
instalação transacional do user/system e desinstalação com reconhecimento de referência;
consumo de biblioteca estática e dinâmica sem semântica dependente da fonte atalhos.

O executável seed --help permanece autoritativo para sinalizadores diretos do compilador. Referência de idioma documenta o inicializador do repositório.

Requisitos de desempenho e qualidade

As reivindicações de desempenho exigem evidências controladas. Os atuais portões de fechamento impõem:

um orçamento de escalabilidade com verificação completa de 100 mil linhas;
corpora de comparação C/Rust equivalente para tempo de execução, inicialização, RSS, artefato tamanho, análise, alocação, coleções, rede e tarefas;
comportamento de perfil seguro em vez de semântica não verificada apenas de benchmark;
normal e ASan/UBSan validação de compiler/runtime binários unitários;
metodologia de benchmark que distingue o tempo de carga de trabalho do nível de suíte tempo de compilação, RSS, LOC e tamanho do artefato.

O instantâneo atual entre idiomas está em Benchmarks. É um corpus medido localmente, não uma classificação para todo o idioma.

Lacunas atuais de produtos

As principais lacunas restantes do produto são:

Gate 14 fechamento nativo macOS x86-64 e evidência de portabilidade hospedada mais ampla;
portar ou substituir pacotes herdados Grove por pacotes de linguagem limpa;
amplitude do ecossistema e distribuição estável de terceiros;
IDE, depurador, formatador e polimento de ferramentas operacionais;
evidências de otimizador e aplicação além das portas controladas do compilador;
histórico de produção e garantias de compatibilidade entre versões.

Novos requisitos devem ser adicionados aqui somente quando descreverem a intenção do produto. A gramática pertence à especificação da linguagem, o status de implementação na status.mde trabalho planejado do compilador em seed/compiler/llvm/ROADMAP.md.