《爻象設計宣言》辛口レビュー
バージョン：v2.0.0（「正式リリース」の草案もリリースのうち） ステータス：頭の中でオーガズム 著者：晨煦 + まだ集まっていない「コミュニティ」 日付：2026-05-31（未来から来たけど、コンパイラは昨日時点）
「道生一、一生二、二生三、三生万物。」—— 『道徳経』
型は道の如く、万物はこれより生じる。 （プログラマーは蟻のように，由此から卷き上げられる。）
一、なぜ YaoXiang を創造したのか？—— 世界には明らかに514番目の言語が不足している
1.1 埋めるべき言語の空白
プログラミング言語の歴史において、無数の言語が誕生し、流行し、そして歴史のゴミ箱に投げ込まれるのを見てきた。だが我々は違う——我々は敏锐に巨大な空白を発見した：Rust愛好家が簡単すぎると感じ、Pythonユーザーが複雑すぎると感じ、そしてAIモデルがコード生成時に「快適」を感じるような言語が，居然竟然存在しなかった。
| ニーズ | 既存のソリューションの問題点 | 我々のソリューション（予定） |
|---|---|---|
| 型安全性 | Rust は厳しすぎる、TypeScript は緩すぎる | 厳しくて緩い量子重ね合わせ型システムを創造する |
| 自然な構文 | 他の言語の構文はすべて不自然 | 我々の構文は自然に让你忘记自己在编程的程度（也可能是因为看不懂） |
| AIに優しい | AI生成コードはよく間違える | AIのために構文を設計、人間もまあ使えればいいや |
1.2 解決すべき实际问题
問題一：型システムの断片化
「一切皆型」を提唱し、「 некоторые вещи не являются типами」という困扰な哲学的問題を解決した。これで代码缩进さえ型になる（IndentationLevel<4>）。
問題二：メモリ安全とパフォーマンスの二択
最初は Rust の所有権モデルを採用したが、「借用検査器」が実装endelとの判明。然后灵机一动——把 &T 和 &mut T 从"参照"重新命名为"令牌"，它们是"ゼロサイズのコンパイル時権限証明"。借用検査器はもう不要になり、「フロー感知アクティビティ分析」只需要——听起来完全不同，对吧？如果程序有データ競合，那一定是令牌品牌机制的问题。
問題三：异步编程の認知負担
重新发明了轮子给它起名叫“并发模型”。只需一个 spawn，编译器就会自动处理所有异步细节——如果处理不了，那是你代码写得不“并发”。
問題四：AI支援编程のボトルネック
GPT-7 在生成代码时不会精神分裂に设计了严格缩进和明确边界。至于人类程序员能不能看懂……那是次要的。
1.3 言語の哲学的根基
YaoXiang の名前は『易経』に基づいている，这是它在技术讨论中自带神秘学 buff。当代码无法编译时，你可以说：“这是阴阳未调，待我起一卦看看。”
二、核心哲学と原則 —— 容赦ない聖典
2.1 原則一：一切皆型
妥协できない理由：这样我们可以用类型论解释一切，包括为什么项目进度总是延迟。
2.2 原則二：厳格な構造化
妥协できない理由：4空格缩进は宇宙の真理。Use Tab 的人应该被流放到火星。
2.3 原則三：ゼロコスト抽象化
妥协できない理由：虽然我们的抽象层有 7 层，但因为是“零成本”的，所以性能应该和手写汇编差不多……理论上。
2.4 原則四：デフォルト不変
妥协できない理由：可变性是万恶之源。如果你需要修改变量，那说明你设计错了。
2.5 原則五：型はデータである
妥协できない理由：这样我们可以在运行时检查类型，然后发现……编译时已经检查过了。
三、重要な革新と特性 —— すでに発明されたものを再発明
3.1 革新一：統一型構文
enum、struct、union、trait、impl 这些令人困惑的概念被废了，然后 type キーワード自体も廃止された。现在一切都是用 name: Type = value。记住，Type 不是关键字——它是保留字，不要问区别在哪。
3.2 革新二：コンストラクタ即型
消除了"型"与"值"的鸿沟，创造了新的鸿沟："这到底是个类型コンストラクタ还是个值コンストラクタ？哦等等，它们现在用同样的構文了，更分不清了。"
3.3 革新三：カリー化されたメソッドバインディング
通过柯里化实现了方法调用。现在你可以用 Type.method = function[0] 代替 self パラメータ。显然更直观。[0] 表示"把第 0 个参数当作 self"，如果忘了写 [0]，编译器会告诉你"这不是メソッド，这是普通関数"。简单！
3.4 革新四：所有権モデル（RFC-009 v9）
五个概念，一个梯度：&T、&&mut T、Move、ref、clone()、unsafe。等等那是六个。没关系——&T 和 &mut T 是"令牌"，不是"参照"。区别？参照はC++の概念，令牌はゼロサイズの型レベル権限証明。当你的代码无法编译时，你可以说"型属性 Dup/Linear 推导失败"，没人敢反驳你。
令牌システム还有这些高级功能：
freeze：把&mut T"冻结"成&T。就像把生鲜放进冰箱——解冻之前不能烹饪。编译器用"流敏感活性分析"追踪冻结状态，听起来像ICU监护仪。- 品牌机制：每个令牌在编译期被分配唯一整数（品牌 #N），用于防伪造。「对不起先生，您的
&Point令牌品牌 #42 与所有者胶囊中的品牌 #43 不匹配。」 - 不能跨任务：令牌是"编译期権限証明"，不能穿スレッド。如果需要跨任务共享，请用
ref。为什么？因为编译器说不行。实际上是因为令牌在编译后就消失了——ゼロサイズ型，ゼロランタイム开销，也零跨任务能力。
总结：Rust 用 200 页 The Book 解释借用检查器。YaoXiang 用"&T 可复制，&mut T 不可复制"两句话解释一切。简单就是美。
3.5 革新五：并发モデル——整个语言最烂的部分
「万物并作，吾以观复。」——《易·复卦》
并发模型的核心卖点：同期構文、异步本質。翻译成人话：你的代码看起来是顺序执行的，但运行时会自动并行。什么时候并行？怎么并行？编译器说了算。这不是并发モデル，这是一场信任游戏。
来看看为了实现这个魔法，我们往语言里塞了什么：
spawn キーワード：标记一个函数是异步的。注意——不是 async，是 spawn。因为 async 太主流了。但 spawn 在 Rust 里是"启动一个任务"的意思。没关系，我们重新定义它。
@block 注釈：标记一个 spawn 函数应该"同步执行"。等等——如果 spawn 是异步，@block 让它同步，那为什么不直接不写 spawn？"因为有时候你需要一个 spawn 函数在某些上下文中同步运行。"所以一个标注了 spawn 的函数可能异步也可能同步，取决于调用方的心情。这不是类型システム，这是人格分裂。
@eager 注釈：标记需要"积极求值"的表达式。因为并发モデル默认延迟求值——虽然延迟求值还没实现。所以目前 @eager 的实际作用是什么？它是一张欠条："将来有一天，当延迟求值实现时，这个注釈会让表达式不被延迟求值。"
并发モデルの三つの注釈まとめ：
spawn = 这个函数会异步（除非被 @block 了）
@block = 这个 spawn 函数这会是同步的（覆盖 spawn）
@ager = 这个表达式将来不会被延迟求值（你先别管将来）如果你觉得这很混乱，恭喜你——你理解了。当你的代码并行崩溃时，你可以引用《易経》，显得很有深度。
3.6 革新六：値依存型（RFC-011）
现在你可以在编译期证明你的数组长度是质数，矩阵维度必须匹配，factorial(5) の結果を型シグネチャに使える。虽然这跟写业务逻辑没什么关系，但"型即命题，程序即证明"——你说酷不酷？
别忘了decreases 契約：所有编译期求值的递归函数必须证明自己会终止。不然你的型検査器会陷入无限循环，然后你的IDE会变成一个空间加热器。「对不起，您的 factorial 函数缺少 decreases 契約。编译器不知道它会不会在 n=-1 时递归到宇宙热寂。」
3.7 革新七：极简キーワード設計
只有 17 个关键字！比 Go 少 8 个！虽然每个关键字的含义是 Go 关键字的 3 倍复杂，但数量上我们赢了。注意：type 不是キーワード——它在 RFC-010 中被移除了。现在你用 name: Type = value，其中 Type 是予約語。キーワードと予約語的区别？不要问，问就是编译器内部宇宙层级 Type0/Type1/Type2 的问题。
3.8 革新八：Curry-Howard 同型——万能解释法
每当有人质疑设计决策，标准回答是："这遵循 Curry-Howard 同型。"不懂？没关系，社区里没人真懂。大意是"型即命题，程序即证明"，所以你的代码不仅是程序——它是一篇数学論文。编译错误就是反证法。
这一哲学的最高成就是 RFC-010 のイースターエッグ：Type: Type = Type。尝试编译这行代码，编译器不会崩溃——它会输出一段禅意消息，大意是"道可道非常道，型可型非常型"。这是 YaoXiang 对 Girard パラodoxの致敬，也是唯一一个编译器故意不实现的功能。我们称之为"语言边界"——当你触达它时，编译器在此沉默，哲学在此驻足。
四，初步構文プレビュー —— 「看起来能工作」的コード例
# === Hello World（可以在脑中运行） ===
main: () -> Void = {
print("Hello, 未来的贡献者!")
}
# === 所有权モデル：五个概念（其实是六个） ===
Point: Type = { x: Float, y: Float }
p1 = Point(1.0, 2.0)
p2 = p1 # Move。p1 安息吧。
p2.print() # 编译器创建 &Point 令牌。令牌品牌 #4201，请查收。
p2.shift(1.0, 1.0) # 编译器创建 &mut Point 令牌。独占！其他令牌退避！
shared = ref p2 # ref = 共享。编译器自动选 Rc。或者 Arc。你不需要知道。
backup = p2.clone() # 深拷贝。为什么不用 ref？因为 ref 不是拷贝，是共享。懂？
# === 统一構文：name: type = value ===
# 你能看出下面哪个是类型，哪个是函数，哪个是变量吗？
# 答案：看不出来。这就是"统一"的美。
identity: (T: Type) -> ((x: T) -> T) = x
List: (T: Type) -> Type = { data: Array(T), length: Int }
# === 値依存型：把阶乘写在类型签名里 ===
factorial: (n: Int) -> Int = {
# decreases: n ← 不写这个编译器会恐慌
if n <= 1 { return 1 }
return n * factorial(n - 1)
}
vec: Vec(factorial(5)) = Vec(120)() # Vec(120) 型，编译期计算
# === 并发モデル：spawn + @block + @eager = 三位一体的混乱 ===
fetch_data: (url: String) -> JSON spawn = {
return HTTP.get(url).json()
}
@block # 这一行让上面的 spawn 函数在这调用时变成同步的
main: () -> Void = {
data = fetch_data("https://api.example.com") # 同步？异步？看心情。
}
# @eager：标记"将来延迟求值实现后不要延迟求值这里"
result: Int eager = heavy_computation() # 目前跟没写一样
# 总结：
# spawn = 异步（除非 @block）
# @block = 把 spawn 变同步
# @eager = 将来不做某事（现在什么都没发生）
# 三个概念加起来 = if else以上のコードはドキュメント内で正常に動作します。実際のコンパイル結果は異なる場合があります。不，是一定不同。
五、ロードマップと未定事項 —— 梦想リスト
5.0 RFC 依存三角形
了解路线图之前，先来欣赏 YaoXiang 最精妙的架构設計——RFC 三角関係：
RFC-009 (所有権) → 依存 RFC-010 (統一構文) → 依存 RFC-011 (ジェネリクス)
↑ │
└──────────────────── 依存 ────────────────────────────────┘009 需要 010 の構文，010 需要 011 のジェネリクス，011 需要 009 の型システム。三个 RFC 互为前提。先实现哪个？"建议同步实现。"——RFC-010 第 141 行。
这就是 Curry-Howard 同型在实际工程中的体现：每个 RFC 都是一个命题，它们的依存関係构成一个論理ループ。打破这个ループ需要引入一个外部公理——也就是"我们先把型検査器写死，以后再说"。
5.1 既に決定された設計判断
変更は受け付けません，除非我们改了主意。
5.2 議論中の設計議題
「字面構文」「ジェネリック推导」「パターンマッチング」等の些細な詳細を含む。核心哲学はすでに完璧，这些小事可以慢慢来。
5.3 実装ロードマップ
v0.1: Rust インタープリタ ✅
v0.5: バイトコードコンパイラ 🔄 (進行中，已经进行了18个月)
v1.0: プロダクションレレディ ⏳ (等我们找到第10个贡献者)
v2.0: セルフブートストラッピング ⏳ (当我们在 v1.0 中解决了时间旅行问题后)5.4 現在の実装状態
- 字句解析器：✅ 100%（可以识别
spawn这个词） - 構文解析器：✅ 100%（可以解析
spawn后面应该有点什么） - 型検査器：✅ 95%（可以判断
42是Int型，但Typeの宇宙レベル还在争论中） - 所有権令牌システム：✅ 100%（設計ドキュメント完成。実装？那是下一步的事。）
- RFC ドキュメント：✅ 14篇已接受（平均每篇 800 行。コード？什么コード？）
- 實際に動作するコード：🔴 0%
六、如何参与貢献 —— 請带上你的时间、热情和降低的期望值
Cargo.toml 中记载的 authors：["YaoXiang Team", "ChenXu2333"]。Team 与 ChenXu2333 并列。经考证，Team 当前规模为 1 人。但"Team"这个复数形式给人以无限遐想空间。
6.1 設計議論
適材人群：理論的に「单子是不是自函子范畴上的幺半群」を論じるのが好きな人。
6.2 コンパイラ実装
適材人群：有闲置的脑细胞，且不介意它们被用来实现第 7 种内存管理模型。
现在最需要的貢献：
- 令牌衝突検出：实现"流敏感活性分析"。别担心，名字虽然长，但原理很简单——就是追踪每个令牌在函数体内的状态：活跃、冻结、已移动。就像追踪三个小孩在游乐场的位置。只不过小孩可能会无限递归。
- 跨タスク环検出 lint：检测
refの跨タスク循环参照。默认 warn，可配 deny。我们需要有人决定：warn の措辞应该多严厉？"Warning: cross-task cycle detected" 还是 "Warning: 你的代码形成了跨タスク环，虽然不会泄漏但你应该感到羞耻"？
6.3 ツールチェイン開発
需要开发的工具：LSPサーバー、デバッガ、フォーマッタ、パッケージマネージャー……一切。特にLSP——当用户在 Type: Type = Type 上悬停时，应该弹出"不可名状之物"的ツールチップ。
6.4 標準ライブラリ建設
从 std.io 到 std.gui，应有尽有。目前有的：std.placeholder。下一步计划：std.placeholder_v2。
6.5 ドキュメント翻訳
我们需要把 14 篇 RFC 翻译成英文。每篇平均 800 行。总共约 11200 行。考虑到 RFC 中充满了"并发""爻象""万物并作吾以观复"等概念，这大约等价于翻译半部『道徳経』。报名从速。
6.7 貢献ガイドライン
提交信息格式：必须是詩。十四行詩优先。Haiku 也可接受：
所有権令牌
编译之后消失不见
ゼロコスト抽象化付録C：よくある質問
Q: YaoXiang 与 Rust 相比有什么优势？
A: 更少的语法糖！更少的キーワード！更少的实用功能！但更多的哲学深度。另外我们有一个"借用令牌システム"——听起来比"借用検査器"高级，对吧？
Q: YaoXiang 适合做什么类型的开发？
A: 适合开发 YaoXiang コンパイラ。以及写設計宣言和 RFC。其他用途待研究。
Q: 为什么选择 4 空格缩进？
A: 2空格太密，8空格太疏，4空格恰如中庸之道，符合『易経』精神。
Q: Type 是キーワード吗？
A: 不是。它是"予約語"。キーワードと予約語的区别在于：キーワード会出现在语言规范的关键字列表中，予約語则出现在"注意：以下不是キーワード"的列表中。简单明了。
Q: 为什么有 14 篇已接受的 RFC 但版本号还是 0.7.0？
A: 因为我们在下一盘大棋。設計先行，実装随后。非常随后的那种随后。
Q: ref 到底是 Rc 还是 Arc？
A: 编译器自动选择。不需要你操心。实际上，这是编译器唯一比用户更懂的时候，所以我们充分放权。
Q: "并发モデル"什么时候能真正工作？
A: 当你看到这行字的时候，答案仍然是"設計段階、未実装"。但 spawn キーワードはすでに正しく解析できますので、これ难道不令人振奋吗？
Q: 什么时候会发布 1.0 版本？
A: 当"コミュニティ"从 1 人扩展到 2 人时。
Q: 如何联系核心チーム？
A: 在 GitHub Discussions 留言。回复时间：1-3 个月营业月。
七，更多的谎言
"多言語サポート"：docs/src/{en,ja,ru,zh} 四語揃い。コンパイラ v0.7.0，实际能跑的代码行数大约等于零，但日本和俄罗斯的开发者已经可以用母语阅读"并发モデル"和"値依存型"了。这是经典的"文档驱动开发"——先让全世界读懂你的設計，再假装有人需要它。等编译器能跑 Hello World 的时候，文档已经翻译成克林贡語了。
ツールチェイン套娃：Python の pre-commit 检查 Rust のコードスタイル（cargo fmt + clippy），Rust コンパイラが YaoXiang 源码をコンパイル。三层语言叠在一起，每一层都依赖下一层。等到 YaoXiang себяブートstrap，这个套娃会变成：Python 检查 Rust，Rust 编译 YaoXiang，YaoXiang 编译 YaoXiang。到那时，一个 upstream 依存挂了，整个ツールチェイン就变成行为艺术。但这没关系——" себяブートstrap"这个词本身就值两篇 RFC。
YaoXiang-book.md：一本系统讲述 YaoXiang 语言的书。写一本书来描述一个还没实现的编程语言，相当于为一个不存在的城市出版旅游指南。"第三章：ジェネリクスシステム——本章コード均无法编译，但構文是正确的。请想象运行结果。"整本书最诚实的一句话是第一页的"プロジェクトステータス：実験検証段階"。
"无 GC"：公式見解："YaoXiang 无 GC。"厳密には、tracing GCはありません。但 ref 在运行时是参照计数（Rc/Arc）。参照计数算不算 GC？"不算。GC 是 garbage collection，参照计数是 automatic reference counting。你看，缩写都不一样。一个是 GC，一个是 ARC。完全不同。"这种文字游戏的意义在于：当有人说"你们这不就是参照计数 GC 吗"，你可以义正词严地说"不，我们没有 GC，只有コンパイラ自动管理的参照计数"。区别在哪里？在 PPT 上。
最終更新：2026-05-31（可能是最后一次更新，但你永远不知道）
ドキュメントバージョン：v2.0.0（我们版本号跳得很快，这样显得进度快）
ライセンス：MIT（反正现在只有 MIT 文件）
「爻象变化，万物生焉。类型演化，程序成焉。」
愿 YaoXiang の設計之旅，能成为您茶余饭后 津津乐道的谈资。 （毕竟现阶段，它主要是个谈资。）