hum-lang

Hum é um rascunho de design em estágio inicial (0.0.1 pré-alfa) para uma linguagem de programação de sistemas. Seu objetivo declarado é combinar o poder de baixo nível ao estilo Rust/C++ com legibilidade semelhante a Python, tipos estáticos, efeitos explícitos, segurança de memória por padrão e contexto gerado pelo compilador voltado tanto para humanos quanto para agentes de programação. A ideia central é que contratos normalmente escritos como comentários se tornem promessas verificadas. Uma tarefa pode declarar seções como `why`, `targets`, `uses`, `changes`, `needs`, `ensures`, `protects`, `trusts`, `fails when`, `watch for`, `cost`, `allocates`, `avoids`, `tradeoffs`, `optimizes`, `tests` e `does`. O repositório inclui um fixture deliberadamente sabotado cujo `ensures: result == a + b` é violado por um corpo `return a - b`; executá-lo produz um diagnóstico que responsabiliza a implementação da tarefa, não o chamador. Palavras de posse (`borrow`, `change`, `consume`) também são tratadas como promessas verificadas. As visões locais são estreitas: emprestar um campo é invalidado por uma escrita posterior nesse campo, e emprestar um elemento de lista é invalidado por crescimento posterior. Uma forma de alias gravável (`let alias = change record.field`) escreve através e permanece ativa apenas até seu último uso sintático em linha reta. Uso após movimentação é reportado com o local da movimentação nomeado. `old(...)` captura o valor de um parâmetro na entrada da tarefa, de modo que uma troca que nunca troca é capturada pelo próprio contrato. O README é explícito sobre os limites: linhas `cost:`, `allocates:`, `protects:` e `trusts:` são intenção registrada, fatos de grafo e obrigações geradas hoje, não provas impostas. Os relatórios do verificador emitem uma lista explícita de não-afirmações para que a fronteira entre verificado e declarado permaneça visível. Status: um front-end de compilador bootstrap em Rust do Marco 0, com a execução do Marco 1 iniciada via `hum run` interpretando os primeiros fixtures do Formal Core. A primeira fatia nativa canônica é `programs/integer_sign.hum`, executada com `hum run --native --allow stdout.write ... --args -7`, que verifica o código-fonte, valida fatos do backend e imprime através do Cranelift em hosts Windows e Linux suportados. O README descreve isso como uma forma de programa limitada, não como compilação nativa geral. O repositório é rico em documentação: arquitetura, referência da linguagem, gramática, esquemas para superfície sintática, capacidades, fatos de alvo, relatórios de evidência, obrigações matemáticas, relatórios de recursos, contrato/pré-visualização/rebaixamento/verificação do Core Hum, verificações de tipo/efeito/posse/recurso, contrato e prontidão de IR, entrada/sonda/contrato de backend, capacidades de LSP, doctor, além de registros de decisão, modelo de segurança, política de unsafe, interoperabilidade e portabilidade, modelo de segurança de memória, estratégia de tempo de compilação, estratégia de stdlib, perfis de runtime, estratégia de backend, roteiro, governança e notas de pesquisa. O ferramental inclui uma gramática TextMate, um formatador planejado (`humfmt`), um plano de gerenciador de pacotes (Nectar) e comandos de CLI como `check`, `version`, `explain`, `diagnostics`, `capabilities`, `target-facts`, `core-contract`, `core-preview`, `core-lower`, `core-verify` e `full-type-check`, vários com saída JSON. O compilador bootstrap é escrito em Rust e nega código unsafe por padrão, com uma fronteira de invocação JIT unsafe revisada e permitida localmente e cinco dependências Cranelift fixadas. O Cargo é o caminho atual de build e instalação, embora o README observe que Hum não deve ser posicionado como "apenas um crate Cargo" a longo prazo.