c13d9c045e
## 主な成果 - Nyashスクリプトでプラグイン作成可能という革命的発見 - C ABI制約の分析と埋め込みVMによる解決策 - MIR/VM/JIT層での箱引数サポートの詳細分析 ## ドキュメント作成 - Phase 12基本構想（README.md） - Gemini/Codex先生の技術分析 - C ABIとの整合性問題と解決策 - 埋め込みVM実装ロードマップ - 箱引数サポートの技術詳細 ## 重要な洞察 - 制約は「リンク時にC ABI必要」のみ - 埋め込みVMでMIRバイトコード実行により解決可能 - Nyashスクリプト→C ABIプラグイン変換が実現可能 Everything is Box → Everything is Plugin → Everything is Possible!
3.2 KiB
3.2 KiB
🚨 重大な設計問題：スクリプトプラグインとMIR/EXEの非互換性
問題の本質
MIR/JIT/AOT（EXE）は、C ABIの関数しか呼び出せない。
現実のフロー:
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に埋め込み
- ネイティブプラグインと完全に透過的な利用
✅ 可能なこと
-
インタープリターモード限定
- スクリプトプラグインはインタープリター実行時のみ
- 開発/プロトタイピング用途
-
トランスパイル方式
- Nyashスクリプト → C/Rust → ネイティブプラグイン
- ビルドステップが必要
-
ハイブリッド実行
- 開発時: スクリプトプラグイン（高速イテレーション）
- 本番時: ネイティブプラグイン（高性能）
修正された価値提案
開発フローの改善
1. アイデア → Nyashスクリプトでプロトタイプ
2. 動作確認 → インタープリターでテスト
3. 性能要求 → Rust/Cで再実装
4. 配布 → ネイティブプラグインとして
制限事項の明確化
- JIT/AOT: ネイティブプラグインのみ
- インタープリター: スクリプトプラグインも可
- EXE生成: ネイティブプラグインのみ含む
推奨アクション
-
Phase 12の再定義
- 「開発支援ツール」として位置づけ
- JIT/AOT統合は諦める
-
ドキュメント修正
- 制限事項を明確に記載
- 誤解を招く「透過的利用」を削除
-
代替案の検討
- Nyash→Rustトランスパイラー
- プラグインテンプレート生成ツール
重要な教訓：C ABIの制約は、システムプログラミングの本質的な制約である。