Skip to content

RFC 016: 量子ネイティブサポートとマルチバックエンド統合

拒否理由: 前提依存関係が不足しています。Primitive::Extension メカニズムがまだ実装されておらず、言語コンパイラが完了しておらず、実際のユーザー需要がありません。量子サポートは、Extension メカニズムのコンシューマーとして、言語が成熟した後で再評価されるべきです。

依存関係:

要約

このドキュメントは YaoXiang 言語の量子ネイティブサポートマルチバックエンド統合方案を定義します。核心的な考え方:YaoXiang の既存設計(デフォルト Move、所有権回流、不透明型、DAGスケジューラ、ジェネリクス定数パラメータ)は量子プログラミング言語の完全な基盤を自然に構成しており、新しい量子固有の構文を導入する必要はありません。少数の組み込み型(QubitComplexTopology)と組み込み関数(量子ゲート、測定、トポロジ制約)を追加し、既存の言語メカニズムを活用することで、量子ネイティブセマンティクス、量子利用率の自動最大化、ハイブリッド古典プログラミング、およびマルチバックエンドサポートを実現します。

動機

なぜ量子ネイティブサポートが必要なのか?

現在の量子プログラミングエコシステムには深刻な断絶があります:

  • 低級言語(QCIS、OpenQASM): 物理量子ゲートを直接操作しますが、型システムや抽象化メカニズムが欠けており、複雑なアルゴリズムを書くのが困難です。
  • 高級フレームワーク(Qiskit、Cirq、Q#): 古典言語(Python、C#)を拡張し、量子セマンティクスはライブラリで実装されており、次のような問題が生じます:
    • 量子状態ノークローニング定理はユーザーが手動で遵守する必要があります(または線形型システムの後付けに依存)。
    • 量子ゲート操作と古典コードの構文が分離しており、学習コストが高い。
  • ハイブリッド計算: 量子部分と古典部分の明示的な分離が必要であり、统一的なデータフローモデルが欠けています。

現在の問題

YaoXiang の既存の設計はこれらの問題を解決するために完全な基盤を提供します:

量子計算ニーズYaoXiang 既存設計説明
量子状態ノークローニングデフォルト Move セマンティクス代入時に所有権が移動し、暗黙的なコピーがなく、ノークローニング定理に天然で準拠
量子ゲートはユニタリ変換所有権回流q = H(q) 元の qubit を消費し、新しい qubit を返すゲートセマンティクスを正確に反映
エンタングルメント状態不透明型BellPair は全体でのみ操作可能で、コンパイラがライフタイムを追跡し誤った分解を防止
物理トポロジ制約ジェネリクス定数パラメータQubit(Topology, N) コンパイル時に隣接性を検査
測定崩壊空状態再利用測定後 qubit が空になり、再初期化して量子状態崩壊をシミュレート可能
量子回路の自動並列化DAGスケジューラ関数内のステートメントはデータ依存関係に基づいて自動並列化され、依存関係のないゲートは自然に同時実行
ハイブリッド古典-量子制御フロー統一構文量子操作と古典操作は同じ name: type = value 形式を使用

YaoXiang は「量子サポートを追加」するのではなく、自分の設計がすでに量子ネイティブであることを「発見」しました。

セマンティクス説明: このドキュメントでは YaoXiang の所有権セマンティクスを使用して量子操作を表現します。コンパイラレベルで no-cloning(所有権安全性)が保証されます。言語レベルの「消費-作成」は所有権移転の構文表現です—消費 = 所有権の取得、返値 = 所有権の移譲。実際の実装では、真の可逆量子ゲート(インプレースで量子状態を変更)であり、実際に「新しい量子状態を作成」するわけではありません。

設計目標

  1. ゼロ新構文: quantumcircuit などのキーワードを導入せず、すべての量子特性は既存の言語メカニズムで表現されます。
  2. 型安全性: コンパイラが量子状態がコピーまたは不法使用されないことを保証します。
  3. トポロジ制約のコンパイル時検査: ジェネリクス定数パラメータ Qubit(T, N) を使用して、2量子ビットゲート操作が物理トポロジに適合するかをコンパイル時に検証します。
  4. マルチバックエンド透過性: 同じ量子コードが QIR(汎用エコシステム)または QCIS(国内量子命令セット)にコンパイルでき、コマンドラインパラメータで切り替え可能です。
  5. ハイブリッド古典のシームレス統合: 量子計算は古典関数を自由に呼び出すことができ、古典コードも量子データを操作できます(ref共有経由、所有権制約あり)。

提案

コア設計

1. 量子型システムマッピング

基本型:

yaoxiang
Qubit: Type0 = primitive_qubit
Complex: Type0 = { re: Float, im: Float }
  • Qubit はファーストクラスの型であり、所有権ルール(Move、RAII)を遵守します。
  • Complex は振幅を表し、コンパイラはインライン最適化を適用できます。

量子ゲートを関数として:

yaoxiang
# 組み込み関数シグネチャ
H: (Qubit) -> Qubit = builtin_hadamard
X: (Qubit) -> Qubit = builtin_pauli_x
Y: (Qubit) -> Qubit = builtin_pauli_y
Z: (Qubit) -> Qubit = builtin_pauli_z
CNOT: (control: Qubit, target: Qubit) -> { Qubit, Qubit } = builtin_cnot
  • すべてのゲートは入力 qubit を消費し、新しい qubit(またはエンタングルメント対)を返します。所有権回流構文 q = H(q) は数学的セマンティクスを直接反映します。
  • 複数 qubit ゲートは構造体を返し、パターン一致またはフィールドアクセスで結果を取得します。

測定:

yaoxiang
measure: (Qubit) -> Int = builtin_measure   # qubit を消費し、古典ビットを返す
measure_all: (List(Qubit)) -> List(Int) = builtin_measure_all
  • 測定後 qubit は消費され(空になり)、ユーザーは空状態再利用によって再初期化できます。

初期化:

yaoxiang
qubit: (Int) -> Qubit = builtin_qubit   # 0 または 1 で基底状態を初期化

2. エンタングルメントと不透明型カプセル化

エンタングルメント対を不透明型にカプセル化し、組合操作のみを提供して分解を禁止します:

yaoxiang
# 組み込み不透明型
BellPair: Type0 = primitive_bell_pair

# 組み込み関数 - 全体でのみ操作可能
CNOT: (Qubit, Qubit) -> BellPair
measure_bell: (BellPair) -> { Int, Int }
split_bell: (BellPair) -> { Qubit, Qubit }  # エンタングルメント対を分解(注意して使用)
apply_cnot_to_bell: (BellPair, Qubit) -> BellPair

鍵となる設計:

  • フィールドアクセサー提供せず、組み込み関数を介して全体でのみ操作可能
  • measure_bell(bp) はエンタングルメント対全体を一度に消費し、古典ビットを返す
  • コンパイラはエンタングルメント対の完全なライフタイムを追跡可能

Python/Qiskit との比較:

Python (Qiskit): 実行時に回路を構築し、エラーは送信後に才发现
YaoXiang:       コンパイル時にほとんどの論理エラーを検出

残りの 10%(物理デコヒーレンス、ゲートエラーなど)はハードウェア問題であり、言語では解決できません。

3. 物理トポロジ制約

量子チップは制約付きトポロジグラフであり、任意の2つの qubit で2量子ビットゲートを実行できるわけではありません。 YaoXiang はジェネリクス定数パラメータを使用してコンパイル時にトポロジ制約を保証します。

トポロジ型定義:

yaoxiang
# トポロジを型として定義し、隣接行列を含む
Topology: Type0 = primitive_topology

# 組み込みトポロジ定数
Linear8: Topology = topology(8)          # 線形8ビット: 0-1-2-3-4-5-6-7
Grid3x3: Topology = topology(3, 3)        # 3x3 グリッド
Ring16: Topology = topology(16, ring)    # リング16ビット

Qubit にトポロジと位置をバインド:

yaoxiang
# Qubit(T, N) - T はトポロジ型、N は定数位置パラメータ
q0: Qubit(Grid3x3, 0)   # Grid3x3 トポロジ、位置 (0,0)
q1: Qubit(Grid3x3, 1)   # Grid3x3 トポロジ、位置 (0,1)
q2: Qubit(Grid3x3, 2)   # Grid3x3 トポロジ、位置 (0,2)
q3: Qubit(Grid3x3, 3)   # Grid3x3 トポロジ、位置 (1,0)

ゲート操作の自動制約:

yaoxiang
# CNOT 型シグネチャはトポロジ制約を含む
CNOT: (T: Topology, I: Int, J: Int) -> (
    (Qubit(T, I), Qubit(T, J)) -> { Qubit(T, I), Qubit(T, J) }
) when adjacent(T, I, J)

# コンパイル時チェック
CNOT(q0, q1)  # ✅ Grid3x3 で (0,0) と (0,1) は隣接
CNOT(q0, q2)  # ❌ コンパイルエラー: (0,0) と (0,2) は隣接していない

adjacent コンパイル時制約:

  • adjacent はコンパイル時関数であり、トポロジの隣接行列を使用して静的チェックを実行します
  • 定数インデックスでは 100% コンパイル時検証
  • 動的インデックスでは実行時チェックコードを生成

仮想から物理へのマッピング:

yaoxiang
# コンパイル時に具体的な物理的位置が分からない?型推論を使用
q = qubit(Grid3x3)  # 位置 0 を自動割り当てし、後続の推論で使用

4. 所有権と量子状態の線形フロー

すべての量子操作は Move セマンティクスを遵守し、qubit のコピーを防止します:

yaoxiang
q = qubit(0)
q2 = q          # ❌ コンパイルエラー: q はすでに移動しており、使用不可
q = H(q)        # ✅ q を消費し、新しい q を返す
measure(q)      # ✅ q を消費し、その後は q が空になる
q = qubit(0)    # ✅ 空状態再利用

5. 自動並列化とDAGスケジューリング

Standard または Full Runtime 下では、DAGスケジューラが量子プログラムを自動的に分析します:

yaoxiang
apply_two_qubit_gates: () -> {Qubit, Qubit} = () => {
    q1 = H(qubit(0))
    q2 = H(qubit(0))
    # 上記2行はデータ依存関係がなく、DAG は自動的に並列実行
    CNOT(q1, q2)   # q1 と q2 に依存、自動的に待機
}
  • スケジューラは num_workers 設定(物理量子プロセッサ数)を活用して真の並列性を実現します。
  • ユーザーはゲート順序を手動で配置する必要はなく、データフローを記述するだけです。

6. ハイブリッド古典計算

古典コードと量子コードが完全に融合しています:

yaoxiang
grover_search: (target: Int) -> Int = () => {
    n = 4
    qubits = List(Qubit)()
    for i in 0..n {
        qubits.append(H(qubit(0)))
    }
    # 古典ループと量子操作の混合
    oracle(qubits, target)   # oracle は量子ゲート列
    qubits = diffusion(qubits)
    results = measure_all(qubits)
    return decode_result(results)   # 古典後処理
}
  • 同じ関数内で量子ゲートと古典制御フローを任意に混合できます。
  • 所有権システムは、量子変数が古典分岐で誤ってコピーされないことを保証します。

7. マルチバックエンドサポートアーキテクチャ

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   YaoXiang ソース │     │   型チェック     │     │   DAG 中間表現  │
│   (統一構文)      │────▶│   + 所有権分析   │────▶│   (データフロー) │
└─────────────────┘     └─────────────────┘     └────────┬────────┘


                          ┌─────────────────────────────────────────────┐
                          │           コード生成バックエンド (プラグイン式)    │
                          ├─────────────────┬───────────────────────────┤
                          │  QIR バックエンド  │  QCIS バックエンド              │
                          │  (汎用エコシステム) │  (国内量子命令セット)          │
                          ├─────────────────┼───────────────────────────┤
                          │  - .ll ファイル出力 │  - .qcis テキスト出力        │
                          │  - 複数 QPU 対応   │  - 中科院/国盾ハードウェア対応 │
                          └─────────────────┴───────────────────────────┘
  • コンパイルフロー: フロントエンド統一 → DAG構築 → バックエンド選択 → ターゲットコード生成。
  • QIR バックエンド: DAGノードを QIR の量子ゲート intrinsic にマッピングし、LLVM bitcode を生成して、LLVM 最適化を適用可能。
  • QCIS バックエンド: DAG を QCIS 命令(例: H q0)にシリアライズし、量子チップコンソールに直接送信可能。

ベル状態の準備と測定

yaoxiang
bell_measure: () -> {Int, Int} = () => {
    q1 = H(qubit(0))
    q2 = H(qubit(0))
    bell = CNOT(q1, q2)  # BellPair 不透明型を返す
    result = measure_bell(bell)  # 2ビットを一度に測定
    return result
}

量子テレポーテーション(簡略版)

yaoxiang
teleport: (msg: Qubit, bell: BellPair) -> Qubit = (msg, bell) => {
    # エンタングルメント対を分解して2つの独立した qubit を取得
    (alice_qubit, bob_qubit) = split_bell(bell)

    # Alice の操作
    (msg, alice_qubit) = CNOT(msg, alice_qubit)
    msg = H(msg)
    a1 = measure(msg)
    a2 = measure(alice_qubit)

    # 古典情報の転送(スケジューラが自動的に依存関係を処理)
    # Bob の操作
    if a2 == 1 { bob_qubit = X(bob_qubit) }
    if a1 == 1 { bob_qubit = Z(bob_qubit) }
    return bob_qubit
}

詳細設計

組み込み型と関数定義

compiler/builtins モジュールに追加:

rust
builtins.insert("Qubit", Ty::Primitive(Primitive::Qubit));
builtins.insert("Complex", Ty::Record(vec![
    ("re", Ty::Primitive(Primitive::Float)),
    ("im", Ty::Primitive(Primitive::Float)),
]));

// 量子ゲート
for (name, sig) in GATES {
    builtins.insert(name, Ty::Function(vec![Ty::Qubit], Ty::Qubit));
}
builtins.insert("CNOT", Ty::Function(
    vec![Ty::Qubit, Ty::Qubit],
    Ty::Record(vec![
        ("q0", Ty::Qubit),
        ("q1", Ty::Qubit)
    ])
));
builtins.insert("measure", Ty::Function(vec![Ty::Qubit], Ty::Primitive(Primitive::Int)));
builtins.insert("qubit", Ty::Function(vec![Ty::Primitive(Primitive::Int)], Ty::Qubit));

所有権チェッカーの Qubit 特殊処理

  • Qubit!Copy(デフォルト Move)としてマークされ、暗黙的なコピーが禁止されます。
  • 測定関数 measure のパラメータは Qubit(値渡し)であり、所有権を消費します。
  • 複数 qubit ゲートが返すレコード型では、フィールドはすべて Qubit であり、所有権ルールを遵守する必要があります。

DAGスケジューラの量子ゲート最適化

  • 量子ゲートノードは純粋関数(副作用なし)として扱われ、スケジューラは依存関係のないゲートを自由に再配置できます。
  • スケジューラは「量子命令列」を出力する際、データ依存関係を保持し、並列ゲートをグループ化します(複数量子プロセッサに適用可能)。
  • --target-num-qubits--target-topology 設定をサポートし、後続のレイアウトとルーティングに使用します(将来拡張)。

QIR バックエンドの詳細マッピング

YaoXiang 操作QIR 命令
H(q)call void @__quantum__qis__h__body(%Qubit* %q)
CNOT(q1, q2)call void @__quantum__qis__cnot__body(%Qubit* %q1, %Qubit* %q2)
measure(q)%result = call i1 @__quantum__qis__mz__body(%Qubit* %q)
qubit(0)%q = call %Qubit* @__quantum__rt__qubit_allocate()

QIR バックエンドは LLVM の -O2 をさらに活用し、QIR Alliance 互換の bitcode を出力します。

QCIS バックエンドの詳細マッピング

YaoXiang 操作QCIS 命令
H(q) (q は物理ビット 2 に対応)H 2
CNOT(q1,q2) (q1→ビット 0, q2→ビット 1)CNOT 0 1
measure(q) (ビット 0)M 0
qubit(0) 初期化最初使用命令に暗黙含み、追加命令不要
  • 仮想 qubit(YaoXiang 変数)から物理ビットへのマッピングテーブルを維持する必要があります。
  • トポロジ制約チェックをサポート(将来実装)。

ハイブリッド古典コード生成

  • 古典部分(ループ、条件、整数演算など)は通常通りローカルコード(x86/ARM)を生成し、FFI または埋め込み呼び出しで量子バックエンドと対話します。
  • QIR バックエンドでは、古典部分は LLVM IR にデグレード可能で、QIR と混合コンパイルされます。

型システムへの影響

  • QubitComplex の新しいプリミティブ型を追加します。
  • Qubit は自動的に Move セマンティクスを持ち、コピーが禁止されます。
  • 量子ゲート関数シグネチャは型システムに登録する必要があります。

後方互換性

  • ✅ 完全な後方互換性
  • 新規組み込み型と関数の追加は既存コードに影響しない
  • 量子特性はオプションであり、有効化しない場合は追加オーバーヘッドなし

トレードオフ

メリット

  • 新構文なし: 開発者は少数の組み込み関数を学ぶだけで量子プログラムを記述できます。
  • 型安全性: 所有権システムが自動的に qubit コピーを防止し、一般的な量子プログラミングエラーを回避します。
  • 自動並列化: DAGスケジューラがゲートレベル並列化を無料で提供し、追加のコンパイラ最適化が不要です。
  • エコシステム互換性: QIR バックエンドにより YaoXiang は複数の量子クラウドプラットフォームで実行可能; QCIS バックエンドにより自律制御が可能になります。
  • ハイブリッド機能: 古典-量子融合が自然であり、複雑な量子アルゴリズム(Shor、Grover 内の古典制御など)の記述に適しています。

デメリット

  • Qubit 数の静的性: 現在の設計では qubit 数はコンパイル時に既知と想定されており、動的割り当ては List(Qubit) を使用する必要がありますが、List のヒープ割り当ては追加オーバーヘッドをもたらす可能性があります(最適化で緩和可能)。
  • 測定後の再利用: 空状態再利用により qubit の再初期化が可能ですが、物理量子ビットには弛緩時間があるかもしれず、実行時システムで処理する必要があります(現状はユーザーが担当)。
  • 動的トポロジマッピング: 実行時に物理トポロジが初めてわかる場合、コンパイル時チェックが有効にならず、実行時チェックコードを生成する必要があります(現在のバージョンは静的チェックのみサポート)。

代替方案

方案为什么不選択
quantum キーワードと circuit 型を導入新構文の追加により学習コストが高くなり、YaoXiang の簡潔設計原則に反する
量子サポートをライブラリとしてのみ実装コンパイラによる量子状態安全性の保証がなく、DAGスケジューラとの深い統合を実現できない
量子ハードウェアの成熟を待ってからサポート量子プログラミング言語設計の重要なウィンドウ期を逃がす
既存の量子フレームワーク(Qiskitなど)を再利用量子セマンティクスがライブラリで実装されるため、型システムと所有権システムの安全保証を получатьできない
量子サブ言語を別途設計言語複雑度が増加し、メンテナンスコストが高い

実装策略

段階的分化

段階期間内容
Phase 11ヶ月基礎量子型と組み込み関数: コンパイラに QubitComplex 型を追加し、組み込み関数の型チェックを実装し、所有権チェッカーを拡張
Phase 21ヶ月DAGスケジューラの量子ゲート認識: DAG構築ロジックを修正し、量子ゲートを純粋関数としてマークし、並列ゲートグループ出力 реализация
Phase 32ヶ月QIR バックエンドプロトタイプ: DAG から QIR コードジェネレータを実装し、LLVM を統合し、QIR シミュレータに接続して検証
Phase 42ヶ月QCIS バックエンドプロトタイプ: DAG から QCIS 命令への翻訳を実装し、仮想-物理ビットマッピングを設計し、国内量子プラットフォームに接続して検証
Phase 52ヶ月ハイブリッド古典機能強化: 古典制御フローと量子ゲートの交差が正しくコード生成されることを保証し、List(Qubit) をサポートし、サンプルプログラムを追加
Phase 62ヶ月最適化とドキュメント: 基本レイアウトとルーティングを実装し、ユーザーガイドと量子プログラミングチュートリアルを编写し、プレビュー版をリリース

リスク

  1. 量子ハードウェア可用性: 外部量子シミュレーターと実際の QPU の可用性に依存します。

    • 軽減: オープンソースシミュレーター(QIR runner、Qiskit Aer)に優先的に接続し、実際の QPU は長期目標とします。
  2. バックエンド実装の複雑性: QIR と QCIS 仕様は変更される可能性があります。

    • 軽減: コード生成インターフェースを抽象化し、バックエンド差異を隔离して、後続の適応を容易にします。
  3. パフォーマンスの不確実性: 量子プログラムのパフォーマンス特性は古典プログラムとは異なります。

    • 軽減: パフォーマンスプロファイリングツールを提供し、ユーザーがゲートレベル並列効果を理解できるようにします。

オープン問題

  • [x] トポロジ制約: Qubit(Topology, N) ジェネリクス定数パラメータでコンパイル時チェックを既に実装済み。
  • [ ] 動的量子レジスタ: List(Qubit) は QCIS バックエンドでどのようにマッピングするか?対応する物理ビット数を生成できますが、実行時割り当てメカニズムが必要です。
  • [ ] エラー緩和: 動的デコヒーレンスなどの組み込みエラー緩和構造を提供するかどうか?まずライブラリとして実装可能です。
  • [ ] 既存の量子SDKとの相互運用性: QASM または QIR モジュールのインポート能否?将来 FFI を検討可能。
  • [ ] 自動レイアウトとルーティング: 仮想 qubit 数が物理 qubit 数を 초과する場合、自动マッピング 方法?

参考文献


ライフサイクルと行き先

┌─────────────┐
│   草案      │  ← 著者作成
└──────┬──────┘


┌─────────────┐
│  審査中     │  ← コミュニティ議論
└──────┬──────┘

       ├──────────────────┐
       ▼                  ▼
┌─────────────┐    ┌─────────────┐
│  承認済み   │    │  拒否済み   │
└──────┬──────┘    └──────┬──────┘
       │                  │
       ▼                  ▼
┌─────────────┐    ┌─────────────┐
│   accepted/ │    │    rfc/     │
│ (正式設計)  │    │ (元の位置を保持) │
└─────────────┘    └─────────────┘

ステータス説明

状態場所説明
草案docs/design/rfc/draft/作成者草稿、審查提出待ち
審査中docs/design/rfc/コミュニティ議論とフィードバックを開放
承認済みdocs/design/accepted/正式設計ドキュメントとなり、実装段階に入る
拒否済みdocs/design/rfc/RFC ディレクトリに保持、ステータスを更新