《YaoXiang 設計宣言》辛口レビュー
バージョン: v2.0.0（結局「正式リリース」と銘打った草稿もリリースのうち） ステータス: 脳内絶頂 著者: 晨煦 + まだ集まっていない「コミュニティ」 日付: 2026-05-31（未来からの便り、されどコンパイラは昨日にて止まる）
「道は一を生じ、一は二を生じ、二は三を生じ、三は万物を生ず。」——『道徳経』
型は道のごとく、万物は皆これより生ず。 （プログラマは蟻のごとく、皆これに翻弄される。）
一、なぜ YaoXiang を創るのか？—— 世界に明らかに欠けている 514 番目の言語
1.1 埋める言語の空白
プログラミング言語の歴史において、無数の言語が生まれ、流行し、そして歴史のゴミ箱へ投げ込まれるのを目の当たりにしてきた。だが我々は違う——我々は鋭く驚くべき空白に気づいた：Rust 愛好家には簡単すぎると感じさせ、Python ユーザーには複雑すぎると感じさせ、しかも AI モデルがコード生成時に「心地よい」と感じさせる言語が一つとしてない。
| ニーズ | 既存ソリューションの問題 | 我々のソリューション（予定） |
|---|---|---|
| 型安全性 | Rust は厳しすぎ、TypeScript は緩すぎる | 厳格かつ緩やかな量子重ね合わせ型システムを創る |
| 自然な構文 | 他所の構文はどれも不自然 | 構文は自然すぎてプログラミングしていることを忘れる（読めないせいかもしれない） |
| AI フレンドリー | AI 生成コードはよく間違える | AI 向けに構文を設計し、人間はついでに使えるようにする |
1.2 解決する実問題
問題一：型システムの断片化
「全ては型である」というテーゼを掲げる。これにより「型でないものがある」という悩ましい哲学的問題が解決された。今やコードのインデントすら型（IndentationLevel<4>）になり得る。
問題二：メモリ安全性と性能の二者択一
我々は当初 Rust の所有権モデルを採用したが、「借用検査器」の実装が難しすぎることが判明。そこで名案が浮かんだ——&T と &mut T を「参照」から「トークン」に改名し、「ゼロサイズのコンパイル時権限証明」であると宣言した。もはや借用検査器は不要、「フロー敏感な活性度解析」さえあればよい——全く違って聞こえるだろう？プログラムにデータ競合があるなら、トークンのブランド機構に問題があるのだ。
問題三：非同期プログラミングの認知負荷
車輪を再発明し、「spawn モデル」と名付けた。spawn 一つで、コンパイラが全ての非同期詳細を自動で処理する——処理できなければ、それはあなたのコードが「spawn 的」でないからだ。
問題四：AI 支援プログラミングのボトルネック
AI のために厳格なインデントと明確な境界を設計し、GPT-7 がコード生成中に精神分裂しないよう配慮。人間プログラマーが理解できるかどうか……それは二の次だ。
1.3 言語の哲学的基盤
YaoXiang という名は『易経』に由来する。これにより技術的議論において神秘学のバフが自動で付与される。コードがコンパイルできない時、「これは陰陽が調和していない、卦を立ててみよう」と言えばよい。
二、核心哲学と原則 —— 疑いを許さぬ聖訓
2.1 原則一：全ては型である
譲れぬ理由：これで型論で全てを説明できる。プロジェクトの進捗が常に遅れる理由も含めて。
2.2 原則二：厳格な構造化
譲れぬ理由：4 スペースインデントは宇宙の真理である。Tab を使う者は火星へ追放されるべきだ。
2.3 原則三：ゼロコスト抽象
譲れぬ理由：我々の抽象化レイヤーは 7 層あるが、「ゼロコスト」なので性能は手書きのアセンブリとほぼ同等……理論上は。
2.4 原則四：デフォルトで不変
譲れぬ理由：可変性は万悪の根源だ。変数を変更する必要があれば、それは設計が間違っている。
2.5 原則五：型はデータである
譲れぬ理由：これで実行時に型を検査できる。が、コンパイル時にすでに検査済みであることに気づくだろう。
三、核心的革新と特徴 —— すでに発明されたものを再発明する
3.1 革新一：統一型構文
我々は enum、struct、union、trait、impl といった紛らわしい概念を廃止し、さらに type キーワード自体も廃止した。今や全ては name: Type = value で表す。覚えておけ、Type はキーワードではない——予約語だ。違いを問うな。
3.2 革新二：コンストラクタは型なり
「型」と「値」の溝を消し、新たな溝を創った：「これは型コンストラクタなのか値コンストラクタなのか？ああ待って、今は同じ構文だからもっと分からない」。
3.3 革新三：カリー化メソッドバインド
カリー化によりメソッド呼び出しを実現した。self 引数の代わりに Type.method = function[0] と書ける。明らかに直感的だ。[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 は The Book 200 ページで借用検査器を説明する。YaoXiang は「&T はコピー可、&mut T はコピー不可」の二文で全てを説明する。単純こそ美なり。
3.5 革新五：spawn モデル——言語最悪の部位
「万物は並び作す、吾は以て復を観る。」——『易経・復卦』
spawn モデルの核心的売り：同期構文、非同期の本質。平易に言えば、コードは順次実行されているように見えるが、実行時には自動的に並列化される。いつ並列化されるか？どうやって並列化されるか？コンパイラが決める。これは並行モデルではなく、信頼ゲームだ。
この魔法を実現するために、言語に詰め込んだものを以下に示す：
spawn キーワード：関数を非同期とマークする。注意——async ではなく spawn だ。async はありふれているから。しかし Rust において spawn は「タスクを起動する」の意だ。問題ない、再定義する。
@block 注釈：spawn 関数を「同期実行」すべきとマークする。えっと——spawn が非同期なら、@block で同期にするなら、なぜ最初から spawn と書かない？「時には spawn 関数を特定の文脈で同期的に動かしたい場合があるからだ」。つまり spawn の付いた関数は、呼び出し側の気分次第で非同期にも同期にもなり得る。これは型システムではなく、人格分裂だ。
@eager 注釈：「先行評価」が必要な式をマークする。spawn モデルはデフォルトで遅延評価だからだ——ただし遅延評価はまだ実装されていない。よって現時点で @eager の実効的な作用は？それは借用証書だ：「将来、遅延評価が実装されれば、この注釈によりその式は遅延評価されない」。
並行モデルの三つの注釈まとめ：
spawn = この関数は非同期だ（@block された場合を除く）
@block = この spawn 関数は今だけ同期だ（spawn を上書き）
@eager = この式は将来遅延評価されない（今は何も起きない）これでは混乱すると感じるなら、おめでとう——あなたは理解した。コードの並列実行が崩壊した時、『易経』を引用すれば、深い味わいがあるように見える。
3.6 革新六：値依存型（RFC-011）
これでコンパイル時に配列の長さが素数であることや、行列の次元が一致すること、factorial(5) の結果が型シグネチャに使用できることを証明できる。ビジネスロジックとは関係ないが、「型は命題、プログラムは証明」——クールじゃないか？
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 パラドックスへのオマージュであり、コンパイラが意図的に実装しない唯一つの機能だ。我々はこれを「言語の境界」と呼ぶ——そこに到達した時、コンパイラは沈黙し、哲学は立ち止まる。
四、初步的構文プレビュー —— 「動きそうに見える」コードサンプル
# === 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 = {
# コンパイラが引数の減少を自動解析、コメント不要
if n <= 1 { return 1 }
return n * factorial(n - 1)
}
arr: Array(Int, factorial(5)) = Array(Int, 120)() # Array(Int, 120) 型、コンパイル時計算
# === spawn モデル：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 行/篇、合計約 11,200 行。RFC には「spawn」「YaoXiang」「万物は並び作す吾は以て復を観る」などの概念が満ちていることを考えると、これは『道徳経』半分を翻訳するのに等しい。応募はお早めに。
6.7 コントリビューションガイド
コミットメッセージ形式：必ず詩であること。十四行詩優先。俳句も可：
所有権トークン
コンパイル後に消え去る
ゼロコスト抽象付録 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: 「spawn モデル」はいつ本当に動くのか？
A: この文字を読んでいる今もなお、答えは「設計段階、未実装」だ。しかし spawn キーワードはすでに正しくパースできるではないか——これは鼓舞すべきではないのか？
Q: 1.0 バージョンはいつリリースされるのか？
A: 「コミュニティ」が 1 人から 2 人に拡大した時。
Q: コアチームへの連絡方法は？
A: GitHub Discussions にメッセージを。返信時間：1〜3 営業日。
七、さらなる嘘
「多言語サポート」：docs/src/{en,ja,ru,zh} の四言語完備。コンパイラ v0.7.0、実際に動くコード行数はほぼゼロに等しいが、日本の開発者もロシアの開発者もすでに母語で「spawn モデル」と「値依存型」を読める。これは古典的な「文書駆動開発」だ——まず全世界に設計を理解させ、誰もそれを必要としないふりをする。コンパイラが Hello World を動かせるようになった時には、文書はクリンゴン語に翻訳されているだろう。
ツールチェーン マトリョーシカ：Python の pre-commit が Rust のコードスタイル（cargo fmt + clippy）をチェックし、Rust コンパイラが YaoXiang ソースをコンパイルする。三層の言語が積み重なり、各層が次の層に依存する。YaoXiang がセルフホストした時、このマトリョーシカは：Python が Rust をチェックし、Rust が YaoXiang をコンパイルし、YaoXiang が YaoXiang をコンパイルする。その時、upstream の依存が一つでも落ちれば、ツールチェーン全体は行為芸術になる。しかし問題ない——「セルフホスト」という言葉自体で 2 篇の RFC 分の価値がある。
YaoXiang-book.md：YaoXiang 言語を体系的に語る本。まだ実装されていないプログラミング言語を解説する本を書くとは、存在しない都市の観光ガイドを出版するようなものだ。「第 3 章：ジェネリクスシステム——本章のコードは一切コンパイルできないが、構文は正しい。実行結果を想像されたし。」本書最も誠実な一文は初頁の「プロジェクトステータス：実験検証段階」。
「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 の設計の旅が、皆さまの 茶飲み話の話題 となることを願ってやまない。 （結局のところ、現時点ではそれは話題でしかない。）