48 lines
2.8 KiB
Markdown
48 lines
2.8 KiB
Markdown
# PBS Spec Approval TODO
|
|
|
|
Status: Draft
|
|
Purpose: checklist curto para decidir se a spec da PBS pode ser aprovada para seguir agora
|
|
|
|
## Blockers
|
|
|
|
- [ ] Fechar o gate de prontidao para implementacao definido no charter.
|
|
Hoje o charter exige specs adicionais antes de iniciar implementacao: dynamic semantics, memory and lifetime, host ABI binding, module/package, diagnostics, IR/lowering e conformance.
|
|
Referencia: `1. Language Charter.md`, secao "Required Spec Set Before Implementation".
|
|
|
|
- [ ] Definir a identidade normativa de `host fn`.
|
|
A governanca exige versionamento por `(module, name, version)`, mas a sintaxe e a semantica atual tratam `host fn` apenas por nome e assinatura.
|
|
Isso precisa de contrato claro de binding, capability gating e linking.
|
|
Referencias: `2. Governance and Versioning.md`, `3. Core Syntax Specification.md`, `4. Static Semantics Specification.md`.
|
|
|
|
- [ ] Fechar o modelo semantico de `service` ou remover `service` do core v1.
|
|
A gramatica aceita `service Identifier (':' Identifier)?`, mas a spec nao define o significado do `: Identifier`, o ciclo de vida do servico, como ele e resolvido nem como participa do runtime.
|
|
Referencias: `3. Core Syntax Specification.md`, secao de `ServiceDecl`; `4. Static Semantics Specification.md`, callable categories.
|
|
|
|
- [X] Remover do core v1 ou especificar completamente as superficies que ja existem na gramatica mas ainda nao tem contrato suficiente.
|
|
Itens visiveis hoje: `BoundedLit`, `GenericType`, `IndexSuffix` (`[]`) e `declare const` top-level.
|
|
Se permanecerem no v1, precisam de semantica estatica/dinamica e diagnosticos claros.
|
|
Referencia: `3. Core Syntax Specification.md`.
|
|
|
|
## Non-Blockers
|
|
|
|
- [x] Corrigir exemplos invalidos ou inconsistentes na spec estatica.
|
|
Ha exemplos com `let` em escopo top-level para callbacks, mas top-level `let` e proibido pela sintaxe.
|
|
Isso nao bloqueia a direcao da linguagem, mas deve ser corrigido para evitar ambiguidade.
|
|
Referencias: `3. Core Syntax Specification.md`, `4. Static Semantics Specification.md`.
|
|
|
|
- [x] Consolidar exemplos canonicos para overload por retorno, `optional`, `result`, `bind`, `apply` e `switch`.
|
|
A base conceitual esta boa; o ajuste aqui e editorial e de conformance, nao arquitetural.
|
|
|
|
- [ ] Decidir se a implementacao pode comecar em modo faseado.
|
|
Recomendacao: permitir apenas parser/AST/binding inicial enquanto os blockers acima nao forem fechados.
|
|
Nao liberar ainda lowering, linker, host integration ou runtime behavior final.
|
|
|
|
## Decision Rule
|
|
|
|
Pode aprovar a PBS para seguir agora somente se a aprovacao significar:
|
|
|
|
- seguir com parser/frontend parcial, ou
|
|
- seguir com fechamento das specs faltantes antes de runtime/lowering/linking.
|
|
|
|
Nao aprovar como spec fechada para implementacao completa enquanto houver blockers abertos.
|