2.8 KiB
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 tratamhost fnapenas 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
serviceou removerservicedo core v1. A gramatica aceitaservice 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 deServiceDecl;4. Static Semantics Specification.md, callable categories. -
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([]) edeclare consttop-level. Se permanecerem no v1, precisam de semantica estatica/dinamica e diagnosticos claros. Referencia:3. Core Syntax Specification.md.
Non-Blockers
-
Corrigir exemplos invalidos ou inconsistentes na spec estatica. Ha exemplos com
letem escopo top-level para callbacks, mas top-levellete 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. -
Consolidar exemplos canonicos para overload por retorno,
optional,result,bind,applyeswitch. 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.