YaoXiang

日本語

中文
English
Русский

日本語

中文
English
Русский

Appearance

YaoXiang 設計ドキュメント ​

道は一を生じ、一は二を生じ、二は三を生じ、三は万物を生じる。

本ディレクトリには、YaoXiangプログラミング言語の設計上の決定、提案、議論が含まれています。

核心設計理念 ​

理念説明
全てが型値、関数、モジュールは全て型であり、型は第一級市民である
自然な構文Pythonのような可読性、自然言語に近い
所有権モデルゼロコスト抽象、GCなし、高パフォーマンス
spawnモデル同期構文、非同期の性質、自動並列
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-028JITコンパイラドラフト
RFC-029モジュール意味論システムドラフト
RFC-031最適化レベルドラフト
RFC-033^^反射演算子ドラフト
RFC-034デバッグツールチェーンドラフト
RFC-035MCP Serverドラフト
RFC-002クロスプラットフォームIO（libuv）ドラフト
RFC-026byx-bindgenドラフト
RFC-011aインターフェース実装と動的ディスパッチレビュー中
RFC-014aRegistryプロトコルレビュー中
RFC-014bビルドシステムレビュー中
RFC-014cワークスペースレビュー中
RFC-026a拡張可能FFIレビュー中
RFC-032spawn統一式レビュー中

採用された提案 ​

番号タイトルステータス
RFC-004カリー化複数位置バインディング採用済み
RFC-006ドキュメントサイトの最適化採用済み
RFC-007関数構文の統一採用済み
RFC-008ランタイム並行モデル採用済み
RFC-009所有権モデル採用済み
RFC-009aトークン生存期間分析採用済み
RFC-010統一型構文採用済み
RFC-011泛型システム採用済み
RFC-012f-string採用済み
RFC-013エラーコード規範採用済み
RFC-014パッケージマネージャー採用済み
RFC-015設定システム採用済み
RFC-017LSPサポート採用済み
RFC-018LLVM AOTコンパイラ採用済み
RFC-024並行モデル採用済み
RFC-026FFIコアメカニズム採用済み
RFC-027コンパイル時アサーション採用済み
RFC-030assertアサーション機構採用済み

拒否された提案 ​

番号タイトルステータス
RFC-003バージョン計画拒否済み
RFC-005CVEスキャン拒否済み
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: () -> Void = {
    print("Hello, YaoXiang!")
}

重要な設計上の決定 ​

1. 型システム ​

  • 統一型構文：enum、struct、unionを廃止し、Name: Type = {...}に統一
  • コンストラクタが型そのもの：「型」と「値」の間の溝を排除
  • 泛型サポート：コンパイル時の単態化、ランタイムコストゼロ

2. spawnモデル ​

yaoxiang
// spawnモデル：デフォルトでは順次実行、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)?
}

関連リソース ​

履歴アーカイブ ​

設計過程の履歴ドキュメントは docs/old/ ディレクトリに移動されました：

  • 初期のアーキテクチャ設計
  • 廃止された提案
  • 時代遅れの実装計画