YaoXiang 設計ドキュメント
道生一，一生二，二生三，三生万物。
本ディレクトリには、YaoXiang プログラミング言語の設計決定、提案、議論が含まれている。
コア設計理念
| 理念 | 説明 |
|---|---|
| 一切皆类型 | 値、関数、モジュールはすべて型であり、型は第一級市民である |
| 自然構文 | Python のような可読性、自然言語に近い |
| 所有権モデル | ゼロコスト抽象化、GC なし、高パフォーマンス |
| 并作モデル | 同期構文、非同期本質、自动並列 |
| AI フレンドリー | 厳密な構造化、明確な AST |
設計ドキュメント構造
design/
├── index.md # 本インデックス
├── deprecated/ # 非推奨（新設計に置き換えられた）
│ └── *.md
├── rejected/ # 却下
│ └── *.md
├── rfc/
│ ├── draft/ # 草案（作業中）
│ ├── review/ # レビュー中（議論公開）
│ ├── accepted/ # 承認済み（設計通過）
│ ├── deprecated/ # 非推奨（置き換えられた）
│ └── rejected/ # 却下（不通過）
└── discussion/ # 設計議論エリア（議論公開）
└── *.md承認された設計提案
| ドキュメント | 状態 | 説明 |
|---|---|---|
| RFC-010 統一型構文 | ✅ 承認済み | 型定義構文の統一 |
| RFC-011 ジェネリクス型システム | ✅ 承認済み | ジェネリクス型システム設計 |
| RFC-009 所有権モデル | ✅ 承認済み | 所有権と借用システム設計 |
| RFC-024 并発モデル | ✅ 承認済み | spawn並発プリミティブ意味論 |
| RFC-027 コンパイル時評価 | ✅ 承認済み | コンパイル時述語と静的検証 |
完全なリスト（全16件）は
rfc/accepted/ディレクトリを、最新状態はrfc/index.mdを参照。
RFC 提案
RFC（Request for Comments）は、新機能と重大な変更の提案プロセスである。
アクティブな提案
| 番号 | タイトル | 状態 |
|---|---|---|
| RFC-019 | 型付けされた同像性 | 草案 |
| RFC-028 | JITコンパイラ | 草案 |
| RFC-029 | モジュール意味論システム | 草案 |
| RFC-031 | 最適化レベル | 草案 |
| RFC-033 | ^^反射演算子 | 草案 |
| RFC-034 | デバッグツールチェーン | 草案 |
| RFC-035 | MCP Server | 草案 |
| RFC-002 | クロスプラットフォームIO(libuv) | 草案 |
| RFC-026b | yx-bindgen | 草案 |
| RFC-011a | インターフェース実装と動的ディスパッチ | レビュー中 |
| RFC-014a | Registryプロトコル | レビュー中 |
| RFC-014b | ビルドシステム | レビュー中 |
| RFC-014c | ワークスペース | レビュー中 |
| RFC-026a | 拡張可能FFI | レビュー中 |
| RFC-032 | spawn統一式 | レビュー中 |
承認された提案
| 番号 | タイトル | 状態 |
|---|---|---|
| RFC-004 | 柯里化多位置束縛 | 承認済み |
| RFC-006 | ドキュメンテーションサイト最適化 | 承認済み |
| RFC-007 | 関数構文統一 | 承認済み |
| RFC-008 | ランタイム並発モデル | 承認済み |
| RFC-009 | 所有権モデル | 承認済み |
| RFC-009a | トークンライフタイム分析 | 承認済み |
| RFC-010 | 統一型構文 | 承認済み |
| RFC-011 | ジェネリクスシステム | 承認済み |
| RFC-012 | f-string | 承認済み |
| RFC-013 | エラーコード規範 | 承認済み |
| RFC-014 | パッケージマネージャー | 承認済み |
| RFC-015 | 設定システム | 承認済み |
| RFC-017 | LSPサポート | 承認済み |
| RFC-018 | LLVM AOTコンパイラ | 承認済み |
| RFC-024 | 並発モデル | 承認済み |
| RFC-026 | FFIコアメカニズム | 承認済み |
| RFC-027 | コンパイル時アサーション | 承認済み |
| RFC-030 | assertアサートメカニズム | 承認済み |
却下された提案
| 番号 | タイトル | 状態 |
|---|---|---|
| RFC-003 | バージョニング | 却下済み |
| RFC-005 | CVEスキャン | 却下済み |
| RFC-016 | 量子ネイティブサポート | 却下済み |
| RFC-025 | プリミティブ型拡張 | 却下済み |
RFC テンプレート
新規提案の提出前に、以下を参照：
設計議論への参加
RFC ライフサイクル
RFC 提案には5つの状態がある：
| 状態 | 意味 |
|---|---|
| 草案 | 作業進行中 |
| レビュー中 | 議論公開 |
| 承認済み | 設計通過 |
| 非推奨 | かつて承認され、新設計に置き換えられた |
| 却下済み | 不通過 |
完全なライフサイクル：
草案 → レビュー中 → 承認済み → 非推奨（置き換えられた）
↓
却下済み（不通過）提案プロセス
1. 草案作成（RFC テンプレートを使用）
→ rfc/draft/ に配置
2. レビュー提出
→ rfc/review/ に移動、社区議論公開
3. コアチームレビュー
→ 承認 → rfc/accepted/ に移動
→ 却下 → rfc/rejected/ に移動
4. 維持管理
→ 置き換え → rfc/deprecated/ に移動設計原則
- 明確な境界: 各設計決定には明確な適用範囲が必要
- 実用優先: 実際の問題を解決し、架空の脅威に立ち向かわない
- ユーザー可視動作不変: Never break userspace
コード例
yaoxiang
// 型定義
Point: Type = { x: Float, y: Float }
Result: (T: Type, E: Type) -> Type = { ok: (T) -> Result(T, E), err: (E) -> Result(T, E) }
// 関数定義
add: (a: Int, b: Int) -> Int = a + b
// main 関数
main: () -> Void = {
print("Hello, YaoXiang!")
}重要な設計決定
1. 型システム
- 統一型構文:
enum、struct、unionを廃止し、Name: Type = {...}で統一 - コンストラクタ即型: 「型」と「値」の沟を消除
- ジェネリクスサポート: コンパイル時単態化、ゼロランタイムオーバーヘッド
2. 并作モデル
yaoxiang
// 并作モデル：デフォルトは逐次実行、spawn でデータフロー並列を導入
// デフォルトは逐次実行
compute: (Int) -> Int = (n) => {
a = heavy_calc(1)
b = heavy_calc(2) // 逐次実行、a の完了を待つ
c = heavy_calc(3) // 逐次実行、b の完了を待つ
a + b + c
}
// spawn ブロックでデータフロー並列を導入
process: () -> Void = () => {
spawn {
users = fetch_users() // 並列
posts = fetch_posts() // 並列
}
// 呼び出し元が結果を同期的にブロックして待つ
render(users, posts)
}3. エラー処理
yaoxiang
Result: (T: Type, E: Type) -> Type = { ok: (T) -> Result(T, E), err: (E) -> Result(T, E) }
process: () -> Result(Data, Error) = {
data = fetch_data()? // ? 演算子は透過的に伝播
transformed = transform(data)?
save(transformed)?
}関連リソース
- チュートリアル - YaoXiang の使い方
- リファレンス - API と標準ライブラリ
- 言語仕様 - 完全な言語仕様
- GitHub Discussions
- コントリビューションガイド
歴史アーカイブ
設計プロセスの歴史ドキュメントは docs/old/ ディレクトリに移動済み：
- 初期アーキテクチャ設計
- 废弃された提案
- 時代遅れの実装計画