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スペースインデント：タブ文字の使用を禁止し、コードブロック境界が一目瞭然
括弧は省略不可：関数引数には括弧が必要、リスト要素にはカンマが必要
コードブロックには波括弧が必要：if、while、forなどの制御フローは{ }で包み込む必要がある
キーワード数を精緻化：17のコアキーワードのみを維持し、糖衣構文の氾濫を拒否

妥協不可の理由：厳格な構造化は三つの重要な優位性をもたらす——（1）IDEの構文ハイライトとコードフォールドがより正確；（2）AIコード生成と修正の正確性が大幅に向上；（3）新規学習者がコード構造を迅速に理解できる。

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

高次の抽象は実行時の性能オーバーヘッドをもたらすべきではない。

具体的な保証：

単態化：泛型関数はコンパイル時に具現バージョンに展開され、仮想テーブルルックアップオーバーヘッドなし
インライン最適化：単純関数は自動的にインライン化され、関数コールオーバーヘッドを消除
スタック配置優先：小オブジェクトはデフォルトでスタック配置、 힙配置は必要な場合のみ使用
GCなし：所有権モデルがメモリ安全を保証し、ゴミ回収器の実行時オーバーヘッドが不要

妥協不可の理由：性能はプログラミング言語の生存底线である。便利さを求めて性能を犠牲にする設計はすべて、程序员への裏切りである。

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

可変性は複雑性と影をなす。YaoXiangはデフォルトで不変を選択し、コードをより推論と理解しやすくする。

具体的な規則：

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

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

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

型情報はコンパイル時だけでなく実行時にも完全に利用可能であるべきである。

具体的な能力：

実行時型クエリ：任意的值からその型情報を取得できる
型リフレクション：型自体を構成して操作できる
パターン照合デストラクト：型コンストラクタは直接パターン照合に使用可能
泛型特化：実行時に泛型パラメータの具体化型を取得可能

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

三、主な革新と特性

YaoXiangは既存の言語の優れた特性を吸取すると同時に、以下の革新的設計を提案する。

3.1 革新一：統一的型構文

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

rust

// 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は唯一の元型キーワードである。

yaoxiang

# === 記録型 ===

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 革新二：コンストラクタは型である

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

yaoxiang

# 型定義
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キーワードを導入する必要がない。

yaoxiang

# === 型定義 ===

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 並作モデル

yaoxiang

# === 並作関数 ===
# 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 を自動待機
}

スレッド安全：

yaoxiang

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

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

技術文書：

詳細 RFC-001 並作モデル

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

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

ステータス：設計中、部分実装

型は値に依存的可能であり、真の型駆動開発を実現する。

yaoxiang

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

# コンパイル時計算：factorial(3) = 6
vec: Vec(factorial(3)) = Vec(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

yaoxiang

# hello.yx

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

4.2 型定義と関数

yaoxiang

# 統一的型構文：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 パターン照合

yaoxiang

# パターン照合
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）

yaoxiang

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 エラー処理

yaoxiang

# 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 並行プログラミング（並作モデル）

yaoxiang

# 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/ ディレクトリ下のテンプレートに従う
構文レビュー：既存の構文設計に改善提案または潜在問題を提起

設計提案の提交：

rfcs/ ディレクトリに新規ファイルを作成
RFC テンプレートを記入（動機、詳細設計、利点欠点分析、代替案）
Pull Request を发起してコミュニティレビュー
コアチームの審議を経てマージまたは拒否

6.2 コンパイラ実装

適任者：コンパイラ開発者、システムプログラマ、パフォーマンス最適化エキスパート

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

優先度	モジュール	説明	難易度
P0	バイトコード仮想マシン	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

貢献を始める：

docs/YaoXiang-implementation-plan.md を查看してアーキテクチャ設計を理解
src/ ディレクトリ下で感兴趣的モジュールを選択
tests/unit/ を查看してテスト要件を理解
コード提交前に cargo fmt と cargo clippy が通過することを確認

6.3 ツールチェーン開発

適任者：IDE プラグイン開発者、ツールチェーン愛好家、効率ツール追求者

開発が必要なツール：

ツール	ステータス	説明
LSP サーバー	⏳ 未開始	言語サーバープロトコルサポート
デバッガ統合	⏳ 未開始	GDB/LLDB 統合
フォーマッター	⏳ 未開始	`yaoxiang fmt`
パッケージマネージャー	⏳ 未開始	依存管理、バージョン解決
パッケージレジストリ	⏳ 未開始	中央レジストリまたは分散化
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 コミュニティ構築

適任者：コミュニティマネージャー、イベントオーガナイザー、エバンジェリスト

コミュニティイベント：

定期的なオンラインミートアップ（月一回）
设计与実装討議会（毎週一回）
コード貢献スプリント（四半期每一度）
オフライン聚会とカンファレンス講演

传播チャネル：

GitHub Discussions：技術議論
GitHub Issues：問題報告と機能リクエスト
Discord/Slack：リアルタイム交流
Twitter/X：プロジェクト動態
ブログ：ディープ記事

6.7 貢献ガイドライン

貢献の始め方：

プロジェクトを理解する：README と設計文書をを読む
方向を選択する：興味に従って貢献分野を選択
環境を構築する：Rust 1.75+、cargo、git
タスクを見つける：GitHub Issues の good first issue タグを查看
PR を提交する：提交仕様に従い、テストを作成
レビューに参加する：他人的のコードをレビューし、議論に参加

提交仕様：

bash

# 提交情報形式
<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	`not`	右から左
9	`and` `or`	左から右
10	`if...else`	右から左
11	`=` `+=` `-=` `*=` `/=`	右から左

付録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 の設計の旅が、あなたと共にありますように。

YaoXiang（爻象）設計宣言 ​

一、なぜ YaoXiang を創造したのか？ ​

1.1 埋めていた言語の空白 ​

1.2 解決すべき实际问题 ​

1.3 言語の哲学的基盤 ​

二、コア哲学と原則 ​

2.1 原則一：すべてが型 ​

2.2 原則二：厳格な構造化 ​

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

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

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

三、主な革新と特性 ​

3.1 革新一：統一的型構文 ​

3.2 革新二：コンストラクタは型である ​

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

3.4 革新四：並作モデル ​

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

3.6 革新六：極限まで簡素化されたキーワード設計 ​

四，初步的な構文プレビュー ​

4.1 Hello World ​

4.2 型定義と関数 ​

4.3 パターン照合 ​

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

4.5 エラー処理 ​

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

五、ロードマップと未定項目 ​

5.1 既に決定された設計意思決定 ​

5.3 実装ロードマップ ​

六、参加貢献の方法 ​

6.1 設計議論 ​

6.2 コンパイラ実装 ​

6.3 ツールチェーン開発 ​

6.4 標準ライブラリ構築 ​

6.5 文書とチュートリアル ​

6.6 コミュニティ構築 ​

6.7 貢献ガイドライン ​

付録A：言語クイックリファレンス ​

A.1 キーワード ​

A.3 原型 ​

A.4 演算子優先順位 ​

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

付録C：よくある質問 ​

YaoXiang（爻象）設計宣言

一、なぜ YaoXiang を創造したのか？

1.1 埋めていた言語の空白

1.2 解決すべき实际问题

1.3 言語の哲学的基盤

二、コア哲学と原則

2.1 原則一：すべてが型

2.2 原則二：厳格な構造化

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

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

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

三、主な革新と特性

3.1 革新一：統一的型構文

3.2 革新二：コンストラクタは型である

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

3.4 革新四：並作モデル

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

3.6 革新六：極限まで簡素化されたキーワード設計

四，初步的な構文プレビュー

4.1 Hello World

4.2 型定義と関数

4.3 パターン照合

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

4.5 エラー処理

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

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

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

5.3 実装ロードマップ

六、参加貢献の方法

6.1 設計議論

6.2 コンパイラ実装

6.3 ツールチェーン開発

6.4 標準ライブラリ構築

6.5 文書とチュートリアル

6.6 コミュニティ構築

6.7 貢献ガイドライン

付録A：言語クイックリファレンス

A.1 キーワード

A.3 原型

A.4 演算子優先順位

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

付録C：よくある質問