seed Idioma: requisitos del producto
Esta página registra los requisitos del producto activo para seed. No es una segunda página de gramática o estado de implementación. El comportamiento del lenguaje normativo vive en seed/docs/lang-spec.md; Los reclamos implementados y los niveles objetivo se encuentran en Estado actual.
Objetivo del producto
seed es un lenguaje de sistemas de tipado estático para programas nativos que necesitan:
- memoria determinista y comportamiento de recursos sin un recolector de basura;
- controles de seguridad que permanecen habilitados en compilaciones optimizadas;
- un modelo de propiedad y una superficie de lenguaje más pequeños que Rust o C++;
- análisis, verificación, compilación y reutilización incremental rápidos;
- acceso explícito de bajo nivel cuando las abstracciones seguras son insuficientes;
- concurrencia estructurada sin nivel de idioma async/await.
El producto principal es el software de sistemas controlados: CLI herramientas, servicios internos, binary/text procesamiento, bibliotecas nativas y trabajo independiente en los niveles de destino cerrados explícitamente por las puertas del compilador.
No goles
seed no exige ni promete:
- recolección de basura, desenredado de excepciones, sintaxis de por vida, macros, clases, herencia, despacho virtual o nivel de idioma async/await;
- compatibilidad con la sintaxis heredada de seed o con los backends del compilador reemplazados;
- un perfil de optimización no controlado que debilita silenciosamente la semántica segura;
- superioridad de rendimiento universal sobre C, Rust, Zig, Go o tiempos de ejecución administrados;
- soporte alojado en un objetivo simplemente porque LLVM existe emisión de objetos;
- autohospedaje antes de que el compilador y el ecosistema LLVM operativos sean estables.
Requisitos de idioma
| Requisito | Criterio de aceptación actual | evidencia |
|---|---|---|
| Tipos estáticos con inferencia. | Cada programa aceptado se escribe antes de MIR; Las interfaces públicas preservan los tipos. | especificación del lenguaje y .sdi pruebas |
| Propiedad predecible | Copia de escalares; los recursos se mueven; clonar es explícito; los propietarios vivos limpian exactamente una vez en las salidas estructuradas | Gates 10–11 y pruebas de propiedad |
| Préstamo seguro sin sintaxis de por vida | Las vistas tienen procedencia lexical/input/receiver y no pueden sobrevivir al almacenamiento de respaldo | ownership/provenance pruebas e interfaces de esquema |
| Fallo de asignación explícito | Las API de asignación segura devuelven result<..., alloc_error> u otro error declarado |
option/result y pruebas de biblioteca |
| Acceso a datos comprobados | La indexación, el corte, los discriminantes y las particiones mutables seguros validan sus contratos | Gates 6, 16 y 19 |
| Límite inseguro explícito | La memoria sin procesar, los punteros, FFI, las llamadas al sistema, las uniones, los átomos, el acceso volátil, los espacios de direcciones y el ensamblaje requieren unsafe |
contrato de seguridad y pruebas negativas |
| Semántica de liberación determinista | --release y --release-small conservan los controles seguros a menos que LLVM demuestre que son redundantes. |
Gate 13 pruebas de perfil |
| Concurrencia estructurada | El trabajo generado se drena en los límites léxicos; transferir y compartir requieren capacidades | Gate 6 task/runtime pruebas |
| Fallo ordinario recuperable | Opciones, resultados, postfix. ?y los resultados de las tareas escritas preservan la propiedad y la limpieza |
Gate 6 y Gate 15 pruebas |
| UTF-8 fuente y texto | El texto original y propio rechaza el formato incorrecto UTF-8; la longitud de bytes y los límites de la biblioteca Unicode permanecen explícitos | pruebas de cargador y texto |
Modelo de memoria
El modelo común requerido es:
- Copia de valores con capacidad de copia.
- Los recursos propios se mueven durante asignaciones, llamadas, devoluciones, capturas y agregados. construcción.
- prestado
str,[]t, ymut []tlas vistas conservan la procedencia. .clone()es explícito y sus efectos allocation/retain son parte del contrato público.- La limpieza se ejecuta una vez en orden inverso de inicialización exitosa en estructurado. salidas.
linear tagrega una obligación exactamente una vez sin cambiar la representación.- Las regiones proporcionan asignación de protuberancias léxicas verificadas y rechazan escapar de forma segura propietarios, vistas y sugerencias.
- El pánico, la trampa y el aborto no desenredan ni ejecutan destructores léxicos.
Los detalles operativos actuales están documentados en Ownership.
Requisitos del compilador
El compilador operativo es seed/compiler/llvm. Su canalización requerida es:
source → lexer/parser → semantic graph → typed HIR/CFG
→ ownership/provenance/effects/loans → cleanup planning/verification
→ MIR → target layout/ABI → verified low MIR → LLVM
el Linux x86-64 El reemplazo autohospedado es una migración cerrada activa bajo roadmap-self-hosted.md. Hasta su transición SH20, seed/compiler/llvm sigue siendo el compilador operativo y el oráculo semántico. Otros puertos de plataforma autohospedados se posponen hasta después del primero Linux x86-64 transición.
Cada ruta de fuente y de interfaz eliminada de fuente debe pasar por la misma tipificación, propiedad, procedencia, efectos, limpieza, ABI y comprobaciones de perfil antes de la generación del código.
El compilador debe proporcionar:
- diagnósticos humanos y JSON con ubicaciones de fuente estables;
- formateo y semantic/IR modos de inspección;
- LLVM Emisión de IR, objeto, ejecutable, biblioteca compartida y biblioteca estática en el nivel declarado de cada objetivo;
- perfiles de liberación segura y explícita independiente ThinLTO/PGO/static-linking opciones;
- compilación separada a través de interfaces
.sdivalidadas; - objetivo exacto, ABI, perfil de compilación, perfil de tiempo de ejecución, dependencia y cuerpo en línea identidad para artefactos reutilizables;
- Rechazo determinista de información mal formada, obsoleta, incompatible o corrupta. interfaces y entradas de caché.
Los compiladores OCaml, QBE, estilo TCC y de código auxiliar de ensamblaje reemplazados son solo historial de compatibilidad y no satisfacen los requisitos actuales del producto.
Requisitos de tiempo de ejecución y objetivo
El soporte objetivo debe describirse como una matriz de capacidad, no como un valor booleano. El análisis, LLVM, el objeto, el archivo, la biblioteca compartida, el ejecutable, la ejecución alojada, los servicios de tiempo de ejecución, el FFI, el programador, los artefactos del paquete y la evidencia de arranque se rastrean por separado.
La matriz canónica es seed/compiler/llvm/tests/GATE14_TARGET_MATRIX.tsv. Linux x86-64 es el principal objetivo alojado cerrado. Gate 14 está completo después del nativo requerido macOS x86-64 evidencia; macOS arm64 tiene su fila de host nativo verificada por separado y no sustituye el requisito de cierre de Intel. WebAssembly/WASI Actualmente es solo de objetos.
Los perfiles independientes y de kernel deben declarar sus servicios de ejecución disponibles. Los efectos de asignación, bloqueo, pánico, I/O, redes y programación solo se pueden utilizar cuando el perfil seleccionado los proporciona.
Requisitos de la biblioteca
El núcleo lingüístico sigue siendo pequeño. Los archivos, las redes, el análisis, el formateo, las colecciones, las tareas y los contenedores del sistema son bibliotecas ordinarias con interfaces explícitas en lugar de funciones integradas ocultas.
El conjunto de repositorio operativo se encuentra en seed/compiler/llvm/libs y está documentado en Referencia de biblioteca. Las bibliotecas deben:
- exponer propiedad, procedencia, mutación, asignación, pánico, bloqueo y efectos inseguros en su signatures/interfaces;
- prefiera envoltorios seguros en lugar de tiempo de ejecución sin formato u operaciones FFI;
- devolver errores escritos en caso de fallo recuperable;
- preservar la limpieza exacta para valores parcialmente inicializados y movidos;
- Evite presentar las API Grove heredadas como funciones integradas del compilador actual.
El árbol grove/ de nivel superior más grande es un corpus de compatibilidad y portabilidad hasta que un paquete individual pasa el compilador operativo y recibe un contrato manifest/interface actual.
Requisitos de herramientas
El iniciador del repositorio y el compilador directo juntos deben admitir:
- comprobar, crear, ejecutar y probar flujos de trabajo;
- resolución de dependencias reproducibles, archivos de bloqueo y cachés;
- reutilización incremental object/interface con invalidación exacta;
- validación de paquetes y declaraciones de plataforma para paquetes FFI;
- Diagnóstico, formateo, linting y documentación generada de LSP;
- instalación transaccional user/system y desinstalación basada en referencias;
- Consumo de bibliotecas estáticas y dinámicas sin semántica dependiente de la fuente. atajos.
El ejecutable seed --help sigue teniendo autoridad para los indicadores del compilador directo. La referencia del idioma documenta el iniciador del repositorio.
Requisitos de rendimiento y calidad.
Las afirmaciones de desempeño requieren evidencia controlada. Las puertas de cierre actuales imponen:
- un presupuesto de escalabilidad de verificación completa de 100.000 líneas;
- Corpus de comparación equivalentes C/Rust para tiempo de ejecución, inicio, RSS, artefacto tamaño, análisis, asignación, colecciones, redes y tareas;
- comportamiento de perfil seguro en lugar de semántica de referencia únicamente sin control;
- normales y ASan/UBSan validación de compiler/runtime binarios unitarios;
- Metodología de referencia que distingue el tiempo de carga de trabajo del nivel de suite. tiempo de compilación, RSS, LOC y tamaño del artefacto.
La instantánea actual en varios idiomas se encuentra en Benchmarks. Es un corpus medido localmente, no una clasificación para todo el idioma.
Brechas de productos actuales
Las principales brechas de productos restantes son:
- Gate 14 cierre nativo macOS x86-64 y evidencia de portabilidad alojada más amplia;
- portar o reemplazar paquetes Grove heredados con paquetes en lenguaje limpio;
- amplitud del ecosistema y distribución estable de terceros;
- Pulido de IDE, depurador, formateador y herramientas operativas;
- optimizador y evidencia de aplicaciones más allá de las puertas controladas del compilador;
- historial de producción y garantías de compatibilidad entre versiones.
Aquí se deben agregar nuevos requisitos solo cuando describan la intención del producto. La gramática pertenece a la especificación del lenguaje, el estado de implementación en status.mdy trabajo de compilación planificado en seed/compiler/llvm/ROADMAP.md.