86b9f7719b
Phase 9.78b: Codexの天才的分析に基づくアーキテクチャ再設計準備 ## 📋 実施内容 1. Codex分析結果のアーカイブ - 実装詳細共有 → モデル共有・実行時共有への転換提案 - 8ステップの段階的実装計画 2. Phase 9.78a作業の保存 - MIR生成でのNewBox命令統一（保持） - ScopeTracker基本実装（一時コメントアウト） - VM拡張の方向性（TODOコメント付き） 3. ビルドエラー修正 - ScopeTrackerインポート問題を一時的に解決 - ビルド成功（警告のみ） ## 📚 作成ドキュメント - architecture-redesign-proposal.md - Codexの設計提案 - phase_9_78b_interpreter_architecture_refactoring.md - 実装計画 - codex-analysis/* - 分析結果アーカイブ ## 🎯 次のステップ Phase 9.78b Step 1: BoxDeclarationをcore::modelへ移動
91 lines
3.5 KiB
Plaintext
91 lines
3.5 KiB
Plaintext
Nyashプログラミング言語のインタープリター・VM統合アーキテクチャ再設計について深い分析をお願いします。
|
||
|
||
【背景】
|
||
Nyashは「Everything is Box」哲学のプログラミング言語で、現在インタープリターとVM（Phase 9.78a）の統合で設計上の問題に直面しています。
|
||
|
||
【現在の問題点】
|
||
|
||
1. **依存関係の逆転**
|
||
- BoxDeclarationがinterpreter::BoxDeclarationとして定義
|
||
- VMがインタープリターに依存してしまう
|
||
- 本来はAST層に属すべきデータ構造
|
||
|
||
2. **SharedState中心の設計**
|
||
```rust
|
||
pub struct SharedState {
|
||
pub global_box: Arc<Mutex<InstanceBox>>,
|
||
pub box_declarations: Arc<RwLock<HashMap<String, BoxDeclaration>>>,
|
||
pub static_functions: Arc<RwLock<HashMap<String, HashMap<String, ASTNode>>>>,
|
||
pub static_box_definitions: Arc<RwLock<HashMap<String, StaticBoxDefinition>>>,
|
||
pub included_files: Arc<Mutex<HashSet<String>>>,
|
||
}
|
||
```
|
||
- インタープリター固有の実装詳細に依存
|
||
- VMから使いにくい構造
|
||
|
||
3. **BoxFactory設計の混乱**
|
||
- BoxFactoryがtraitとして定義されている
|
||
- UserDefinedBoxFactoryがSharedStateに依存
|
||
- VMではArc<BoxFactory>でコンパイルエラー（dynが必要）
|
||
|
||
4. **グローバル副作用**
|
||
```rust
|
||
let factory = UserDefinedBoxFactory::new(shared.clone());
|
||
register_user_defined_factory(Arc::new(factory));
|
||
```
|
||
- グローバルレジストリへの登録
|
||
- テストや並行実行で問題
|
||
|
||
5. **VM実装の困難**
|
||
- インタープリターの実装詳細に依存
|
||
- 統一的なBox管理ができない
|
||
- birth/finiライフサイクルの不統一
|
||
|
||
【要求事項】
|
||
1. インタープリターとVMで共通のBox管理メカニズム
|
||
2. 依存関係の整理（AST → Runtime → Interpreter/VM）
|
||
3. テスタブルで並行実行可能な設計
|
||
4. シンプルで美しい実装
|
||
5. Everything is Box哲学の維持
|
||
|
||
【質問】
|
||
|
||
1. **アーキテクチャ全体の再設計**
|
||
- どのような層構造が最も美しく保守しやすいか？
|
||
- 依存関係をどう整理すべきか？
|
||
|
||
2. **BoxDeclarationの適切な配置**
|
||
- AST層に移動すべきか、それとも別の共通層を作るべきか？
|
||
- 必要な情報は何か？不要な情報は何か？
|
||
|
||
3. **SharedStateの解体**
|
||
- どの部分を共通ランタイムに移すべきか？
|
||
- インタープリター固有の部分はどう分離すべきか？
|
||
|
||
4. **BoxFactory/Registryの統一設計**
|
||
- traitベースか、具体的な構造体ベースか？
|
||
- プラグインシステムとの統合方法は？
|
||
|
||
5. **具体的な実装手順**
|
||
- 最小限の変更で最大の効果を得る順序は？
|
||
- 既存コードとの互換性を保ちながら進める方法は？
|
||
|
||
【理想の設計】
|
||
```rust
|
||
// 例：こんな感じ？
|
||
pub struct NyashRuntime {
|
||
box_registry: BoxRegistry,
|
||
type_definitions: HashMap<String, TypeDefinition>,
|
||
}
|
||
|
||
// インタープリターもVMも同じランタイムを使用
|
||
impl NyashInterpreter {
|
||
pub fn new(runtime: NyashRuntime) -> Self { ... }
|
||
}
|
||
|
||
impl VM {
|
||
pub fn new(runtime: NyashRuntime) -> Self { ... }
|
||
}
|
||
```
|
||
|
||
Nyashの「Everything is Box」哲学を活かしつつ、最もシンプルで美しく、保守しやすいアーキテクチャを提案してください。特に、天才的な洞察で問題の本質を見抜き、エレガントな解決策を示してください。 |