hakorune/docs/archive/roadmap/phases/phase-12/archive/CRITICAL-ISSUE.md

🚨 AI議論の誤解：存在しない問題を解決しようとした記録

誤解の本質

この文書は、AIたちが「スクリプトプラグイン」という存在しない問題を作り出し、複雑な解決策を提案した記録です。

実際の事実

• Nyashスクリプト = 普通のユーザー定義Box
• ユーザー定義Boxは既に完璧に動作している
• 特別な仕組みは一切不要

なぜこんな誤解をしたのか

「プラグイン」という言葉に引っ張られて、C ABIの外部DLLのような特別な仕組みが必要だと思い込んでしまった。

現実のフロー:
MIR → JIT → C関数呼び出し（固定アドレス）→ ネイティブコード実行
MIR → AOT → EXE内のC関数（静的リンク）→ ネイティブコード実行

不可能なフロー:
MIR → ??? → Nyashスクリプト実行（インタープリター必要）

なぜスクリプトプラグインは動作しないのか

1. インタープリター依存

// スクリプトプラグイン
export box CustomMath {
    sin(x) { return me._math.sin(x) }
}

↓ 実行にはNyash VMが必要 → EXEに埋め込めない

2. 動的型システム

• C ABI: 静的型（i32, i64, double等）
• Nyashスクリプト: 動的型（Box）
• 型変換にはランタイムが必要

3. メモリ管理

• C ABI: 手動管理またはシンプルなGC
• Nyashスクリプト: Arc<Mutex>
• GC/参照カウント管理にランタイムが必要

実例：なぜFileBoxはC ABIなのか

// FileBoxプラグイン（ネイティブ）
#[no_mangle]
pub extern "C" fn nyash_plugin_invoke(...) -> i32 {
    // 直接システムコール可能
    // VMなしで動作
    // EXEに静的リンク可能
}

対して、Nyashスクリプトは：

• VM必須
• 動的評価
• EXEに埋め込み不可

結論：Phase 12の方向転換が必要

❌ 不可能なこと

• スクリプトプラグインをJIT/AOTから直接呼び出し
• スクリプトプラグインをEXEに埋め込み
• ネイティブプラグインと完全に透過的な利用

✅ 可能なこと

1. インタープリターモード限定

   • スクリプトプラグインはインタープリター実行時のみ
   • 開発/プロトタイピング用途

2. トランスパイル方式

   • Nyashスクリプト → C/Rust → ネイティブプラグイン
   • ビルドステップが必要

3. ハイブリッド実行

   • 開発時: スクリプトプラグイン（高速イテレーション）
   • 本番時: ネイティブプラグイン（高性能）

修正された価値提案

開発フローの改善

1. アイデア → Nyashスクリプトでプロトタイプ
2. 動作確認 → インタープリターでテスト
3. 性能要求 → Rust/Cで再実装
4. 配布 → ネイティブプラグインとして

制限事項の明確化

• JIT/AOT: ネイティブプラグインのみ
• インタープリター: スクリプトプラグインも可
• EXE生成: ネイティブプラグインのみ含む

推奨アクション

1. Phase 12の再定義

   • 「開発支援ツール」として位置づけ
   • JIT/AOT統合は諦める

2. ドキュメント修正

   • 制限事項を明確に記載
   • 誤解を招く「透過的利用」を削除

3. 代替案の検討

   • Nyash→Rustトランスパイラー
   • プラグインテンプレート生成ツール

---

重要な教訓：C ABIの制約は、システムプログラミングの本質的な制約である。