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

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

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

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

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

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