hum-lang

Hum 是一门系统编程语言的早期（0.0.1 pre-alpha）设计草案。其既定目标是将 Rust/C++ 风格的底层能力与 Python 式的可读性相结合，同时具备静态类型、显式效应、默认内存安全，以及面向人类和编码代理的编译器生成上下文。 核心理念是：通常以注释形式编写的契约，将变成可检查的承诺。一个任务可以声明诸如 `why`、`targets`、`uses`、`changes`、`needs`、`ensures`、`protects`、`trusts`、`fails when`、`watch for`、`cost`、`allocates`、`avoids`、`tradeoffs`、`optimizes`、`tests` 和 `does` 等区段。仓库中包含一个刻意植入错误的测试样例，其 `ensures: result == a + b` 被 `return a - b` 的函数体违反；运行它会生成一条诊断信息，将责任归咎于任务实现而非调用方。 所有权关键词（`borrow`、`change`、`consume`）同样被视为可检查的承诺。局部视图是狭窄的：借用某个字段后，对该字段的后续写入会使借用失效；借用列表元素后，列表的后续增长会使借用失效。可写别名形式（`let alias = change record.field`）会穿透写入，并且仅在其最后一个直线式语法使用点之前保持有效。移动后使用会被报告，并指明移动发生的位置。`old(...)` 会在任务入口处捕获参数的值，因此一个从未真正交换的 swap 会被其自身的契约捕获。 README 明确说明了限制：`cost:`、`allocates:`、`protects:` 和 `trusts:` 这些行目前是记录的意图、图事实和生成的义务，而非强制执行的证明。检查器报告会输出一份明确的非声明列表，以便让已检查与已声明之间的边界保持可见。 状态：Milestone 0 的 Rust 引导编译器前端已完成，Milestone 1 的执行已通过 `hum run` 解释首批 Formal Core 测试样例而启动。第一个规范的原生切片是 `programs/integer_sign.hum`，通过 `hum run --native --allow stdout.write ... --args -7` 运行，它会检查源代码、验证后端事实，并在受支持的 Windows 和 Linux 主机上通过 Cranelift 打印输出。README 将此描述为一种有界的程序形态，而非通用的原生编译。 仓库以文档为主：包括架构、语言参考、语法、语法表面模式、能力、目标事实、证据报告、数学义务、资源报告、Core Hum 的 contract/preview/lower/verify、类型/效应/所有权/资源检查、IR 契约与就绪状态、后端输入/探测/契约、LSP 能力、doctor，以及决策记录、安全模型、unsafe 策略、互操作与可移植性、内存安全模型、编译期策略、标准库策略、运行时配置、后端策略、路线图、治理和研究笔记。工具方面包括 TextMate 语法、计划中的格式化工具（`humfmt`）、包管理器计划（Nectar），以及诸如 `check`、`version`、`explain`、`diagnostics`、`capabilities`、`target-facts`、`core-contract`、`core-preview`、`core-lower`、`core-verify` 和 `full-type-check` 等 CLI 命令，其中若干命令支持 JSON 输出。 引导编译器使用 Rust 编写，默认拒绝 unsafe 代码，仅有一个经过审查、在局部允许的 unsafe JIT 调用边界，以及五个固定版本的 Cranelift 依赖。Cargo 是当前的构建和安装路径，不过 README 指出，长期来看 Hum 不应被定位为“只是一个 Cargo crate”。