2026-03-24 13:42:16 +00:00

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 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.

  • 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

  • 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.

  • 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.