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,ASTebindinginicial). 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 fnpordeclare hostreservado 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 usamdeclare hostreservado. 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
projectemodule, enderecamento canonico@project:path/to/module,stdlibcomo 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
serviceno core v1. Resolvido comdeclare servicecomo singleton nominal por modulo, exportado via barrel, com metodos sem visibilidade independente e suporte aimplements Contract for Service using s. 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. 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 futuraDynamic Semantics SpecificationeMemory and Lifetime Specification. Referencia:Heap Model - Discussion Agenda.md. -
Abrir pauta dedicada para validar se a
Host ABI Binding and Loader Resolution Specificationatual ja satisfaz o gate da fase seguinte ou se ainda precisa deixar de ser "Temporary". Objetivo: confirmar se o contrato atual dedeclare 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.