YaoXiang（爻象）設計宣言

バージョン：v2.0.0 ステータス：正式リリース 著者：晨煦 + YaoXiang コミュニティ 日付：2026-05-31

---

「道生一、一生二、二生三、三生万物」——『道徳経』

タイプ（型）は道の如く、万物はすべてこれより生ず。

---

一、なぜYaoXiangを作るのか？

1.1 埋める言語の空白

プログラミング言語の歴史の長い川の中で、数え切れないほどの優れた言語の誕生と進化を目の当たりにしてきた。C言語はシステムプログラミングの効率革命をもたらし、Pythonは誰もが学べるプログラミング体験を創造し、Rustはメモリ安全性とパフォーマンスの両立を証明し、TypeScriptは大規模なフロントエンドプロジェクトを保守可能にした。しかし、今日の言語エコシステムを审视すると、依然として明らかな断層地帯が存在している——いかなる言語も以下の3つの核心的なニーズを同時に満たすことができない：

ニーズ	既存ソリューションの問題
型安全性	Rustは厳しすぎ、学習曲線が急峻；TypeScriptはオプショナル型で、编译時の保証を提供できない
自然な構文	Rustの構文は複雑で難解；Haskellの関数型は敷居が高い；従来の静的言語は冗長で煩雑
AI親和性	既存言語は構文の曖昧性が多く、ASTが複雑で、隠れた動作の予測が難しいため、AIのコード生成・修正の精度が制限される

YaoXiangの誕生は、まさにこの空白を埋めるためである。私たちはこう信じる：プログラミング言語は強力で親しみやすく、安全で効率的、厳密でエレガントであるべきである。

1.2 解決する実際的な問題

問題一：型システムの断片化

今日のプログラミング言語は、型システムにおいて深刻な断片化を示している。静的型付き言語は编译時の絶対的な正確性を追求するが、往々にして開発効率の犠牲を伴う。動的型付き言語は柔軟性を提供するが、大規模プロジェクトでは保守が困難な欠点を露呈する。YaoXiangは「すべては型である」という統一的な抽象フレームワークを提案し、型を言語設計の主軸とし、後付けの补丁ではなくする。

問題二：メモリ安全性とパフォーマンスの二者択一

長らく、開発者はメモリ安全性と実行パフォーマンスの間で難しい選択を迫られてきた。GC（ガベージコレクション）は開発者を解放するが、レイテンシの変動とメモリオーバーヘッドをもたらす。手動メモリ管理は効率的だが、綱渡りと同様に危険である。YaoXiangはRustスタイルの所有権モデルを採用し、编译時にデータ競合とメモリリークを排除しつつ、ゼロコスト抽象を実現し、GCなしに高性能を達成する。

問題三：非同期プログラミングの認知負担

現代のアプリケーションはネットワークと並行性に依存しているが、非同期プログラミングは常にプログラマーの悪夢だった。コールバック関数のネスト、Promiseチェーン呼び出し、async/await構文——どのアプローチもコードの複雑性を増大させる。YaoXiangは非同期モデルを再設計した：関数シグネチャの後にspawnマークを追加するだけで、コンパイラがすべての非同期の詳細を自動的に処理し、並行プログラミングを同期コードのように自然にする。

問題四：AI支援プログラミングのボトルネック

AIが開発者のコード作成を支援するようになった現在、言語設計の選択が極めて重要になる。曖昧な構文ルール、暗黙的な型変換、複雑な構文糖衣——これらは人間のプログラマーがすでに慣れた特性だが、AIの理解と生成の障壁となっている。YaoXiangは設計当初から「AI親和性」を核心目標とする：厳格なインデントルール、明確なコードブロック境界、曖昧さのない構文構造により、AIがコードを正確に理解し、生成、修正できるようにする。

1.3 言語の哲学的根底

YaoXiangという名前は『易経』の「爻」と「象」に由来する。「爻」は卦象を構成する基本記号で、陰陽の変化、動静の相互生成を象徴し、「象」は事物の本質的な外在的表現で、万象万物を包括的に表す。

この哲学的思想は言語設計のあらゆる細部に体现されている：

• 統一性：爻卦の単純な記号が複雑な卦象を構成するように、YaoXiangは少数の核心概念（型、関数、コンストラクタ）で完全なプログラミングモデルを構築する
• 階層性：象に先天と後天の区別があるように、YaoXiangの型システムは明確な階層構造を持ち、原型からジェネリクス、値からメタ型へと展開する
• 可変性：陰陽が流転し変化无穷であるように、YaoXiangは依存型をサポートし、型の値に応じた変化を可能にする
• 識別可能性：卦象が解け万物に象があるように、YaoXiangは完全な型リフレクション能力を提供し、実行時の型情報は完全に利用可能である
• 証明可能性：卦象が事物の法則を明らかにするように、YaoXiangの型システムはCurry-Howard同型（型は命題、プログラムは証明）に従い、型検査のプロセスが論理的証明の検証となる

---

二、核心哲学と原則

以下の設計信条はYaoXiangの礎石であり、譲歩できず、违背できない。あらゆる特性提案はこれらの原則による検驗を経なければならない。

2.1 原則一：すべては型である

YaoXiangの世界観において、型は最高層の抽象ユニットであり、言語を貫く核心概念である。

具体的な体现：

• 値は型のインスタンス：42はInt型のインスタンス、"hello"はString型のインスタンス
• 型自身もまた型である：Typeは言語唯一のメタ型キーワードであり、Intの類型はType
• 関数は型マッピング：add: (a: Int, b: Int) -> IntはInt × IntからIntへの型マッピングを記述する
• モジュールは型の組み合わせ：モジュールは関数と型を含む名前空間の組み合わせである

譲歩できない理由：統一された型の抽象は言語の意味論を簡素化し、値と型の二元対立を排除し、型システムをコードの正しさの守護者とし、障害者としない。

2.2 原則二：厳格な構造化

YaoXiangの構文設計は「曖昧さなし、予測可能、解析容易」を追求する。

具体的なルール：

• 強制4スペースインデント：Tab文字の使用を禁止し、コードブロックの境界を一目でわかるようにする
• 括弧の省略不可：関数の引数は括弧が必須、リスト要素にはカンマが必須
• コードブロックには必ず中括弧を：if、while、forなどの制御フローは{ }で囲む必要がある
• キーワード数を精简：わずか17個の核心キーワードのみを残し、構文糖衣の泛滥を拒否

譲歩できない理由：厳格な構造化は3つの重要な利点をもたらす——（1）IDEの構文ハイライトとコード折叠がより正確になる；（2）AIのコード生成と修正の精度が大幅に向上；（3）新しい学習者がコード構造を迅速に理解できる。

2.3 原則三：ゼロコスト抽象

高次の抽象が実行時のパフォーマンスオーバーヘッドをもたらすことはない。

具体的な保証：

• 単態化：ジェネリック関数は编译時に具象バージョンに展開され、仮想表検索のオーバーヘッドがない
• インライン化最適化：単純な関数は自動的にインライン化され、関数呼び出しのオーバーヘッドを排除
• スタック割り当て優先：小さなオブジェクトはデフォルトでスタック割り当て、必要時のみヒープ割り当て
• GCなし：所有権モデルがメモリ安全性を保証し、ガベージコレクターのランタイムオーバーヘッドが不要

譲歩できない理由：パフォーマンスはプログラミング言語の生存底线である。利便性のためにパフォーマンスを犠牲にする設計は、プログラマーへの裏切りである。

2.4 原則四：デフォルト不変

可変性は複雑性と密接に結びついている。YaoXiangはデフォルトを不変とし、コードをより推論しやすく理解しやすくする。

具体的なルール：

• 変数はデフォルトで不変、代入後に再変更不可
• 可変が必要な場合は明示的にmutを宣言する必要がある
• 参照はデフォルトで不変、可変参照にはmutマークが必要
• 所有権の移転は元のバインディングの失効を意味する

譲歩できない理由：不変性は並行安全性の基礎であり、コード可読性の保障であり、関数型プログラミングの知恵の結晶である。

2.5 原則五：型はデータである

型情報はコンパイル期にのみ存在するのではなく、実行時に完全に利用可能であるべきである。

具体的な能力：

• 実行時型クエリ：あらゆる値はその型情報を取得できる
• 型リフレクション：型自体の構築と操作が可能
• パターンマッチによる分解：型コンストラクタは直接パターンマッチに使用可能
• ジェネリクス特殊化：実行時にジェネリクス引数の具象型を取得可能

譲歩できない理由：完全な型リフレクション能力はメタプログラミングの基礎であり、高性能フレームワークとツールの礎石である。

---

三、重要な革新と特性

YaoXiangは既存言語の優れた特性を吸収しつつ、以下の革新的な設計を提案する。

3.1 革新一：統一型構文

従来の言語の型定義は往々にして複数のキーワードを必要とする：

// Rust
struct Point { x: f64, y: f64 }
enum Result<T, E> { Ok(T), Err(E) }
enum Color { Red, Green, Blue }
trait Drawable { fn draw(&self, s: &Surface); }

YaoXiangの統一構文：すべてはname: type = value、Typeは唯一のメタ型キーワード。

# === レコード型 ===

Point: Type = {
    x: Float,
    y: Float,
}

# デフォルト値を持つフィールド
Point3D: Type = {
    x: Float = 0,
    y: Float = 0,
    z: Float = 0,
}

# === ジェネリック型 ===

Option: (T: Type) -> Type = {
    some: (T) -> Self,
    none: () -> Self,
}

Result: (T: Type, E: Type) -> Type = {
    ok: (T) -> Self,
    err: (E) -> Self,
}

# === インターフェース（フィールドがすべて関数型のレコード） ===

Drawable: Type = {
    draw: (Surface) -> Void,
    bounding_box: () -> Rect,
}

Serializable: Type = {
    serialize: () -> String,
}

# === インターフェース実装（インターフェース名は型体内に記述） ===

Point: Type = {
    x: Float,
    y: Float,
    Drawable,
    Serializable,
}

# === メソッド（Type.method 構文） ===

Point.draw: (self: &Point, surface: Surface) -> Void = {
    surface.plot(self.x, self.y)
}

革新の価値：fn、struct、enum、trait、implキーワードの断片化がない——一つの統一構文があらゆる宣言をカバーする。

3.2 革新二：コンストラクタは型そのもの

値の構築と関数呼び出しは完全に同一：

# 型定義
Point: Type = { x: Float, y: Float }
Option: (T: Type) -> Type = {
    some: (T) -> Self,
    none: () -> Self,
}

# 値構築：関数呼び出しと同じ
p: Point = Point(3.0, 4.0)
opt: Option(Int) = Option.some(42)
none: Option(Int) = Option.none()

# パターンマッチ：直接分解
match opt {
    Option.some(value) -> print(value)
    Option.none -> print("nothing")
}

3.3 革新三：カリー化メソッドバインディング

YaoXiangは純粋関数型設計を採用し、カリー化によりオブジェクトメソッド呼び出しに類似した構文糖衣を実現、classとmethodキーワードを導入する必要がない。

# === 型定義 ===

Point: Type = {
    x: Float,
    y: Float,
}

# 核心関数：ユークリッド距離
distance: (a: Point, b: Point) -> Float = {
    dx = a.x - b.x
    dy = a.y - b.y
    return (dx * dx + dy * dy).sqrt()
}

# メソッド構文糖衣バインディング（[0]は第0引数位置へのバインディングを示す）
Point.distance = distance[0]

# === 使用 ===

p1 = Point(3.0, 4.0)
p2 = Point(1.0, 2.0)

# 2つの呼び出し方法は完全に等価
d1 = distance(p1, p2)     # 核心関数の直接呼び出し
d2 = p1.distance(p2)      # メソッド構文糖衣

# カリー化用法
dist_from_p1 = p1.distance  # 部分適用、第2引数を待機
d3 = dist_from_p1(p2)       # 2.828

革新の価値：純粋関数型設計、隠れたself引数なし、関数は値として自由に渡して組み合わせ可能。

3.4 革新四：並作モデル

「万物並作、吾以観復」——『易・復卦』

並作モデルはここに由来し、一つのプログラミングパラダイムを記述する：開発者は同期・逐次の思考でロジックを記述し、言語ランタイムはその中の計算ユニットを万物並作のように自動的かつ効率的に並列実行させ、最終的に統一的に協働させる。

核心三原則：

原則	説明
同期構文	見たものがそのまま得られる逐次コード
並列本質	ランタイムが自動的に並列性を抽出
統一協働	結果は必要なときに自動集約、論理の正確性を保証

用語体系：

公的用語	対応構文	説明
並作関数	spawn (params) => body	並作実行に参加可能な計算ユニットを定義
並作ブロック	spawn { a(), b() }	明示的に宣言された並列領域、ブロック内のタスクは並作実行
並作ループ	spawn for x in xs { ... }	データ並列、ループ本体は全要素上で並作実行
並作値	Async(T)	並作中の未来値、使用時に自動待機
並作グラフ	遅延計算グラフ(DAG)	並作が発生する舞台、依存関係と並列関係を記述
並作スケジューラ	ランタイムタスクスケジューラ	万物を協調させ、正しいタイミングで並作させる知的中枢

詳細：RFC-001 並作モデル

# === 並作関数 ===
# spawnマーク付き関数
fetch_data: (url: String) -> JSON spawn = {
    return HTTP.get(url).json()
}

# === 並作ブロック ===
# spawn { }内の式は強制的に並列実行される
compute_all: () -> (Int, Int, Int) spawn = {
    (a, b, c) = spawn {
        heavy_calc(1),    # タスク1
        heavy_calc(2),    # タスク2
        another_calc(3)   # タスク3
    }
    return (a, b, c)
}

# === 自動待機 ===
main: () -> Void = {
    # 2つの独立したリクエストが自動的に並列実行される
    users = fetch_data("https://api.example.com/users")
    posts = fetch_data("https://api.example.com/posts")

    # 待機点は結果が必要なときに自動的に挿入される
    print(users.length + posts.length)  # usersとpostsを自動待機
}

スレッド安全性：

# refキーワードが自動的にスレッド安全性を処理（コンパイラが自動的にRc/Arcを選択）
main: () -> Void = {
    counter = ref SafeCounter(0)

    # タスク間共有：コンパイラが自動的にArcを選択
    spawn {
        counter.increment()
    }
    spawn {
        counter.increment()
    }
}

技術文書：

• 詳細はRFC-001 並作モデルを参照

革新の価値：非同期プログラミングの認知負担がゼロに、コード可読性は同期コードと完全に同じ、同時に高性能並列実行効率を獲得。

3.5 革新五：値依存型（RFC-011）

ステータス：設計中、一部実装済み

型は値に依存可能、真の型駆動開発を実現。

# 行列型：次元はコンパイル期に決定
Matrix: (T: Type, Rows: Int, Cols: Int) -> Type = {
    data: Array(Array(T, Cols), Rows),
}

# コンパイル期計算：factorial(3) = 6
arr: Array(Int, factorial(3)) = Array(Int, 6)()

# コンパイル期次元検証
identity_3x3: Matrix(Float, 3, 3) = identity(Float, 3)(3)
# multiply(matrix_2x3, matrix_4x2)  # コンパイルエラー：次元不一致

革新の価値：コンパイル期により多くのエラーを捕捉し、より精密な型保証を実現。

3.6 革新六：極簡キーワード設計

YaoXiangはわずか17個の核心キーワードのみを定義し、主流言語をはるかに下回る：

pub    use    spawn
ref    mut    if     else
else   match  while  for    return
break  continue as     in     unsafe

比較言語	キーワード数
YaoXiang	17
Rust	51+
Python	35
TypeScript	64+
Go	25

革新の価値：より低い記憶負担、より一貫した構文スタイル、より解析しやすい構文構造。

---

四、初步構文プレビュー

以下のコード例はYaoXiangの言語風貌を示し、その設計美学を迅速に感じていただくためのものである。

4.1 Hello World

# hello.yx

main: () -> Void = {
    print("Hello, YaoXiang!")
}

4.2 型定義と関数

# 統一型構文：name: type = value

# レコード型
Point: Type = { x: Float, y: Float }

# ジェネリック型
Option: (T: Type) -> Type = {
    some: (T) -> Self,
    none: () -> Self,
}

# インターフェース型（フィールドがすべて関数のレコード）
Serializable: Type = {
    serialize: () -> String,
}

# 関数定義
add: (a: Int, b: Int) -> Int = a + b

# ジェネリック関数
identity: (T: Type) -> ((x: T) -> T) = x

# 複数行関数
fact: (n: Int) -> Int = {
    if n == 0 { return 1 }
    return n * fact(n - 1)
}

4.3 パターンマッチ

# パターンマッチ
classify: (n: Int) -> String = {
    return match n {
        0 -> "zero",
        1 -> "one",
        _ if n < 0 -> "negative",
        _ -> "positive",
    }
}

# 分解パターン
Point: Type = { x: Float, y: Float }
match point {
    Point(0.0, 0.0) -> "origin",
    Point(x, y) -> "point at (${x}, ${y})",
}

4.4 所有権モデル（RFC-009 v9）

Point: Type = { x: Float, y: Float }

# デフォルトMove（ゼロコピー）
p1 = Point(1.0, 2.0)
p2 = p1              # Move、p1はもう読めない

# &T / &mut T トークン（コンパイル期ゼロコスト）
p2.print()           # コンパイラが自動的に&Pointトークンを作成
p2.shift(1.0, 1.0)  # コンパイラが自動的に&mut Pointトークンを作成

# ref：共有保持（コンパイラが自動的にRc/Arcを選択）
shared = ref p2      # スコープ間共有

# clone()：明示的ディープコピー
backup = p2.clone()

# unsafe + 生ポインタ：システムレベル
unsafe {
    ptr: *Point = &p2
    (*ptr).x = 0.0
}

所有権のグラデーション：

&T / &mut T    Move       ref        clone()    unsafe
    |             |          |           |          |
借用トークン   デフォルト  共有保持   ディープコピー  生ポインタ
ゼロコスト     ゼロコピー  自動Rc/Arc 明示的       システムレベル

4.5 エラー処理

# Result型
Result: (T: Type, E: Type) -> Type = {
    ok: (T) -> Self,
    err: (E) -> Self,
}

divide: (a: Float, b: Float) -> Result(Float, String) = {
    if b == 0.0 {
        return Result.err("Division by zero")
    }
    return Result.ok(a / b)
}

# matchで処理
result = divide(10.0, 2.0)
match result {
    Result.ok(value) -> print(value),
    Result.err(msg) -> print("Error: ${msg}"),
}

4.6 並行プログラミング（並作モデル）

# spawnで非同期関数をマーク
fetch_api: (url: String) -> JSON spawn = {
    response = HTTP.get(url)
    return JSON.parse(response.body)
}

# 並行構築ブロック：明示的並列
process_all: () -> (JSON, JSON, JSON) spawn = {
    (a, b, c) = spawn {
        fetch_api("https://api1.com/data"),
        fetch_api("https://api2.com/data"),
        fetch_api("https://api3.com/data")
    }
    return (a, b, c)
}

---

五、ロードマップと未決定事項

5.1 既に決定された設計決定

以下の決定は充分な議論と審査を経ており、もはや変更を受け付けない：

モジュール	決定	説明
型システム	すべては型である	値、関数、モジュール、ジェネリクスはすべて型
型構文	統一name: type = value	一つの宣言形式があらゆる場合をカバー、Typeは唯一のメタ型キーワード
キーワード	17個の核心キーワード	type/fn/struct/enum/trait/implを含まない
関数構文	シグネチャ + 式	name: (params) -> ReturnType = body
メソッドバインディング	RFC-004 カリー化バインディング	Type.method = function[position]
非同期モデル	並作モデル	spawnマーク、遅延評価、自動並列
メモリ管理	所有権モデル（RFC-009 v9）	Move + &T/&mut Tトークン + ref + clone + unsafe、GCなし
ファイル=モジュール	モジュールシステム	各.yxファイルは一つのモジュール
主関数	main: () -> Void	プログラムエントリーポイント
スレッド安全性	refが自動的にRc/Arcを選択	コンパイラのエスケープ分析、ユーザーは感知しない

5.3 実装ロードマップ

┌─────────────────────────────────────────────────────────────────────────────┐
│                              YaoXiang 実装ロードマップ（例）                            │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  v0.1: Rustインタプリタ ────────→ v0.5: Rustコンパイラ ────────→ v1.0: Rust AOT│
│        ✅ 完了                       │ (現在のフェーズ)            コンパイラ       │
│                                      │                                      │
│                                      ▼                                      │
│  v0.6: YaoXiangインタプリタ ←─────── v1.0: YaoXiang JITコンパイラ ←──── v2.0:│
│        （セルフホスティング）          （セルフホスティング）        YaoXiang AOT │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

六、コントリビューション参加方法

YaoXiangはコミュニティで生まれ、コミュニティで成長し、コミュニティに奉仕する言語である。プログラミング言語設計を愛するすべての開発者の皆様に、この探索の旅に加わっていただくことを心より歓迎する。

6.1 設計討論

対象となる方：プログラミング言語理論研究者、型システム愛好家、言語設計狂

参加方法：

• GitHub Discussions：「Language Design」分類の討論に参加
• 設計提案（RFC）：新特性の設計文書を提案、rfcs/ディレクトリ下のテンプレートに従う
• 構文審査：既存構文設計に対する改善提案または潜在的な問題の発見

| 現在のホットな議題： | | | | - マクロシステムの設計と実装 | | - インターフェース型メカニズム | | - エラー処理構文最適化 | | - 標準ライブラリAPI設計 |

設計提案の提出：

1. rfcs/ディレクトリに新ファイルを作成
2. RFCテンプレートを記入（動機、詳細設計、優缺點分析、代替案）
3. Pull Requestを発起しコミュニティ審査
4. コアチームの審議後、マージまたは拒否

6.2 コンパイラ実装

対象となる方：コンパイラ開発者、システムプログラマー、性能最適化専門家

現在の実装重点（優先順位順）：

優先度	モジュール	説明	難易度
P0	バイトコードVM	VM命令完善、性能最適化	中
P0	ランタイムメモリ	GC実装、メモリアロケータ	高
P0	非同期ランタイム	並作モデルの完全実装	高
P1	標準ライブラリ	IO、String、List、Concurrent	中
P1	JITコンパイラ	Cranelift統合	高
P2	AOTコンパイラ	LLVM/ Craneliftバックエンド	高
P3	セルフホスティングコンパイラ	YaoXiangで書き直し	極高

技術スタック：

• 実装言語：Rust（現在のフェーズ）
• コード生成：CraneliftまたはLLVM
• ビルドツール：Cargo
• テストフレームワーク：Rust #[test] + cargo nextest

コントリビューション開始：

1. docs/YaoXiang-implementation-plan.mdでアーキテクチャ設計を確認
2. src/ディレクトリ下の興味のあるモジュールを選択
3. tests/unit/でテスト要件を確認
4. コード提出前にcargo fmtとcargo clippyの通過を確保

6.3 ツールチェーン開発

対象となる方：IDEプラグイン開発者、ツールチェーン愛好家、効率ツール追求者

開発すべきツール：

ツール	ステータス	説明
LSPサーバー	⏳ 未着手	言語サーバープロトコルサポート
デバッガ統合	⏳ 未着手	GDB/LLDB統合
フォーマッタ	⏳ 未着手	yx format
パッケージマネージャ	⏳ 未着手	依存管理、バージョン解決
パッケージリポジトリ	⏳ 未着手	中央リポジトリまたは非中央集権
REPL	⏳ 未着手	インタラクティブインタプリタ
ベンチマークツール	⏳ 未着手	性能分析
VS Codeプラグイン	⏳ 未着手	構文ハイライト、補完、デバッグ
Vim/Neovimプラグイン	⏳ 未着手	構文ハイライト、LSPクライアント

プロジェクト構造参考：

yaoxiang/
├── src/
│   ├── tools/                    # ツールチェーン
│   │   ├── lsp/                  # LSPサーバー
│   │   ├── fmt/                  # フォーマッタ
│   │   ├── repl/                 # REPL
│   │   └── benchmark/            # ベンチマーク
│   └── ...
├── extensions/                   # エディタ拡張
│   ├── vscode/                   # VS Code
│   └── vim/                      # Vim/Neovim

6.4 標準ライブラリ建設

対象となる方：ライブラリ開発者、API設計者、ドメインエキスパート

標準ライブラリモジュール計画：

モジュール	優先度	説明
std.io	P0	ファイルIO、コンソール入出力
std.string	P0	文字列操作、フォーマット
std.list	P0	リスト/配列操作
std.dict	P0	辞書/ハッシュテーブル
std.math	P0	数学関数、定数
std.time	P1	時間日付操作
std.net	P1	ネットワークプログラミング、HTTP
std.concurrent	P1	並行プリミティブ、チャネル
std.crypto	P2	暗号化ハッシュ、署名
std.json	P1	JSONパース/生成
std.regex	P2	正規表現
std.database	P3	データベース接続
std.gui	P3	グラフィカルインターフェース（長期）

設計原則：

• 一貫性：同じ機能の関数名と動作は一貫性を保つ
• 簡潔性：APIは直感的で使いやすく、過剰設計を避ける
• パフォーマンス：標準ライブラリ関数は効率的で、不要なコピーを避ける
• テスト可能性：各関数には対応するユニットテストが必要

6.5 ドキュメントとチュートリアル

対象となる方：テクニカルライター、教育者、コミュニティマネージャー

コントリビューションが必要なドキュメント：

ドキュメント	ステータス	説明
クイックスタート	✅ 完了	5分入門ガイド
言語ガイド	✅ 完了	核心概念の体系的学習
言語仕様	✅ 完了	完全な構文と意味論の定義
実装計画	✅ 完了	コンパイラ実装技術詳細
APIドキュメント	⏳ 未着手	標準ライブラリAPIリファレンス
チュートリアル	⏳ 未着手	进阶チュートリアルとベストプラクティス
ブログ	⏳ 未着手	技術記事と設計ストーリー
翻訳	⏳ 未着手	多言語サポート

6.6 コミュニティ建設

対象となる方：コミュニティマネージャー、活動主催者、エバンジェリスト

コミュニティ活動：

• 定期オンラインミートアップ（月1回）
• 設計と実装討論会（週1回）
• コードコントリビューションスプリント（四半期毎）
• オフライン交流会とカンファレンス講演

広報チャネル：

• GitHub Discussions：技術討論
• GitHub Issues：問題報告と機能リクエスト
• Discord/Slack：リアルタイム交流
• Twitter/X：プロジェクト動向
• ブログ：深掘り記事

6.7 コントリビューションガイド

コントリビューションの始め方：

1. プロジェクトを理解する：READMEと設計ドキュメントを読む
2. 方向を選択：興味に応じてコントリビューション分野を選ぶ
3. 環境を構築：Rust 1.75+、cargo、git
4. タスクを見つける：GitHub Issuesのgood first issueラベルを確認
5. PRを提出：提出規範に従い、テストを作成
6. 審査に参加：他者のコードをレビューし、討論に参加

コミット規範：

# コミットメッセージ形式
<type>(<scope>): <subject>

# タイプ
feat: 新機能
fix: バグ修正
docs: ドキュメント更新
style: コードフォーマット（機能に影響なし）
refactor: リファクタリング
perf: パフォーマンス最適化
test: テスト
chore: ビルドツールまたは補助ツール

# 例
feat(typecheck): add generic type inference
fix(parser): fix infinite loop on invalid input
docs(readme): update installation instructions

コードスタイル：

• rustfmt.toml規範に従う
• cargo clippy警告なしを確保
• 必要なユニットテストを作成
• 関連ドキュメントを更新

---

付録A：言語チートシート

A.1 キーワード

キーワード	役割
pub	パブリックエクスポート
use	モジュールのインポート
spawn	並作マーク
ref	共有保持（コンパイラが自動的にRc/Arcを選択）
mut	可変変数
if/else if/else	条件分岐
match	パターンマッチ
while/for	ループ
return/break/continue	制御フロー
as	型変換
in	メンバー検査/リスト内包表記
unsafe	unsafeコードブロック（生ポインタ）

注意：Type、true、false、voidなどは予約語であり、キーワードではない。typeキーワードはRFC-010で既に削除され、統一的にname: Type = value構文を使用。

A.3 原型

型	説明	デフォルトサイズ
Void	空値	0バイト
Bool	ブール値	1バイト
Int	符号付き整数	8バイト
Uint	符号なし整数	8バイト
Float	浮動小数点数	8バイト
String	UTF-8文字列	可変
Char	Unicode文字	4バイト
Bytes	生バイト	可変

A.4 演算子優先順位

優先度	演算子	結合性
1	() [] . ?	左から右
2	as	左から右
3	単項前置 ! - +	右から左
4	* / %	左から右
5	+ -	左から右
6	..	左から右
7	<< >>	左から右
8	& | ^	左から右
9	== != < > <= >=	左から右
10	and or	左から右
11	if...else	右から左
12	= += -= *= /=	右から左

単項前置演算子（! - +）は强結合で、すべての二項演算子より高い（Zig式、SPEC §2.2参照）。

---

付録B：設計インスピレーション

YaoXiangの設計は以下の言語とプロジェクトの優れた思想を借鉴している：

出典	借鉴点
Rust	所有権モデル、ゼロコスト抽象、型システム
Python	構文スタイル、可読性、リスト内包表記
Idris/Agda	依存型、型駆動開発
Curry-Howard同型	型は命題、プログラムは証明、型システムと論理の統一理論
TypeScript	型アノテーション、実行時型
MoonBit	AI親和性設計、簡潔な構文
Haskell	純粋関数型、パターンマッチ
OCaml	型推論、バリアント型

---

付録C：よくある質問

Q: YaoXiangはRustと比較してどのような優位性がありますか？

A: YaoXiangはRustのメモリ安全性とゼロコスト抽象を保持しつつ、より簡潔な構文とより低い認知負担を採用している。並作モデルはRustのasync/awaitより簡潔——spawnマーク一つだけで、FutureとPinを手動管理する必要がない。「万物並作、吾以観復」、並行プログラミングを自然法則を記述するように直感的にする。所有権モデル（RFC-009 v9）はライフタイムアノテーションをMove + &T/&mut Tトークンで置き換え、借用チェッカーを型属性（Dup/Linear）で置き換える。統一型構文はenum/struct/trait/implの概念の断片化を排除する。

Q: YaoXiangはどのような開発に適していますか？

A: システムプログラミング、アプリケーション開発、Webサービス、スクリプティングツール、AI支援プログラミング。汎用プログラミング言語となることを目指している。

Q: なぜ4スペースインデントを選択するのですか？

A: 4スペースは明確なコードブロック視覚的分離を提供し、ネストの深さによる混乱を軽減する。これは深思熟慮された「AI親和性」設計決定である。

Q: いつバージョン1.0がリリースされますか？

A: v1.0目標：プロダクション対応。リリース時期は実装進捗に依存、詳細はバージョン計画RFCを参照。

Q: コアチームへの連絡方法は？

A: GitHub DiscussionsまたはDiscordコミュニティチャンネル経由。コアチームメンバーが定期的に返信する。

---

最終更新：2026-05-31

ドキュメントバージョン：v2.0.0

ライセンス：MIT

---

「爻象変化、万物生焉。型演化、プログラム成焉。」

願わくはYaoXiangの設計の旅が、あなたと共にありますように。