71 lines
4.9 KiB
Markdown
71 lines
4.9 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
|
|
|
|
- [X] Fechar o gate de prontidao para implementacao definido no charter para o escopo atual.
|
|
Decisao: a aprovacao atual cobre apenas implementacao faseada de frontend (`parser`, `AST` e `binding` inicial).
|
|
Isso fecha o gate apenas para esse escopo limitado e nao reclassifica a PBS como pronta para implementacao completa.
|
|
Dynamic semantics, memory and lifetime, diagnostics, IR/lowering e conformance permanecem como trabalho aberto para fases posteriores.
|
|
Referencia: `1. Language Charter.md`, secao "Required Spec Set Before Implementation".
|
|
|
|
- [X] Substituir o antigo modelo publico de `host fn` por `declare host` reservado a SDK/toolchain.
|
|
Resolvido no nivel de charter, sintaxe e semantica estatica: bindings canonicos de host nao sao authorados pelo usuario comum, e superficies SDK usam `declare host` reservado.
|
|
O contrato de PBX/load/runtime continua pendente para a futura Host ABI Binding specification.
|
|
Referencias: `1. Language Charter.md`, `2. Governance and Versioning.md`, `3. Core Syntax Specification.md`, `4. Static Semantics Specification.md`, `5. Manifest, Stdlib, and SDK Resolution Specification.md`.
|
|
|
|
- [X] Fechar a spec normativa de manifest/module/package/stdlib.
|
|
Resolvido com o modelo normativo de `project` e `module`, enderecamento canonico `@project:path/to/module`, `stdlib` como ambiente efetivo do build, `@sdk:*` e `@core:*` como project spaces reservados, interface modules PBS-like e atributos reservados de compile time como `[Host(...)]`.
|
|
Referencias: `5. Manifest, Stdlib, and SDK Resolution Specification.md`, `6. Host ABI Binding and Loader Resolution Specification.md`.
|
|
|
|
- [X] Fechar o modelo semantico de `service` no core v1.
|
|
Resolvido com `declare service` como singleton nominal por modulo, exportado via barrel, com metodos sem visibilidade independente e suporte a `implements Contract for Service using s`.
|
|
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.
|
|
|
|
- [X] Decidir se a implementacao pode comecar em modo faseado.
|
|
Decisao tomada: permitir apenas parser/AST/binding inicial nesta etapa.
|
|
Nao liberar ainda lowering, linker, host integration ou runtime behavior final.
|
|
|
|
## Pautas Dedicadas
|
|
|
|
- [ ] Abrir pauta dedicada para dynamic semantics + memory and lifetime.
|
|
Objetivo: fechar o modelo de execucao observavel, ordem de avaliacao, traps, efeitos sobre `optional`/`result`/`apply`/`bind`/`switch`, baseline GC, fronteira heap VM vs memoria do host e visibilidade de custo/alocacao.
|
|
Resultado esperado: material para futura `Dynamic Semantics Specification` e `Memory and Lifetime Specification`.
|
|
Referencia: `Heap Model - Discussion Agenda.md`.
|
|
|
|
- [ ] Abrir pauta dedicada para validar se a `Host ABI Binding and Loader Resolution Specification` atual ja satisfaz o gate da fase seguinte ou se ainda precisa deixar de ser "Temporary".
|
|
Objetivo: confirmar se o contrato atual de `declare host` -> metadata PBX -> loader -> syscall numerico ja esta suficientemente estavel para nao bloquear a etapa posterior.
|
|
Resultado esperado: decisao explicita de "suficiente para a proxima fase" ou lista curta de endurecimentos pendentes.
|
|
Referencia: `6. Host ABI Binding and Loader Resolution Specification.md`.
|
|
|
|
- [ ] FUTURO: abrir pauta de backend.
|
|
Objetivo: tratar IR/lowering, linker, host integration, runtime behavior final e conformance somente depois de fechar o frontend e aparar as arestas da linguagem/spec.
|
|
Resultado esperado: backlog da etapa de backend com precondicoes claras.
|
|
Esta pauta nao bloqueia o frontend faseado atual.
|
|
|
|
## 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.
|