RFC-003：版本规划
拒绝日期: 2026-06-01
⚠️ 拒绝原因
本 RFC 不符合 RFC 规范，已被拒绝。
问题分析
| 问题 | 说明 |
|---|---|
| 文档类型错误 | RFC 是关于"为什么这样设计"的决策文档，本文是"现在在哪里、要去哪里"的项目管理文档 |
| 缺乏设计决策 | 没有技术选型的权衡分析，没有替代方案比较，没有设计理由 |
| 过度规划 | 规划了 9 个版本（v0.1-v1.0），但只完成了 1.5 个，v0.3 以后都是推测 |
| 维护成本高 | 成功指标表有 50 个状态，难以维护 |
| 版本号混乱 | 跳过 v0.8，没有解释 |
正确的文档类型
本文档应作为**项目路线图（Roadmap）**管理，而非 RFC。路线图记录事实和短期计划，RFC 记录设计决策。
以下为原始内容，保留供参考。
摘要
YaoXiang 的版本发布计划，从 v0.1 到 v1.0 的路线图。
核心目标：
- 字节码编译：支持 REPL 和渐进式编译
- 自举 (Bootstrap)：使用 YaoXiang 编写 YaoXiang 编译器
- AOT 编译：字节码编译为本地机器码
一、动机
为什么需要版本规划？
- 项目管理：将目标分解为可执行的里程碑
- 用户预期：让用户了解语言的发展阶段
- 资源分配：明确每个阶段的重点
- 风险控制：及时发现问题并调整方向
核心设计决策
- 字节码优先：先实现解释执行，再考虑 AOT
- 渐进式交付：每个版本都有可用功能
- 向后兼容：v1.0 前 API 可能变更，但会提前公告
- 自举验证：通过自举证明语言表达能力
- 性能分层：先跑通，再优化
二、组件状态 (Phase)
| Phase | 模块 | 状态 | 位置 | 最后更新 |
|---|---|---|---|---|
| P1 | 词法分析器 | ✅ 完成 | src/frontend/lexer/ | 2025-01-23 |
| P2 | 类型检查器 | ✅ 完成 | src/frontend/typecheck/ | 2025-01-23 |
| P3 | 字节码生成器 | ✅ 完成 | src/middle/codegen/ | 2025-01-25 |
| P4 | 虚拟机 | ✅ 完成 | src/middle/ | 2025-01-25 |
| P4.1 | 任务系统 | ✅ 完成 | src/backends/runtime/task.rs | 2025-01-23 |
| P4.2 | DAG调度器 | 🔶 设计完成 | .claude/plan/flow-scheduler-implementation.md | 2026-01-04 |
| P5 | 标准库 | ⚠️ 部分完成 | src/std/ | 2025-01-23 |
| P6 | TUI REPL | ✅ 完成 | src/backends/dev/repl/ | 2025-01-24 |
| P7 | 泛型系统 | ✅ 完成 | docs/design/rfc/011-generic-type-system.md | 2025-01-25 |
核心成就：
- ✅ 编译器前端完整实现（P1-P2）
- ✅ 字节码生成与虚拟机完成（P3-P4）
- ✅ 基础任务系统完成（P4.1）
- ✅ TUI REPL 开发完成（P6）
- ✅ 泛型系统设计完成（P7）
下一步优先：实现 FlowScheduler 调度器 → 完善标准库（P5）→ v0.1 发布
三、版本路线图
v0.1：可运行里程碑 ✅
状态：基本完成（2025-01-25）
已完成：
- ✅ 词法分析、语法分析、类型检查完整
- ✅ 字节码生成可用
- ✅ 虚拟机能解释执行基本程序
- ✅ 基础 print 函数
- ✅ TUI REPL 完成
- ✅ 基础任务系统（Task/Scheduler）
$ yaoxiang run hello.yx
Hello, YaoXiang!技术亮点：
- 三层运行时架构设计完成
- 任务系统完整实现
- TUI REPL 现代化界面
- 统一类型语法 + 泛型系统设计
未包含：完整 DAG 调度（基础调度器已实现）
v0.2：FlowScheduler 调度器 🚧
目标：实现完整的依赖感知调度器
- ✅ 设计文档完成
- 🔶 实现进行中
- [ ] DAG 节点与图实现
- [ ] 工作窃取算法
- [ ] libuv IO 调度引擎
- [ ] 惰性求值策略
- [ ] spawn 语法支持
技术重点：
- FlowScheduler 架构实现
- 工业级 IO 调度（libuv）
- 零成本抽象
v0.3：并发预览 📋
目标：支持基础并发
- DAG 任务依赖图
- 基础调度器
- spawn 并发
v0.4：泛型系统 📋
目标：完整泛型能力
- [ ] RFC-011 Phase 1：基础泛型
- [ ] RFC-011 Phase 2：类型约束
- [ ] RFC-011 Phase 3：关联类型
- [ ] RFC-011 Phase 4：Const 泛型
- [ ] RFC-011 Phase 5：条件类型
技术重点：
- 死代码消除
- 零成本抽象
- 函数重载 + 内联优化
v0.5：标准库完善 📋
目标：可用性提升
- IO、字典、网络模块
- 工具链（fmt、基础 LSP）
- 性能优化
v0.6：错误处理系统 📋
目标：完整错误处理
- [ ] RFC-001 实现
- [ ] Result 类型系统
- [ ] 错误图可视化
- [ ] DAG 错误传播
v0.7：稳定版本 📋
目标：API 趋于稳定
- 完整文档
- 工具链完善
- 边界情况修复
v0.9：自举开始 📋
目标：核心模块用 YaoXiang 重写
- Lexer → Parser → TypeChecker → Codegen 逐步替换
- 交叉验证：两个编译器结果一致
v1.0：生产可用 📋
目标：稳定发布
- 完整自举
- AOT 编译（LLVM 后端）
- 生产可用
四、编译策略三层设计
| 层级 | 版本 | 输入 | 输出 | 说明 |
|---|---|---|---|---|
| L1: 字节码 | v0.1+ | 源码 (.yx) | 字节码 (.yxb) | VM 解释执行 |
| L2: 自举 | v0.9+ | YaoXiang 源码 | 字节码 | 自己编译自己 |
| L3: AOT | v1.0+ | 源码/字节码 | 机器码 | 原生性能 |
字节码优先的理由：
- REPL 支持：即时编译输入代码，交互式开发
- 渐进式编译：修改单个函数只需重新编译该部分
- 平台无关：.yxb 文件跨平台运行，只需对应平台的 VM
五、依赖策略
短期：调用 Rust 库复用 crates.io（Cargo 寄生）
当前依赖：
- 并发：parking_lot, crossbeam, rayon
- 数据结构：indexmap, hashbrown, smallvec
- 网络：tokio
- 序列化：serde, ron
长期：自建标准库和包管理器
六、工具链
| 版本 | 工具 | 状态 |
|---|---|---|
| v0.1 | yaoxiang-cli | ✅ 已完成 |
| v0.1 | TUI REPL | ✅ 已完成 |
| v0.2 | yaoxiang-debug | 🚧 设计中 |
| v0.3 | yaoxiang-fmt | 📋 计划中 |
| v0.3 | yaoxiang-lsp (基础) | 📋 计划中 |
| v0.5 | yaoxiang-clippy | 📋 计划中 |
| v1.0 | 完整工具链 | 📋 计划中 |
七、成功指标
| 指标 | v0.1 | v0.2 | v0.3 | v0.5 | v1.0 |
|---|---|---|---|---|---|
| 端到端运行 | ✅ | ✅ | ✅ | ✅ | ✅ |
| 基础任务系统 | ✅ | ✅ | ✅ | ✅ | ✅ |
| FlowScheduler | ❌ | 🚧 | ✅ | ✅ | ✅ |
| 并发支持 | ⚠️ | 🚧 | ✅ 基础 | ✅ 完整 | ✅ |
| 标准库 | 基础 | 基础 | 基础 | 完善 | 完整 |
| 泛型系统 | ⚠️ | ⚠️ | 🚧 | ✅ | ✅ |
| TUI REPL | ✅ | ✅ | ✅ | ✅ | ✅ |
| 自举 | ❌ | ❌ | ❌ | ❌ | ✅ |
| AOT | ❌ | ❌ | ❌ | ❌ | ✅ |
| 代码覆盖率 | 60% | 70% | 80% | 90% | 95% |
图例：
- ✅ 已完成
- 🚧 进行中
- ⚠️ 部分完成
- 📋 计划中
八、开放问题
- [ ] JIT vs AOT 时机选择
- [ ] 包管理器设计
- [ ] 自举模块替换顺序
- [ ] AOT 后端选型（LLVM vs 自研）
九、版本发布标准
v0.x 系列：
- 功能完整但可能存在边界情况问题
- API 可能变更
- 仅供学习和试验
v1.0：
- 所有核心功能稳定
- API 冻结
- 适合生产使用
- 完整的文档和教程