tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Major documentation reorganization and unified Box design updates

Browse Source 
## Documentation & Organization
- Moved copilot_issues.txt → 00_MASTER_ROADMAP.md (phases folder)
- Created Phase 9.79b.1 & 9.79b.2 plans for unified Box implementation
- Updated unified-box-design-deep-analysis.md with ChatGPT5 insights
- Added P2P documentation and examples (ping-pong, self-ping)

## Code Updates
- P2PBox: Reverted to original error state for demonstration
- VM: Enhanced BoxCall dispatch for unified approach
- Updated box factory, interpreter calls, and transport layer

## Cleanup & Privacy
- Removed private/ and private_test/ from git tracking
- Added private folders to .gitignore for security
- Cleaned root directory: moved backups, removed temp files
- Moved consultation files to docs/archive/consultations/

## Other Improvements
- Added object literal syntax improvement idea
- Updated CLAUDE.md with master roadmap reference
- Updated CURRENT_TASK.md with latest progress

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Moe Charm
2025-08-26 20:30:07 +09:00
parent 22212aa314
commit 6eda81f5db
41 changed files with 1446 additions and 3132 deletions
Download Patch File Download Diff File Expand all files Collapse all files

113
docs/archive/consultations/gemini_builtin_box_plugin_consultation.txt Normal file
View File

@ -0,0 +1,113 @@
Nyashプログラミング言語の革命的設計変更について深い技術的相談をお願いします。
【背景】
Nyashは「Everything is Box」哲学を掲げるプログラミング言語です。現在、3種類のBoxが存在します：
1. ビルトインBox（StringBox, IntegerBox等）- Rustで静的リンク
2. プラグインBox（FileBox等）- 動的ライブラリ（.so）で提供
3. ユーザー定義Box（box Person等）- Nyashコードで定義
【現状の問題】
現在、2つの異なるプラグインシステムが並存しています：
- plugin_loader.rs（1217行）: ビルトインBoxを動的ライブラリ化するシステム（未使用）
- plugin_loader_v2.rs（906行）: 汎用プラグインシステム（BID-FFI）
合計2000行以上の重複コードが存在し、メンテナンスが困難です。
【革命的提案：ビルトインBox完全プラグイン化】
すべてのBox（StringBox、IntegerBox含む）をプラグインとして実装する提案です。
```rust
// 現在
ビルトインStringBox → Rust静的リンク
プラグインFileBox → 動的ロード（.so）
// 提案
すべてのBox → プラグイン（.so）として統一
```
【実装案】
```rust
// コアBoxの定義
const CORE_BOXES: &[&str] = &[
"libnyash_string_box.so",
"libnyash_integer_box.so",
"libnyash_bool_box.so",
"libnyash_console_box.so", // print用
];
// 起動時自動ロード
fn main() {
for plugin in CORE_BOXES {
plugin_loader.load_required(plugin)?;
}
}
```
【期待されるメリット】
1. コード削減：plugin_loader.rs（1217行）を完全削除
2. 統一性：「Everything is Box」の究極の実現
3. 柔軟性：StringBoxすら置き換え可能（カスタムString実装など）
4. ビルド高速化：本体が軽量化
5. 配布の柔軟性：必要なBoxだけ選択可能
6. 開発の独立性：各Boxを独立して開発・テスト可能
【懸念事項と対策案】
1. パフォーマンス
- 懸念：FFI境界でのオーバーヘッド
- 分析：C関数呼び出しなのでナノ秒レベル、実用上問題なし？
2. デバッグの困難さ
- 懸念：エラー時のスタックトレースが不明瞭
- 対策案：
a) プラグイン側での詳細ロギング
b) デバッグシンボルの保持
c) プラグイン単体テストの充実
3. 起動時間
- 懸念：多数のプラグインロードで遅くなる？
- 対策案：コアBoxのみ必須、他は遅延ロード
4. 配布の複雑さ
- 懸念：実行ファイル+多数の.soファイル
- 対策案：標準パスに配置、設定ファイルで管理
【深く検討してほしい点】
1. 技術的妥当性
- この設計は本当に実現可能で健全でしょうか？
- 見落としている致命的な問題はありませんか？
2. パフォーマンスへの実影響
- FFIオーバーヘッドは本当に無視できるレベルでしょうか？
- 頻繁に呼ばれるメソッド（toString等）での累積的影響は？
3. エコシステムへの影響
- すべてがプラグインになることで、ライブラリ開発はどう変わりますか？
- パッケージマネージャーの設計にどんな影響がありますか？
4. 他言語での前例
- 同様のアプローチを採用した言語はありますか？
- 成功例・失敗例から学べることは？
5. セキュリティ
- コアBoxまでプラグイン化することのセキュリティリスクは？
- 悪意のあるStringBox置き換えなどへの対策は？
6. 開発体験
- デバッグの困難さは実際どの程度深刻でしょうか？
- IDE統合やデバッガサポートはどうなりますか？
7. 段階的移行戦略
- 一気に移行すべきか、段階的に移行すべきか？
- 既存ユーザーへの影響を最小化する方法は？
8. 長期的な保守性
- 5年後、10年後もこの設計は維持可能でしょうか？
- 技術的負債になる可能性は？
【最終的な問い】
「Everything is Box」哲学を実装レベルでも完全に実現するこの提案は、革新的な美しさか、それとも行き過ぎた純粋主義でしょうか？
実装の現実性、パフォーマンス、開発体験、エコシステムなど、多角的な視点から深い分析をお願いします。特に、この決定が言語の将来に与える影響について、時間をかけて考察していただければ幸いです。

170
docs/archive/consultations/mir_debug_infrastructure_consultation.txt Normal file
View File

@ -0,0 +1,170 @@
Nyash MIRレベルデバッグインフラストラクチャ設計相談
【背景】
NyashはMIR（中間表現）を経由して複数のバックエンドで実行されます：
- VM（現在実装済み）
- JIT（Phase 9で実装予定）
- AOT（将来実装）
- WASM（実装済み）
現在、デバッグ・メモリリーク検出・パフォーマンス解析機能をVM層で実装することを検討していますが、
MIRレベルで実装できれば、すべてのバックエンドで統一的に使える理想的な設計になります。
【技術的課題】
1. MIRは低レベル命令（26命令）で、高レベルのBox情報が失われる
- NewBox(type_id=6, args) → 6が何のBoxか分からない
- BoxCall(reg=0, "toString") → どのBox型のメソッドか不明
2. MIRは実行前の静的表現なので、実行時情報の追跡が困難
- Boxの生成・破棄タイミング
- メソッド実行時間の計測
- メモリ使用量の追跡
3. 各バックエンドでの実装の違い
- VM: スタックベース、インタープリター
- JIT: ネイティブコード生成
- WASM: 別の仮想マシン
【設計案1: MIRデバッグ命令の追加】
```rust
pub enum MIRInstruction {
// 既存の命令
NewBox(u16, Vec<u8>),
BoxCall(RegisterIndex, RegisterIndex, String, Vec<RegisterIndex>),
// デバッグ専用命令（本番では無視）
DebugBoxCreate(RegisterIndex, String), // Box型名を記録
DebugMethodEnter(String, Vec<RegisterIndex>), // メソッド開始
DebugMethodExit(RegisterIndex), // メソッド終了
DebugSnapshot(String), // 任意の時点のスナップショット
}
```
メリット：
- MIRレベルで完結
- すべてのバックエンドで同じデバッグ情報
デメリット：
- MIRが肥大化
- 本番実行時のオーバーヘッド
【設計案2: MIRメタデータの分離】
```rust
pub struct MIRModule {
pub functions: HashMap<String, MIRFunction>,
pub constants: Vec<Constant>,
pub debug_info: Option<MIRDebugInfo>, // デバッグ時のみ生成
}
pub struct MIRDebugInfo {
// 命令インデックス → デバッグ情報
instruction_map: HashMap<usize, InstructionDebugInfo>,
// type_id → Box型名
type_names: HashMap<u16, String>,
// ソースマップ
source_map: SourceMap,
}
```
メリット：
- MIR本体はクリーン
- デバッグ時のみメタデータ生成
デメリット：
- 実行時追跡には各バックエンドでのフック必要
【設計案3: MIRプロファイリング拡張】
```rust
pub trait MIRExecutor {
// 基本実行
fn execute(&mut self, module: &MIRModule) -> Result<(), Error>;
// プロファイリング付き実行
fn execute_with_profiling(
&mut self,
module: &MIRModule,
profiler: &mut dyn MIRProfiler
) -> Result<(), Error>;
}
pub trait MIRProfiler {
fn on_instruction(&mut self, pc: usize, inst: &MIRInstruction);
fn on_box_create(&mut self, type_id: u16, reg: RegisterIndex);
fn on_method_call(&mut self, receiver: RegisterIndex, method: &str);
// ...
}
```
メリット：
- 各バックエンドが同じプロファイラーインターフェースを実装
- 柔軟な拡張が可能
デメリット：
- 各バックエンドでの実装が必要
【設計案4: MIR静的解析による事前情報抽出】
```rust
pub struct MIRAnalyzer {
pub fn analyze(module: &MIRModule) -> AnalysisResult {
// Box生成パターンの検出
let box_creations = find_box_creations(&module);
// メソッド呼び出しグラフの構築
let call_graph = build_call_graph(&module);
// 潜在的なメモリリークパターン
let leak_patterns = detect_leak_patterns(&module);
AnalysisResult {
box_creations,
call_graph,
leak_patterns,
// ...
}
}
}
```
メリット：
- 実行前に多くの情報を取得
- オーバーヘッドなし
デメリット：
- 動的な振る舞いは追跡できない
【質問事項】
1. MIRレベルでのデバッグ実装について、どの設計案が最も実用的でしょうか？
2. 他の言語（LLVM IR、Java bytecode、.NET IL等）では、
このような問題をどのように解決していますか？
3. MIR命令セットの拡張 vs メタデータ分離、
どちらがパフォーマンスと保守性のバランスが良いでしょうか？
4. JIT/AOTコンパイル時にデバッグコードを埋め込む方法として、
効率的なアプローチはありますか？
5. WASMのような異なる実行環境でも統一的にデバッグ情報を
扱う方法についてアドバイスをお願いします。
【現在のMIR命令セット（26命令）】
- 基本: Const, Move, Copy
- 算術: Add, Sub, Mul, Div, Mod, Neg
- 比較: Eq, Ne, Lt, Le, Gt, Ge
- 論理: And, Or, Not
- Box: NewBox, BoxCall, GetField, SetField
- 制御: Br, Jmp, Call, Ret
- メモリ: RefNew, RefGet, RefSet
- 型: AsType, IsType
【Nyashの設計哲学】
- Everything is Box - すべてがBoxオブジェクト
- メモリ安全性重視
- 初学者フレンドリー
- 高速実行（VM実装で13.5倍高速化達成）
専門的な観点から、MIRレベルでの統一デバッグインフラストラクチャの
実現可能性と最適な設計についてアドバイスをお願いします。

93
docs/development/current/CURRENT_TASK.md
View File

@ -1,74 +1,51 @@
# 🎯 CURRENT TASK - 2025-08-26（Context Reset / Fresh Focus）
# 🎯 CURRENT TASK - 2025-08-26（Phase 9.79b Kickoff）
コンテキストを「0%」にリセットし、いま必要なことだけに集中するにゃ。
コンテキストを最小化して、次フェーズへの導線だけ残すにゃ。
## ⏱️ 今日のフォーカス（Phase 9.79a: Unified Dispatch + P2P Polish）
- 判断: 統一Box設計は「非侵襲のディスパッチ統一」から入る → P2PBox磨きを同時並行
- 目的: ユニバーサルメソッド（toString/type/equals/clone）をVM/Interpreter前段で統一 + P2PBoxのmulti-node/async UX安定化
## ⏱️ 今日のフォーカス（Phase 9.79b: Unified IDs → VM Thunks）
- 目的: Box種別（builtin/user/plugin）をMIR/VMで数値ID＋スロット統一に移行し、Phase 10(JIT)の足場を固める。
### 直近の実行タスク（小さく早く）
1) ユニバーサルメソッドの前段ディスパッチ（非侵襲）
- VM/Interpreterで`toString/type/equals/clone`を共通ヘルパにマップ（トレイト変更なし）
2) P2PBox磨き（multi-node/async/解除）
- share/cloneセマンティクス：share=共有, clone=新規（実装済みの明文化）
- unregisterの安全化（endpoint一致 or refcount）
- onOnce/off のE2Eテスト追加
- VM表示整合（getLast*/debug_* の toString/Console）
3) E2Eスモーク更新
- self→self, two-node ping-pong（安定）
- asyncデモ（TimeBox併用で確実に出力）
### 直近タスク（小さく早く）
1) 9.79b.1: Unified Registry IDs + Builder Slotting
- 型ID/メソッドスロットの導入（レジストリ）
- ユニバーサルメソッド低スロット予約（0..3）
- Builderが解決可能なBoxCallに`method_id`を付与（未解決は遅延）
2) 9.79b.2: VM VTable Thunks + Mono-PIC
- `execute_boxcall`をvtable+thunkの単一路線へ
- call-site単位のモノモーフィックPICを追加
### すぐ試せるコマンド（最小）
### すぐ試せるコマンド
```bash
# Rust（Release）
cargo build --release -j32
./target/release/nyash --help
# Plugin デバッグ実行（任意）
NYASH_DEBUG_PLUGIN=1 ./target/release/nyash --backend vm local_tests/extern_console_log.nyash || true
# WASM（Web配布）
cd projects/nyash-wasm && wasm-pack build --target web --out-dir pkg
./target/release/nyash examples/p2p_self_ping.nyash
./target/release/nyash examples/p2p_ping_pong.nyash
```
## 現在の地図（Done / Doing / Next）
## 現在の地図（Done / Next）
### ✅ 完了
- PluginHostファサード導入・移行（create/invoke/extern）
- TLVヘッダ/引数/ハンドルの共通化（`plugin_ffi_common.rs`）
- Interpreter分割の導線: `eval.rs` / `calls.rs` / `methods_dispatch.rs` 抽出
- ログ静音の基盤: `idebug!`（NYASH_DEBUG=1 で有効）を calls/core/statements に適用
- MIR modular builder ゲート追加（feature: `mir_modular_builder`）/ 整合パッチ投入
### ✅ 完了（9.79a）
- ユニバーサル前段ディスパッチ（toString/type/equals/clone）Interpreter/VM
- P2P unregister安全化・onOnce/off E2E・self/two-nodeスモーク
- IntentBoxのpayload糖衣（MapBox/JSONBox直渡し可）
- Docs: P2Pリファレンス/サンプル
### 🚧 進行中（小タスク）
- Interpreterログ統一の残り（`delegation.rs` など）
- PluginHost の `resolve_method` キャッシュ化（I/O削減）
### ⏭️ 次（9.79b）
- 9.79b.1: `phase_9_79b_1_unified_registry_ids_and_builder_slotting.md`
- 9.79b.2: `phase_9_79b_2_vm_vtable_thunks_and_pic.md`
### ⏭️ 次アクション（今日～明日）
- 9.79a-M1: ユニバーサル前段ディスパッチ（VM/Interpreter）/ 回帰確認
- 9.79a-M2: P2P unregister安全化 + onOnce/off E2E + async安定
- 9.79a-M3: VM表示整合/ Docs更新（言語ガイド・P2Pリファレンス）
## 統一Box設計メモ（唯一参照）
- `docs/ideas/other/2025-08-25-unified-box-design-deep-analysis.md`
- 数値ID/スロット/Thunk/PIC/DebugInfoの全体像
## 決定事項（Unified Box設計メモ）
- ドキュメント: `docs/ideas/other/2025-08-25-unified-box-design-deep-analysis.md`
- 判断: まずはディスパッチャ層でユニバーサルメソッドを統一（トレイト変更なし）
- P2Pは共有セマンティクス（share=共有, clone=新規）を維持しつつ unregister 正式化へ
## 参考リンク（唯一参照/ゲート）
- MIR命令セット（26命令）: `docs/reference/mir/INSTRUCTION_SET.md`
- Phase 9.79（P2P）: `docs/development/roadmap/phases/phase-9/phase_9_79_p2pbox_rebuild.md`
- Phase 9.79a（Unified Dispatch + P2P Polish）: `docs/development/roadmap/phases/phase-9/phase_9_79a_unified_box_dispatch_and_p2p_polish.md`
- Phase 9.78h（前段完了）: `docs/development/roadmap/phases/phase-9/phase_9_78h_mir_pipeline_stabilization.md`
## 参考リンク
- MIR命令セット: `docs/reference/mir/INSTRUCTION_SET.md`
- Phase 9.79a（完了）: `docs/development/roadmap/phases/phase-9/phase_9_79a_unified_box_dispatch_and_p2p_polish.md`
- Phase 9.79b（計画）:
- `docs/development/roadmap/phases/phase-9/phase_9_79b_1_unified_registry_ids_and_builder_slotting.md`
- `docs/development/roadmap/phases/phase-9/phase_9_79b_2_vm_vtable_thunks_and_pic.md`
- Phase 10（Cranelift JIT主経路）: `docs/development/roadmap/phases/phase-10/phase_10_cranelift_jit_backend.md`
## Doneの定義（P2PBox 最小）
- `LocalLoopback` で ping/pong が安定
- P2PBox API（start/stop/send/broadcast/reply/on）が固まる
- ResultBox経由でエラーが伝搬（E2E テスト含む）
- ログは既定静音（環境変数でデバッグオン）
## Parking Lot（後でやる）
- NyashValue enum導入（即値最適化）
- NyashValue即値最適化・演算子特化
- トレイト階層化（Comparable/Arithmetic etc.）
- メタプログラミング・パイプライン演算子
- `mir_modular_builder` をデフォルト化（パリティ後）
- オブジェクトリテラル糖衣（feature `object_literal`）提案: `docs/ideas/improvements/2025-08-26-object-literal-sugar.md`

494
docs/development/roadmap/native-plan/copilot_issues.txt
View File

@ -1,494 +0,0 @@
# 🤖 Copilot様 作業予定・課題整理 (Phase 8.6-10 重点フェーズ)
# Generated: 2025-08-19 (Phase 9.75g-0完了・VM性能改善移行)
# Purpose: Claude×Copilot協調開発のための情報共有
================================================================================
🎯 Nyash実行モード併用戦略
================================================================================
## 🌟 インタープリター＋コンパイラ併用の価値
### 実行モード使い分け
```
開発時: インタープリター（デバッグ・即時実行・非同期フル対応）
本番時: インタープリター（Pythonのように実用的）
OR
WASM/AOT（性能要求時）
配布時: AOT native（最高性能）
Web時: WASM（ブラウザ対応）
```
### インタープリターの強み
- **即時実行**: コンパイル不要で高速開発
- **デバッグ容易**: 実行時情報の完全把握
- **非同期完全対応**: Rust async/awaitで真の並行処理
- **動的性**: 実行時評価・REPL対応
- **十分な性能**: 多くのユースケースで実用的（Pythonが証明）
================================================================================
🎯 Phase 8.6-10 開発ロードマップ (性能最適化・LLVM実装重点)
================================================================================
## 🎊 Phase 9.75g-0: BID-FFI Plugin System - 完全完了！ ✅
Summary:
- ✅ **動的プラグインシステム完成**: FileBoxプラグインで実証
- ✅ **BID-FFI基盤確立**: 型安全なFFIインターフェース
- ✅ **plugin-tester完成**: 汎用プラグイン診断ツール
- ✅ **型情報管理システム**: nyash.toml外部化、セグフォルト修正
**革命的成果**: NyashがプラグインでBox型を動的拡張可能に！
```nyash
// これが現実になった！
local file = new FileBox() // プラグイン提供
local db = new PostgreSQLBox() // 将来: プラグイン提供
local gpu = new CudaBox() // 将来: プラグイン提供
```
References:
- docs/Phase-9.75g-0-BID-FFI-Developer-Guide.md (包括的開発者ガイド)
- tools/plugin-tester/ (プラグイン診断ツール)
------------------------------------------------------------
## 🚨 Phase 8.6: VM性能改善 - 最優先課題（進行中）
Summary:
- **緊急問題**: VMがインタープリターより0.9倍遅い（性能回帰！）
- **目標**: 2倍以上高速化でVM実行を実用レベルに引き上げ
- **担当**: Copilot主導（GitHub Issue #112）
Priority: **Critical**
Expected Duration: 1-2週間
GitHub Issue: #112 (Phase 8.6 VM性能改善)
### 技術的課題
```bash
# 現状のベンチマーク結果
Interpreter: 110.10ms (ベースライン)
VM: 119.80ms (0.9倍 - 遅い...)
Target: 55.00ms (2倍高速化目標)
```
### 推定原因と対策
- **デバッグ出力過多**: `println!`による性能劣化
- **HashMap操作重い**: ValueId → VM値の変換コスト
- **命令ディスパッチ非効率**: switch文ベースディスパッチ
### 🤖 Copilot協力期待
- VM実行時間詳細測定・プロファイリング
- 命令ディスパッチ最適化（direct threading等）
- Box操作インライン化・メモリレイアウト最適化
References:
- docs/予定/native-plan/issues/phase_8_6_vm_performance_improvement.md
------------------------------------------------------------
## 📦 Phase 9.8: BIDレジストリ + 自動コード生成ツール - MIR統合の要
Summary:
- **Phase 9.75g-0完了により準備完了**: プラグインがMIR経由で全バックエンド利用可能に
- BIDレジストリと、BID→各ターゲットのスタブ生成（import/extern宣言）を自動化
Priority: **High** (Phase 8.6完了直後)
Expected Duration: 2-3週間
### 🌟 革命的価値
```bash
# 🎯 1つのプラグインが4バックエンド全対応！
nyash bid gen --target wasm bid.yaml # WASM用import生成
nyash bid gen --target vm bid.yaml # VM用関数テーブル生成
nyash bid gen --target llvm bid.yaml # AOT用declare生成（LLVM実装時）
```
### Scope/Tasks
- BIDレジストリ仕様（署名・効果・バージョン・依存関係）
- 生成: WASM(importObject), VM(関数テーブル), LLVM(declare), TS/Python(RTEラッパ)
- CLI: `nyash bid gen --target wasm|vm|llvm|ts|py bid.yaml`
### Acceptance
- console/canvasのBIDから各ターゲットの骨子が自動生成される
- **FileBoxプラグインがVM・WASM・AOT全てで動作**
------------------------------------------------------------
## 🔒 Phase 9.9: ExternCall 権限/ケイパビリティモデル（Sandbox/Allowlist）
Summary:
- 外部API呼び出しの安全化。BIDに必要権限を宣言し、ホスト側で許可/拒否。WASMはimport allowlist、VM/LLVMは関数テーブルで制御。
Scope/Tasks:
- 権限種別（console, canvas, storage, net, audio...）とポリシー
- 実行時プロンプト/設定ファイル/環境変数での許可
- 失権時の挙動（明示エラー）
Acceptance:
- 禁止権限のExternCallが実行時にブロックされ、明確なエラーが返る
------------------------------------------------------------
## 🧱 Phase 9.10: NyIR（公開IR）仕様化 + フォーマット + 検証器
Summary:
- 26命令MIRを公開IR（NyIR v1）として基本セマンティクス凍結。バージョニング、バイナリ`.nybc`/テキスト`.nyir`、厳格検証器を用意。
Scope/Tasks:
- docs/nyir/spec.md（Core＋Ext骨子）
- nyir-parser/nyir-serializer（.nyir/.nybc）
- Verifier: 所有森/weak/効果/Bus整合
- ツール: `nyashel -S`, `nyir-run`
Acceptance:
- 代表サンプルがNyIRで保存・検証・実行可能
References:
- docs/nyir/spec.md
- docs/予定/native-plan/issues/phase_9_10_nyir_spec.md
------------------------------------------------------------
## 🧪 Phase 9.11: Golden NyIR + Differential 実行テスト（CI）
Summary:
- NyIRダンプをゴールデンとし、interp/vm/wasm/jitの出力一致をCIで検証。
Scope/Tasks:
- golden/*.nyir の整備
- CIで各バックエンド実行→結果一致チェック
Acceptance:
- 主要サンプルで全バックエンド一致
------------------------------------------------------------
## 🏆 Phase 10: Cranelift JIT（主経路） + LLVM AOT（後段研究）
Summary:
- **主経路**: MIR→VMを維持しつつ、ホットパスをCraneliftでJIT化して2倍以上の高速化を狙う
- **LLVM AOT**: 設計資産は維持しつつ、JIT安定後（Phase 11以降）に検討
- **目標**: VMのホットパス（BoxCall/Array/Map）で体感高速化、ベンチで優位性を実証
Priority: **High**（Phase 8.6完了直後着手）
Expected Duration: **実装6-8週間（段階導入）**
### 🚧 Start Gate（着手前の必須完了）
- MIRダイエット（26命令）整合完了：Printer/Verifier/Optimizer一致・効果ラベル統一
- Loop SSA復帰：Phi/Seal/Pred更新のVerifierチェック合格
- TypeOp網羅：is/as/isType/asTypeの早期lowering＋Optimizer診断（未lowering検出）
- 軽量スナップショット：TypeOp/extern_call/loop/await/boxcallでゴールデン緑
- P2PBox再設計（Phase 9.79）完了・E2Eグリーン
- CLI分離テスト導線（`cargo test -p core`）安定
### 🔍 実現可能性チェック項目（Cranelift）
- ✅ **技術的基盤**: MIR26整合（TypeOp/WeakRef/Barrier）
- ✅ **VM統計**: `--vm-stats` でホット関数抽出可能
- 🔄 **Proof of Concept**: MIR→CLIFの最小Lower（算術/比較/分岐）
- ❓ **実装工数**: BoxCall/Array/MapのJIT最適化の妥当性
### 🌟 インタープリター併用戦略
```
開発・デバッグ: インタープリター（即時実行・完全な情報）
軽量タスク: インタープリター（Pythonライク）
性能要求時: LLVM AOT（1000倍高速化）
Web配布: WASM（ブラウザ対応）
```
### 🏗️ Phase 10.1: Proof of Concept（2週間）
Steps:
1) **JITマネージャ**: プロファイル収集・しきい値設計
2) **MIR→CLIF最小Lower**: Const/BinOp/Compare/Branch/Return
3) **呼出しABI**: VMとの引数/戻り値・BoxRef受け渡し
### 🏗️ Phase 10.2: 基本実装（4週間）
Implementation Steps:
1) `src/backend/cranelift/` 基盤構築
2) MIR→CLIF Lowerの拡充（Call/BoxCall/Array系）
3) JIT関数テーブル + VM切替の安定化
4) ベンチ: VM比2×目標、BoxCallホットパス優位
### 🌐 Phase 10.3: 非同期の扱い（最小）
- awaitは当面VM側で処理継続（JIT対象外）
- JIT関数は同期区間を優先（将来拡張）
### 技術アプローチ
🤖 Copilot協力期待:
- **Cranelift統合**: MIR→CLIF Lower
- **VMハイブリッド**: JITスイッチ・例外/フォールバック
- **ホットパス最適化**: BoxCall/Array/Mapの直結最適化
### パフォーマンス目標
- **同期処理**: VM比 2×以上（段階的に引き上げ）
- **起動時間**: 低オーバーヘッド（JIT初回コストを隠蔽）
### Acceptance Criteria
- インタープリター/VMとの互換性（結果一致）
- ホットパスでの実測高速化（2×）
- 回帰テスト・スナップショットの整備
References:
- docs/予定/native-plan/issues/phase_10_x_llvm_backend_skeleton.md
### 🌟 戦略的決定: ネームスペース統合はLLVM後に実施
**理由**: 4バックエンド（Interpreter/VM/WASM/LLVM）全体の知見蓄積後に、最適化された統合設計を一回で実現するため
**効果**: 後戻り・再設計なしで完璧な統合ネームスペースを実装可能
```rust
// Phase 10完了後: 4バックエンド対応統合ネームスペース
pub struct UniversalNamespaceManager {
interpreter_cache: BuiltinCache,
vm_function_table: VmFunctionTable,
wasm_import_object: WasmImports,
llvm_module_linking: LlvmLinker, // LLVM完成後追加
}
```
------------------------------------------------------------
## 🧰 Phase 10.1: LLVM 外部関数マッピング方針（プラットフォーム抽象）
Summary:
- ExternCallのFQN→ネイティブ関数（printf等）への写像レイヤーと、OS差の抽象。初手はLinux/clang、他OSは後続。
Scope/Tasks:
- env.console.log → printfテンプレート、他は段階的拡張
- プラットフォーム切替（feature）とリンク方針
Acceptance:
- 代表ExternCall（console.log）がAOTバイナリで出力可能
------------------------------------------------------------
## 🧩 Phase 10.2: Host API層（C-ABI `ny_host_*` / WASM `nyir_host`）
Summary:
- Rust依存を薄い宿主APIへ集約。C-ABI公開（ファイル/メモリ/時間等）、WASMは`nyir_host` importで提供。
Scope/Tasks:
- `ny_host_*`関数群（read_file/free/clockなど）をC-ABIで実装
- Nyash側extern宣言と所有移管`*_from_raw`/`*_into_raw`
- WASM: import `nyir_host` 名前空間で最低限の関数提供
Acceptance:
- 代表I/OがHost API経由で動作し、Rust実装置換が容易
------------------------------------------------------------
## 🧱 Phase 10.3: ランタイム層の切り分け（corelang/rt/sys/std）
Summary:
- corelang（純Nyash）, rt（Box ABI/所有/weak/Safepoint/Bus）, sys（プラットフォーム）, std（Nyash実装）に整理。
Scope/Tasks:
- ドキュメント化＋最小コードの配置替えスケルトン
Acceptance:
- 層構造が明文化され、新規実装がガイドに従って進められる
------------------------------------------------------------
## 🧬 Phase 10.4: Box ABI（fat ptr）とLLVM属性（Effects）
Summary:
- Boxのfat pointer（data*, typeid, flags）の定義、Weakの世代タグ、SafepointのLLVM降ろし、Effect→LLVM属性（readonly/readnone等）。
Scope/Tasks:
- LLVM IR側のstruct宣言・属性付与の雛形
Acceptance:
- 代表関数で属性が付与され、最適化に寄与（noalias/argmemonly等は可能な範囲で）
------------------------------------------------------------
## 📚 Phase 10.5: コア標準（String/Array/Map）Nyash実装（Rust依存の段階的削減）
Summary:
- 現在Rust実装に依存している基本コンテナ（String/Array/Map）を、rt/sys層を活用してNyash実装に置換。
Scope/Tasks:
- String: {ptr,len,cap}, new/push_str/substr/len、`ny_host_alloc/realloc/free`
- Array<T>: {ptr,len,cap}, push/get/set/len/reserve、要素fini
- Map<K,V>: 簡易hash、set/get/remove/len、所有規則順守
Acceptance:
- 代表サンプルでString/Array/MapがNyash実装で動作し、Rust実装をリンクせずに通る
References:
- docs/予定/native-plan/issues/phase_10_5_core_std_nyash_impl.md
## Phase 11-14: Infrastructure & Polish
### Phase 11: MIR Optimization Framework
- エスケープ解析基盤
- 型特殊化・ボックス化解除
- デッドコード除去
### Phase 12: Advanced JIT Features
- Profile-guided optimization
- インライン展開
- レジスタ割り当て最適化
### Phase 13: Production Readiness
- GC統合最適化
- メモリ使用量最適化
- 起動時間短縮
### Phase 14: Packaging/CI polish
Summary:
- Windows/Linux の配布パッケージ化と CI 整備。
Scope/Tasks:
- GitHub Actions: Windows(MSVC)/WSL+cargo-xwin のマトリクス
- dist/: nyash(.exe) + LICENSE/README 同梱
Acceptance Criteria:
- リリースアーティファクトが自動生成される
================================================================================
🧠 AI大会議 + 実用優先戦略で得られた技術的知見 (2025-08-14更新)
================================================================================
## Gemini先生の助言（修正適用）
✅ エスケープ解析・ボックス化解除が性能の鍵
✅ wasmtime compileは短期的に実用的 → **Phase 9で最優先実装**
✅ WASM実行は確実に高速（13.5倍実証済み）
🔄 Cranelift → LLVM段階的アプローチ → **実用優先でLLVM直接へ**
## codex先生の助言（重点化）
✅ MIR前倒し実装推奨（全バックエンドが恩恵）
✅ wasmtime互換性管理が重要 → **AOT実装で最重要**
✅ CPU差異対応 (baseline/v3二段ビルド)
✅ 起動時間・割当削減・配布体験がKPI → **AOT価値の核心**
## Claude統合分析（実用優先）
✅ 実用価値最大化: WASM+AOTで十分な競争力
✅ 開発効率: Cranelift JITの恩恵限定的（cargo build変わらず）
✅ Everything is Box最適化が差別化の核心
✅ 時間効率: 2-3ヶ月節約でLLVM集中投資
## 🎯 実用優先戦略の確定理由
- **ユーザー体験**: WASM既に動作、AOTで配布価値追加
- **開発効率**: Cranelift JITは重複投資（Rust開発環境改善せず）
- **競合優位**: AOT+LLVM早期実現で差別化
- **リソース効果**: 限られた開発時間の最大効率化
================================================================================
💡 Copilot様への具体的お願い・相談事項
================================================================================
## 🔧 Phase 8.6 VM性能改善 (最優先)
### VM実行時間詳細測定・プロファイリング
❓ 命令ディスパッチのボトルネック特定方法は？
❓ HashMap操作の最適化戦略は？
❓ デバッグ出力削除による性能改善測定は？
### VM最適化実装
❓ Direct threading実装の現実的アプローチは？
❓ Register-based VM への移行可能性は？
❓ Box操作インライン化の効果的な実装は？
## 🚀 長期戦略相談
### インタープリター併用戦略
❓ 開発時と本番時の最適な使い分け方法は？
❓ インタープリターとコンパイラの互換性保証は？
❓ Pythonライクな実用性の実現方法は？
### Phase 10 LLVM実現可能性調査 (研究段階)
❓ MIR→LLVM IR変換の基本的な実装戦略は？
❓ Box型のLLVM表現として最適なアプローチは？
❓ C-ABIとの統合によるプラグイン連携可能性は？
❓ 現実的な開発期間での完成可能性評価は？
### Everything is Box最適化
❓ Box操作の根本的高速化戦略は？
❓ エスケープ解析によるスタック化判定は？
❓ 型特殊化・ボックス化解除の実装戦略は？
### ベンチマーク戦略
❓ インタープリター/VM/WASM/LLVMの性能比較方法は？
❓ 非同期処理のベンチマーク設計は？
❓ 実用アプリケーションでの測定指標は？
================================================================================
📊 進捗管理・コミュニケーション
================================================================================
## 🤝 協調開発ルール
### コミット・マージ戦略
✅ 大きな変更前にはdocs/CURRENT_TASK.mdで情報共有
✅ ベンチマーク機能は最優先で維持
✅ CLI統合は両機能を統合的に対応
✅ 競合発生時は機能優先度で解決
### 進捗報告
📅 週次: 進捗状況をCURRENT_TASK.mdに反映
📅 完了時: 新機能のベンチマーク結果を共有
📅 問題発生: AI大会議で技術的相談
### 品質保証
✅ cargo check でビルドエラーなし
✅ 既存ベンチマークが regression なし
✅ 新機能のドキュメント整備
✅ テストケース追加・CI通過
================================================================================
🎯 期待される成果・インパクト
================================================================================
## Phase 8-9完了時の成果 (達成済み・進行中)
🏆 RefNew/RefGet/RefSet WASM完全動作
🏆 Box操作ベンチマーク追加
🏆 メモリレイアウト最適化効果測定
🏆 26命令MIR階層化完了（Phase 8.5）
🔄 **VM性能改善進行中（Phase 8.6）** - GitHub Issue #112
🏆 **Phase 9.75g-0 BID-FFI Plugin System完全完了**
🏆 警告削減100%達成（Phase 9.75j）
🏆 BoxCall実装・wasmtime更新（Phase 9.77）
## Phase 10以降の展望
🚀 **WASM復旧完了** (Phase 9.77): 基本機能の完全動作
🚀 **Cranelift JIT** (Phase 10): VM比2×以上の高速化（段階導入）
🚀 **非同期ネイティブ実装** (Phase 10.2): async/await完全対応
🚀 **インタープリター併用** : 開発・本番両対応
## 言語としての完成度向上
💎 Everything is Box哲学のネイティブ実現
💎 インタープリター＋コンパイラの最適併用
💎 4つの実行形態対応（Interpreter/VM/WASM/AOT）
💎 Pythonライクな実用性＋C++並みの性能
================================================================================
📞 連絡・相談方法
================================================================================
技術的相談や進捗報告は、以下の方法でお気軽にどうぞ：
1. 📝 GitHub Issues・Pull Request
2. 📋 docs/CURRENT_TASK.md コメント
3. 🤖 AI大会議 (重要な技術決定)
4. 💬 コミットメッセージでの進捗共有
どんな小さなことでも相談大歓迎です！
一緒にNyashを最高の言語にしていきましょう🚀
================================================================================
最終更新: 2025-08-19 (Phase 9.75g-0完了・VM性能改善最優先・LLVM調査段階化)
作成者: Claude (BID-FFIプラグインシステム完了 + 最新優先順位反映)
🎯 重要な変更点:
- ✅ **Phase 9.75g-0 BID-FFI Plugin System完全完了** (動的プラグインシステム実現)
- 🔄 **Phase 8.6 VM性能改善を最優先** (進行中 - GitHub Issue #112)
- 📦 **Phase 9.8 BIDレジストリ** (Phase 8.6完了後の次期重点)
- 🔍 **Phase 10 LLVM** (実現可能性調査・検証段階として位置づけ)
- 🌟 **ネームスペース統合戦略変更** (LLVM完成後に4バックエンド統合設計)
- 📅 **優先順位明確化**: VM性能 → BIDレジストリ → LLVM調査 の順序
================================================================================

219
docs/development/roadmap/phases/00_MASTER_ROADMAP.md Normal file
View File

@ -0,0 +1,219 @@
# 🚀 Nyash開発マスタープラン
Status: Active Development
Last Updated: 2025-08-26
Purpose: Claude×Copilot×ChatGPT協調開発の総合ロードマップ
## 📍 現在位置
- **現在フェーズ**: Phase 8.6 VM性能改善（進行中）
- **次フェーズ**: Phase 9 JIT実装
- **詳細タスク**: [CURRENT_TASK.md](../../current/CURRENT_TASK.md)
## 🗺️ フェーズ概要
| Phase | 状態 | 概要 | 詳細リンク |
|-------|------|------|------------|
| 8.4 | ✅完了 | AST→MIR Lowering完全実装 | [phase_8_4_ast_mir_lowering.md](phase-8/phase_8_4_ast_mir_lowering.md) |
| 8.5 | ✅完了 | MIRダイエット（35→26命令） | [phase_8_5_mir_35_to_26_reduction.md](phase-8/phase_8_5_mir_35_to_26_reduction.md) |
| 8.6 | 🔄進行中 | VM性能改善（0.9倍→2倍以上） | [phase_8_6_vm_performance_improvement.md](phase-8/phase_8_6_vm_performance_improvement.md) |
| 9 | 📅予定 | JIT実装 | [phase-9/](phase-9/) |
| 9.75g-0 | ✅完了 | BID-FFI Plugin System | [Phase-9.75g-0-BID-FFI-Developer-Guide.md](phase-9/Phase-9.75g-0-BID-FFI-Developer-Guide.md) |
| 9.8 | 📅予定 | BIDレジストリ + 自動コード生成 | [phase_9_8_bid_registry_and_codegen.md](phase-9/phase_9_8_bid_registry_and_codegen.md) |
| 10 | 📅予定 | Cranelift JIT（主経路） | [phase_10_cranelift_jit_backend.md](phase-10/phase_10_cranelift_jit_backend.md) |
| 11+ | 🔮将来 | LLVM AOT（研究段階） | 後段検討 |
---
## 🎯 Nyash実行モード併用戦略
### 🌟 インタープリター＋コンパイラ併用の価値
#### 実行モード使い分け
```
開発時: インタープリター（デバッグ・即時実行・非同期フル対応）
本番時: インタープリター（Pythonのように実用的）
OR
WASM/AOT（性能要求時）
配布時: AOT native（最高性能）
Web時: WASM（ブラウザ対応）
```
#### インタープリターの強み
- **即時実行**: コンパイル不要で高速開発
- **デバッグ容易**: 実行時情報の完全把握
- **非同期完全対応**: Rust async/awaitで真の並行処理
- **動的性**: 実行時評価・REPL対応
- **十分な性能**: 多くのユースケースで実用的（Pythonが証明）
---
## 📊 Phase別詳細
### 🚨 Phase 8.6: VM性能改善 - 最優先課題（進行中）
**Summary**:
- **緊急問題**: VMがインタープリターより0.9倍遅い（性能回帰！）
- **目標**: 2倍以上高速化でVM実行を実用レベルに引き上げ
- **担当**: Copilot主導（GitHub Issue #112）
**技術的課題**:
```bash
# 現状のベンチマーク結果
Interpreter: 110.10ms (ベースライン)
VM: 119.80ms (0.9倍 - 遅い...)
Target: 55.00ms (2倍高速化目標)
```
**推定原因と対策**:
- **デバッグ出力過多**: `println!`による性能劣化
- **HashMap操作重い**: ValueId → VM値の変換コスト
- **命令ディスパッチ非効率**: switch文ベースディスパッチ
---
### 🎊 Phase 9.75g-0: BID-FFI Plugin System - 完全完了！ ✅
**革命的成果**: NyashがプラグインでBox型を動的拡張可能に！
```nyash
// これが現実になった！
local file = new FileBox() // プラグイン提供
local db = new PostgreSQLBox() // 将来: プラグイン提供
local gpu = new CudaBox() // 将来: プラグイン提供
```
**References**:
- [Phase-9.75g-0-BID-FFI-Developer-Guide.md](phase-9/Phase-9.75g-0-BID-FFI-Developer-Guide.md)
- tools/plugin-tester/ (プラグイン診断ツール)
---
### 📦 Phase 9.8: BIDレジストリ + 自動コード生成ツール
**Summary**:
- Phase 9.75g-0完了により準備完了
- BID→各ターゲットのスタブ生成自動化
**革命的価値**:
```bash
# 🎯 1つのプラグインが4バックエンド全対応！
nyash bid gen --target wasm bid.yaml # WASM用import生成
nyash bid gen --target vm bid.yaml # VM用関数テーブル生成
nyash bid gen --target llvm bid.yaml # AOT用declare生成（LLVM実装時）
```
---
### 🏆 Phase 10: Cranelift JIT（主経路）
**Summary**:
- MIR→VMを維持しつつ、ホットパスをCraneliftでJIT化
- 目標: VM比2倍以上の高速化
- LLVM AOTは設計資産は維持しつつ、Phase 11以降に検討
**Start Gate（着手前の必須完了）**:
- ✅ MIRダイエット（26命令）整合完了
- ✅ VM統計: `--vm-stats` でホット関数抽出可能
- 🔄 Proof of Concept: MIR→CLIFの最小Lower
- ❓ BoxCall/Array/MapのJIT最適化
**実装ステップ**:
1. **Phase 10.1**: Proof of Concept（2週間）
2. **Phase 10.2**: 基本実装（4週間）
3. **Phase 10.3**: 非同期の扱い（最小）
---
## 🧠 AI大会議から得られた技術的知見
### Gemini先生の助言
- ✅ エスケープ解析・ボックス化解除が性能の鍵
- ✅ wasmtime compileは短期的に実用的
- ✅ WASM実行は確実に高速（13.5倍実証済み）
- 🔄 Cranelift → LLVM段階的アプローチ
### codex先生の助言
- ✅ MIR前倒し実装推奨（全バックエンドが恩恵）
- ✅ wasmtime互換性管理が重要
- ✅ CPU差異対応 (baseline/v3二段ビルド)
- ✅ 起動時間・割当削減・配布体験がKPI
### Claude統合分析
- ✅ 実用価値最大化: WASM+AOTで十分な競争力
- ✅ 開発効率: Cranelift JITの恩恵限定的
- ✅ Everything is Box最適化が差別化の核心
- ✅ 時間効率: 2-3ヶ月節約でLLVM集中投資
---
## 💡 協調開発への具体的お願い
### 🔧 Phase 8.6 VM性能改善（最優先）
- ❓ 命令ディスパッチのボトルネック特定方法は？
- ❓ HashMap操作の最適化戦略は？
- ❓ デバッグ出力削除による性能改善測定は？
- ❓ Direct threading実装の現実的アプローチは？
### 🚀 長期戦略相談
- ❓ インタープリターとコンパイラの互換性保証は？
- ❓ MIR→LLVM IR変換の基本的な実装戦略は？
- ❓ Box型のLLVM表現として最適なアプローチは？
- ❓ エスケープ解析によるスタック化判定は？
---
## 📊 進捗管理・コミュニケーション
### 🤝 協調開発ルール
- ✅ 大きな変更前にはdocs/CURRENT_TASK.mdで情報共有
- ✅ ベンチマーク機能は最優先で維持
- ✅ 競合発生時は機能優先度で解決
### 品質保証
- ✅ cargo check でビルドエラーなし
- ✅ 既存ベンチマークが regression なし
- ✅ 新機能のドキュメント整備
- ✅ テストケース追加・CI通過
---
## 🎯 期待される成果
### 達成済み
- 🏆 RefNew/RefGet/RefSet WASM完全動作
- 🏆 26命令MIR階層化完了（Phase 8.5）
- 🏆 Phase 9.75g-0 BID-FFI Plugin System完全完了
- 🏆 警告削減100%達成（Phase 9.75j）
### 進行中・予定
- 🔄 VM性能改善進行中（Phase 8.6）- GitHub Issue #112
- 📅 Cranelift JIT（Phase 10）: VM比2×以上の高速化
- 📅 非同期ネイティブ実装: async/await完全対応
- 📅 インタープリター併用: 開発・本番両対応
---
## 📞 連絡・相談方法
技術的相談や進捗報告は、以下の方法でお気軽にどうぞ：
1. 📝 GitHub Issues・Pull Request
2. 📋 docs/CURRENT_TASK.md コメント
3. 🤖 AI大会議 (重要な技術決定)
4. 💬 コミットメッセージでの進捗共有
どんな小さなことでも相談大歓迎です！
一緒にNyashを最高の言語にしていきましょう🚀
---
**最終更新**: 2025-08-26 (copilot_issues.txt統合・Markdown化)
**作成者**: Claude (ファイル統合・構造整理)
### 🎯 重要な変更点
- ✅ **Phase 9.75g-0 BID-FFI Plugin System完全完了**
- 🔄 **Phase 8.6 VM性能改善を最優先** (進行中)
- 📦 **Phase 9.8 BIDレジストリ** (Phase 8.6完了後の次期重点)
- 🔍 **Phase 10 Cranelift JIT** (主経路として確定)
- 🌟 **統一ロードマップ化** (phasesフォルダに集約)

23
docs/development/roadmap/phases/phase-9/phase_9_79a_unified_box_dispatch_and_p2p_polish.md
View File

@ -1,6 +1,6 @@
# Phase 9.79a: Unified Box Dispatch (Minimal) + P2PBox Polish
Status: Planned
Status: Completed
Last Updated: 2025-08-26
Owner: core-runtime
@ -37,6 +37,7 @@ Owner: core-runtime
- VM: universal methods 前置ディスパッチ
- Interpreter: 同様の前置ディスパッチ
- スモーク：既存演算子/print動作の回帰なし
- 進捗: 2025-08-26 達成（VM/Interpreterともに toString/type/equals/clone を前段で統一。cargo build 成功）
- M2（Day 3–4）
- P2PBox unregister安全化（endpoint一致 or refcount）
- E2E: onOnce/off 追加、two-node ping-pong 安定、asyncデモが確実に出力
@ -44,6 +45,26 @@ Owner: core-runtime
- VM表示整合：P2PヘルパのtoString/ConsoleをInterpreterと一致
- Docs更新：言語ガイド/P2Pリファレンス反映
## Completion Notes (2025-08-26)
- Universal dispatch (toString/type/equals/clone): Interpreter/VMに前段実装・整合確認済み。
- P2PBox Polish:
- InProcess unregister: endpoint一致時のみunregisterで安全化。
- E2E: onOnce/off ユニットテスト追加、two-node ping→pong スモーク、self→selfスモーク追加。
- 受信トレース: getLastFrom/getLastIntentName を受信時に更新。
- 実用ミニ糖衣: IntentBoxの第2引数に MapBox/JSONBox を直接渡せるよう拡張。
- Docs: 新規リファレンス追加（P2P）/ 例追加
- docs/reference/boxes-system/p2p_box.md
- examples/p2p_self_ping.nyash
- examples/p2p_ping_pong.nyash
Notes:
- 非WASM環境のTimerBoxはダミーのため、async出力の確実化はWASM側のガイドで扱う。ネイティブでは同期スモーク（self→self/二者）で安定確認。
## Next (roll-forward)
- Language sugar: Object literal → MapBox lowering（feature flag `object_literal`で段階導入）
- Proposal: docs/ideas/improvements/2025-08-26-object-literal-sugar.md
- WASMガイドにTimer併用のasyncサンプル追記。
## リスクと対策
- VM分岐に触るリスク → 型別分岐の“前段”に追加、既存分岐はフォールバックとして維持
- unregister回りの退行 → 一致解除テスト/順次Dropテスト（clone/share/Drop順の組み合わせ）を追加

49
docs/development/roadmap/phases/phase-9/phase_9_79b_1_unified_registry_ids_and_builder_slotting.md Normal file
View File

@ -0,0 +1,49 @@
# Phase 9.79b.1: Unified Registry IDs + Builder Slotting
Status: Planned
Owner: core-runtime
Target: Before Phase 10 (Cranelift JIT)
Last Updated: 2025-08-26
## Goals
- Introduce `BoxTypeId`/`MethodId` and stable method slot reservation in the unified registry.
- Resolve method names to slot IDs at MIR builder time when possible.
- Keep MIR instruction set stable (26) while enabling ID-based BoxCall.
## Scope
- Registry
- Add numeric `BoxTypeId` mapping (type-name → id) and `(type_id, method)` → `slot` table.
- Reserve low slots for universal methods: `0=toString`, `1=type`, `2=equals`, `3=clone`.
- Provide `reserve_method_slot()`, `resolve_slot()` APIs.
- MIR Builder
- When receiver type can be inferred, emit `BoxCall { method_id }` (slot ID) instead of name.
- Add late-bind fallback path for unresolved sites (keeps current behavior).
- Debug scaffolding
- Add `MIRDebugInfo` container types (empty by default) for ID→name mapping (off by default).
- Docs
- Update MIR design note to mention ID-based BoxCall with late-bind fallback.
## Deliverables
- New IDs and slot APIs in registry
- Builder emits `method_id` when resolvable
- Unit tests for slot reservation and universal slot invariants
## Non-Goals
- VM vtable/thunk dispatch (handled in 9.79b.2)
- PIC/JIT codegen
## Risks & Mitigations
- Slot consistency with inheritance: document rule “override keeps parent slot”; add test.
- Partial resolvability: ensure late-bind remains correct and does not regress semantics.
## Timeline
- 1–2 days
## Acceptance Criteria
- Tests pass; builder prints BoxCall with numeric `method_id` for resolvable sites.
- Universal methods occupy reserved slots across all types.
- No change to MIR opcode count (26) and existing dumps remain valid except for `method_id` where applicable.
## Roll-forward
- Proceed to 9.79b.2 (VM vtable/thunk + mono-PIC).

51
docs/development/roadmap/phases/phase-9/phase_9_79b_2_vm_vtable_thunks_and_pic.md Normal file
View File

@ -0,0 +1,51 @@
# Phase 9.79b.2: VM VTable Thunks + Mono-PIC
Status: Planned
Owner: core-runtime
Target: Before Phase 10 (Cranelift JIT)
Last Updated: 2025-08-26
## Goals
- Implement unified VM BoxCall path via vtable thunks indexed by `MethodId`.
- Add monomorphic inline cache (PIC) at call sites; prepare for polymorphic expansion.
- Keep behavior identical; improve structure and enable JIT lowering.
## Scope
- VM Dispatch
- Add `TypeMeta` with `vtable_base`, `version`.
- `execute_boxcall(receiver, method_id, args)`: lookup thunk = `vtable[slot]` and call target.
- PIC (Monomorphic)
- Per call-site cache: `(type_id, version) → target` fast path with fallback.
- Counters for hit/miss (debug only) to validate performance wins.
- Plugin safety (stub)
- Provide thunk replacement and type `version++` API (actual unload handled later with plugin mgr).
- Tests
- BoxCall correctness across builtin/user/plugin (plugin mocked if needed).
- PIC hit on repeated calls; miss on version change.
- Docs
- Update VM README with unified path and PIC diagram.
## Deliverables
- Unified VM BoxCall path (vtable + thunk)
- Monomorphic PIC
- Test coverage for core scenarios
## Non-Goals
- Polymorphic PIC (plan only)
- JIT emission (Phase 10)
## Risks & Mitigations
- Thunk ABI uniformity: define single target signature usable by builtin/VM/plugin shims.
- Cache invalidation: bump `version` on thunk replacement; verify miss logic.
## Timeline
- 2–3 days
## Acceptance Criteria
- All existing tests pass; new VM dispatch tests pass.
- Measurable hit rate on hot call-sites in debug stats.
- No observable behavior change from user code perspective.
## Roll-forward
- Phase 10: Cranelift JIT lowers BoxCall to the same thunks; add poly-PIC and codegen stubs.

80
docs/ideas/improvements/2025-08-26-object-literal-sugar.md Normal file
View File

@ -0,0 +1,80 @@
# Object Literal Sugar for Nyash (Draft)
Status: Proposal (target: Phase 9.79b or 9.80)
Author: core-runtime
Last Updated: 2025-08-26
## Goals
- Provide ergonomic inline construction of structured data for messaging and config.
- Keep parser stable and avoid ambiguity with blocks and control structures.
- Lower to existing Box types (MapBox/JSONBox) without breaking NyashBox trait.
## Syntax Candidates
- A) JSON-like literals
- Example: `{ a: 1, b: "x", ok: true }`
- Variant: Allow string keys without quotes; values are Nyash expressions.
- B) Explicit constructors with sugar keyword
- Example: `map { a: 1, b: "x" }` → lowers to `new MapBox()` + sets
- C) JSON string auto-parse contextually
- Example: `"{\"a\":1}"` auto-parsed where JSON is expected (too implicit → avoid as default)
Recommendation: Start with A) JSON-like object literal lowering to MapBox.
## Grammar Design (A)
- Token additions: `{`, `}`, `:`, `,` are already present.
- Production:
- PrimaryExpr := ObjectLiteral | existing-primary
- ObjectLiteral := `{` ObjMembers? `}`
- ObjMembers := ObjPair (`,` ObjPair)* (`,`)?
- ObjPair := Identifier `:` Expr
- Key constraints: Identifier (no quotes) initially; string-literal keys as follow-up.
- Values: Any expression; evaluation order left-to-right.
## Lowering Strategy
- `{ k1: v1, k2: v2 }` →
- `tmp = new MapBox(); tmp.set("k1", (v1)); tmp.set("k2", (v2)); tmp`
- In AST builder: desugar ObjectLiteral into a sequence and final tmp reference.
- Side-effects: preserve evaluation order; each `vi` evaluated once.
## Ambiguity & Conflict Checks
- With blocks: Nyash does not use `{}` for statement blocks (loop uses `loop(cond) { }` but parser differentiates by context). Ensure lookahead disambiguates after `=` or in expression position.
- With `from`: no conflict.
- With `while/if` (obsolete): not applicable.
## Types & Interop
- MapBox chosen for mutability and existing rich API.
- Allow JSONBox interop later via `json{ ... }` form or helper.
- IntentBox constructor already accepts MapBox/JSONBox (implemented 2025-08-26).
## Examples
- `msg = new IntentBox("chat", { text: "hi", user: me.name })`
- `cfg = { retries: 3, verbose: true }`
- `headers = { Accept: "application/json", Host: host }`
## Validation & Tests
- Parser tests: empty `{}`, single/multi pairs, trailing comma, nested values, errors.
- Runtime tests: MapBox size/keys/values; evaluation order with side effects.
- Negative tests: `{ :1 }`, `{a 1}`, `{a:}`, `{a: 1, , b:2}`.
## Phased Rollout
- Phase 1 (behind feature flag `object_literal`): parser + lowering to MapBox; docs + examples.
- Phase 2: string-literal keys; nested object/array literals sugar (`[ ... ]`?) once array-literal is designed.
- Phase 3: JSONBox literal form `json{ ... }` (optional).
## Migration & Back-compat
- No breaking changes; literals are additive syntax.
- Existing code using JSON strings/MapBox continues to work.
## Open Questions
- Should we permit numeric/bool literals as keys? → No (keys stringify already).
- Trailing comma allowed? → Yes (developer-friendly).
- Pretty-printer/formatter impact? → Add simple rule to keep one-line small maps.
## Out of Scope (for this proposal)
- Array literal `[ ... ]` (future parallel RFC)
- Spread syntax, computed keys, deep merge helpers
## Appendix
- Related work: JS object literals, Rust maplit!, Lua tables, TOML inline tables.
- Risks: Parser precedence bugs → mitigate with unit tests + feature flag.

904
docs/ideas/other/2025-08-25-unified-box-design-deep-analysis.md
View File

@ -1,539 +1,427 @@
# Nyash統一Box設計の深い分析と今後の方向性
Status: Research
# Nyash統一Box設計の深い分析と実装戦略
Status: Active Design
Created: 2025-08-25
Priority: High
Updated: 2025-08-26 (Codex深掘り版)
Priority: Critical
Related: Everything is Box哲学の実装レベルでの完全実現
## 現状の統一Box設計
## 📌 最新の合意事項（2025-08-26）
### 3種類のBoxの存在
1. **ビルトインBox** - Rustで実装（StringBox, IntegerBox, ConsoleBox等）
2. **プラグインBox** - 動的ライブラリで提供（FileBox等の置き換え可能）
3. **ユーザー定義Box** - Nyashコードで定義（box Person等）
### 2つのAI専門家からの統一見解
- **Codex (GPT-5)**: ハイブリッドアプローチ推奨、Method ID = Stable Slot Index
- **Claude**: MIRレベル完全統一の重要性を強調
- **共通結論**: コアBox静的リンク＋MIR統一＋Thunk indirection = 最適解
### 現在の統一アーキテクチャ
```
UnifiedBoxRegistry（統一レジストリ）
├── BuiltinBoxFactory（優先度1）
├── UserDefinedBoxFactory（優先度2）
└── PluginBoxFactory（優先度3）
```
### 核心的設計決定
1. **ハイブリッドアプローチ** - コアは静的、拡張はプラグイン
2. **MIRレベル完全統一** - 3種類のBoxを数値IDで区別なく扱う
3. **Stable Slot Index** - メソッドIDは型ごとのvtableスロット番号
4. **Thunk-based Safety** - プラグインアンロード時の安全性保証
### 統一の美しさ
## 🎯 統一Box設計の全体像
1. **透過的な置き換え**
- 同じ名前のBoxをプラグインで上書き可能
- 実行時の動的切り替えも可能
2. **統一インターフェース**
```rust
pub trait BoxFactory: Send + Sync {
fn create_box(&self, name: &str, args: &[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError>;
fn box_types(&self) -> Vec<&str>;
fn supports_birth(&self) -> bool;
}
```
3. **優先順位システム**
- ビルトイン > ユーザー定義 > プラグイン
- 予約語保護（StringBox等は上書き不可）
## InstanceBoxによる完全統一
### 統一実装の核心
```rust
pub struct InstanceBox {
pub class_name: String, // "StringBox", "Person"等
pub inner_content: Option<Box<dyn NyashBox>>, // 内包Box（統一！）
pub fields_ng: Arc<Mutex<HashMap<String, NyashValue>>>,
pub methods: Arc<HashMap<String, ASTNode>>,
}
```
### 3つの形態を統一的に扱う
```rust
// ビルトイン
InstanceBox::from_any_box("StringBox", Box::new(StringBox::new("hello")))
// プラグイン
InstanceBox::from_any_box("FileBox", plugin_loader.create_box("FileBox"))
// ユーザー定義
InstanceBox::from_declaration("Person", vec!["name", "age"], methods)
```
## 基本メソッドの統一提案
### 問題点
- `toString()` → `to_string_box()` （Rustの命名規則で異なる）
- `type()` → `type_name()` （微妙に異なる）
- 各Boxで個別実装されていて統一感がない
### 解決案：NyashBoxトレイトにデフォルト実装
```rust
pub trait NyashBox: BoxCore + Debug {
// Nyash標準メソッド（デフォルト実装）
fn toString(&self) -> Box<dyn NyashBox> {
Box::new(StringBox::new(&self.to_string_box().value))
}
fn type(&self) -> Box<dyn NyashBox> {
Box::new(StringBox::new(self.type_name()))
}
fn equals(&self, other: Box<dyn NyashBox>) -> Box<dyn NyashBox> {
Box::new(BoolBox::new(self.equals_internal(other.as_ref())))
}
fn clone(&self) -> Box<dyn NyashBox> {
self.clone_box()
}
}
```
### VMでの統一的な呼び出し
```rust
pub(super) fn call_box_method(&self, box_value: Box<dyn NyashBox>, method: &str, args: Vec<Box<dyn NyashBox>>) -> Result<Box<dyn NyashBox>, VMError> {
// 基本メソッドは全Boxで使える！
match method {
"toString" => Ok(box_value.toString()),
"type" => Ok(box_value.type()),
"equals" => Ok(box_value.equals(args[0].clone_or_share())),
"clone" => Ok(box_value.clone()),
_ => self.call_specific_method(box_value, method, args)
}
}
```
## Gemini先生からの提案（部分）
### 1. NyashValue Enumの導入
```rust
pub enum NyashValue {
// 即値（スタック上）
Void,
Bool(bool),
Integer(i64),
Float(f64),
// ヒープ上の不変値
String(Arc<String>),
// 複雑なオブジェクト
Object(Arc<NyashObject>),
}
```
**メリット**:
- 小さな値のヒープアロケーション回避
- パターンマッチによる高速ディスパッチ
- 型安全性の向上
### 2. トレイトの階層化
```rust
// 基本トレイト
pub trait NyashBox: Send + Sync + Debug {
fn to_string(&self) -> String;
fn type_name(&self) -> &'static str;
fn equals(&self, other: &dyn NyashBox) -> bool;
}
// 拡張トレイト
pub trait Comparable: NyashBox {
fn compare(&self, other: &dyn NyashBox) -> Option<Ordering>;
}
pub trait Arithmetic: NyashBox {
fn add(&self, other: &dyn NyashBox) -> Result<Box<dyn NyashBox>, String>;
}
```
### 3. メタプログラミング機能
```rust
pub trait BoxMetadata {
fn on_method_missing(&self, name: &str, args: &[NyashValue]) -> Option<NyashValue>;
fn on_field_access(&self, name: &str) -> Option<NyashValue>;
}
```
## 統一継承の実現
### ~~現在の課題~~ → 2025-08-25更新：すべて実装済み！
- ~~ビルトインBoxの継承ができない~~ → ✅ 実装済み！
- ~~プラグインBoxの継承も未実装~~ → ✅ 実装済み！
### 理想的な統一継承（すでに実現！）
```nyash
// すべて可能になった！
box MyString from StringBox { } // ビルトイン継承 ✅
box MyFile from FileBox { } // プラグイン継承 ✅
box Employee from Person { } // ユーザー定義継承 ✅
// 多重デリゲーションも可能！
box MultiChild from StringBox, IntegerBox { } // ✅
```
### 実際のコード例（動作確認済み）
```nyash
box EnhancedString from StringBox {
init { prefix, suffix }
birth(text) {
from StringBox.birth(text) // 透過的にpackに変換される
me.prefix = "【"
me.suffix = "】"
}
enhanced() {
return me.prefix + me.toString() + me.suffix + "✨"
}
}
```
## さらなる美化への道
### 1. パイプライン演算子
```nyash
// 現在
local result = str.substring(0, 5).toUpperCase().trim()
// パイプライン版
local result = str
|> substring(0, 5)
|> toUpperCase()
|> trim()
```
### 2. Box階層の整理
```
NyashBox (trait)
├── ValueBox (数値・文字列・真偽値)
│ ├── IntegerBox
│ ├── StringBox
│ └── BoolBox
├── ContainerBox (コレクション)
│ ├── ArrayBox
│ └── MapBox
├── IOBox (入出力)
│ ├── ConsoleBox
│ └── FileBox
└── ConcurrentBox (並行処理)
├── FutureBox
└── ChannelBox
```
### 3. エフェクトシステムの美化
```rust
impl ArrayBox {
#[effect(Pure)]
fn length(&self) -> IntegerBox { }
#[effect(State)]
fn push(&mut self, item: Box<dyn NyashBox>) { }
}
```
## 実装優先順位（80/20ルール）
### 今すぐやるべき（80%）
1. 基本メソッド（toString, type, equals, clone）の統一実装
2. VMでの統一的なメソッドディスパッチ
3. InstanceBoxのinner_content活用の徹底
### 後でじっくり（20%）
1. NyashValue enum導入によるパフォーマンス最適化
2. トレイト階層化による整理
3. パイプライン演算子の実装
4. メタプログラミング機能
5. 完全な統一継承システム
## まとめ
現在のNyashの統一Box設計は、すでに相当美しく実装されている。特に：
1. **UnifiedBoxRegistry**による透過的な管理
2. **優先順位システム**による明確な解決
3. **InstanceBox**による統一的な扱い
これらは「Everything is Box」哲学を実装レベルで体現している。
ユーザー定義Boxをビルトイン/プラグインBoxと完全に同じレベルで扱うことは、強引ではなく、むしろ設計として自然で美しい。この統一により、言語の一貫性と拡張性が大幅に向上する。
今後は、基本メソッドの統一実装から始めて、段階的により洗練された設計へと進化させていくのが良いだろう。
## 🚀 MIR/VM統一実装計画（2025-08-25追記）
### 📍 現状の課題
VMとMIRで、Box型によって異なる処理をしている：
### 1. Box分類の最終決定
```rust
// VMでの現状：InstanceBoxだけ特別扱い
if let Some(inst) = arc_box.as_any().downcast_ref::<InstanceBox>() {
// ユーザー定義Box → 関数呼び出しに変換
let func_name = format!("{}.{}/{}", inst.class_name, method, args.len());
} else {
// ビルトイン/プラグイン → 直接メソッド呼び出し
self.call_box_method(cloned_box, method, nyash_args)?
}
```
### 🎯 統一実装の提案
#### 1. 統一メソッドディスパッチインターフェース
```rust
pub trait UnifiedBox: NyashBox {
fn dispatch_method(&self, method: &str, args: Vec<Box<dyn NyashBox>>)
-> Result<Box<dyn NyashBox>, String> {
// デフォルト実装：既存のメソッド呼び出しを使用
self.call_method(method, args)
}
}
// InstanceBoxでのオーバーライド
impl UnifiedBox for InstanceBox {
fn dispatch_method(&self, method: &str, args: Vec<Box<dyn NyashBox>>)
-> Result<Box<dyn NyashBox>, String> {
// MIR関数へのリダイレクト
let func_name = format!("{}.{}/{}", self.class_name, method, args.len());
// VM経由で関数呼び出し
}
}
```
#### 2. VMの簡素化
```rust
// 統一後：すべて同じ処理パス
let result = match &recv {
VMValue::BoxRef(arc_box) => {
arc_box.dispatch_method(method, nyash_args)?
}
_ => {
recv.to_nyash_box().dispatch_method(method, nyash_args)?
}
};
```
#### 3. MIRレベルでの統一
- `BoxCall`命令ですべてのBox型を統一的に処理
- 型による分岐や特殊処理を削除
- コンパイル時の最適化は維持
### 💎 期待される効果
1. **コードの簡素化**
- VM内の条件分岐削除で30%以上のコード削減
- 新Box型追加時の変更箇所が最小限に
2. **保守性の向上**
- Box型の実装詳細がVMから隠蔽される
- テストが書きやすくなる
3. **パフォーマンス**
- 統一的な最適化（メソッドキャッシュ等）が可能
- 仮想関数テーブルによる高速化の可能性
4. **美しさ**
- 「Everything is Box」が実装レベルでも完全に実現
- シンプルで理解しやすいコード
### 📅 実装ロードマップ
1. **Phase 1**: UnifiedBoxトレイトの導入（後方互換性を保ちながら）
2. **Phase 2**: VMでの統一ディスパッチ実装
3. **Phase 3**: MIRビルダーの簡素化
4. **Phase 4**: 旧実装の削除とクリーンアップ
### 🌟 最終的なビジョン
すべてのBox（ビルトイン、プラグイン、ユーザー定義）が完全に統一された世界：
- 同じインターフェース
- 同じ実行パス
- 同じ最適化機会
これこそが「Everything is Box」の究極の実現！
## 🔌 プラグインローダーv2との統合
### 現在のプラグインシステムとの関係
- プラグインローダーv2がすでに統一的なインターフェースを提供
- `extern_call`経由での統一的なアクセス
- UnifiedBoxトレイトとの相性は良好
### 統合のメリット
- プラグインBoxも`dispatch_method()`で統一処理
- ホットリロード時も透過的に動作
- FFI境界を意識しない実装
## 📊 パフォーマンス測定計画
### 現在のベースライン
- インタープリター基準で13.5倍高速化達成（VM実装）
- BoxCall命令の実行時間が全体の約30%
### 統一実装後の予測
- 条件分岐削減で5-10%の高速化期待
- メソッドキャッシュで追加20%改善の可能性
- 測定方法：`--benchmark --iterations 1000`で検証
## 🔄 移行時の互換性戦略
### 段階的移行計画
1. **Phase 1**: UnifiedBoxトレイトを追加（既存APIは維持）
2. **Phase 2**: 警告付きで旧API使用を通知
3. **Phase 3**: 内部実装を統一版に切り替え
4. **Phase 4**: 旧APIをdeprecated化
5. **Phase 5**: 完全削除（6ヶ月後）
### テスト戦略
- 既存の全E2Eテストが通ることを保証
- パフォーマンスリグレッションテスト追加
- プラグイン互換性テストスイート
## ⚡ JITコンパイラとの統合（Phase 9準備）
### 統一メソッドディスパッチの利点
- JITが最適化しやすい単純な呼び出しパターン
- インライン展開の機会増加
- 型情報を活用した特殊化
### 仮想関数テーブル（vtable）戦略
```rust
struct BoxVTable {
methods: HashMap<String, fn(&dyn NyashBox, Vec<Box<dyn NyashBox>>) -> Result<Box<dyn NyashBox>, String>>,
}
```
- 起動時に事前計算
- JITコンパイル時に直接参照
- キャッシュフレンドリーな配置
## 🔧 具体的な実装タスク（TODO）
### Phase 1: 基礎実装（1週間）
- [ ] UnifiedBoxトレイトの定義（src/box_trait.rs）
- [ ] StringBox, IntegerBox等への実装
- [ ] InstanceBoxへのdispatch_method実装
- [ ] 単体テストの作成
### Phase 2: VM統合（2週間）
- [ ] execute_boxcall()の簡素化
- [ ] InstanceBox特別扱いコードの削除
- [ ] VMValueとの統合
- [ ] E2Eテスト全パス確認
- [ ] ベンチマーク実行と比較
### Phase 3: 最適化（1週間）
- [ ] メソッドキャッシュ実装
- [ ] 頻出メソッドの特殊化
- [ ] vtable事前計算
- [ ] JIT統合準備
### Phase 4: クリーンアップ（3日）
- [ ] 旧実装コードの削除
- [ ] ドキュメント更新
- [ ] CHANGELOG記載
- [ ] マイグレーションガイド作成
### 検証項目
- [ ] 全Box型でtoString/type/equals/cloneが動作
- [ ] プラグインBoxの透過的な動作
- [ ] パフォーマンス改善の確認
- [ ] メモリ使用量の変化なし
## 🚀 究極の統一：ビルトインBox完全プラグイン化構想
### 現状の二重実装問題
- **plugin_loader.rs** (1217行) - ビルトインBoxの動的ライブラリ化
- **plugin_loader_v2.rs** (906行) - プラグインBoxシステム
- 合計2000行以上の重複！
### 完全プラグイン化の提案
#### すべてをプラグインに統一
```rust
// 現在
ビルトインFileBox → 静的リンク
プラグインFileBox → 動的ロード（.so）
// 統一後
すべてのBox → プラグイン（.so）として実装
```
#### コアBoxの自動ロード戦略
```rust
// 絶対的コアBox（静的リンク必須）- 10個
const CORE_BOXES: &[&str] = &[
"libnyash_string_box.so", // StringBox（必須）
"libnyash_integer_box.so", // IntegerBox（必須）
"libnyash_bool_box.so", // BoolBox（必須）
"libnyash_console_box.so", // ConsoleBox（print用）
"NilBox", "BoolBox", "IntegerBox", "FloatBox",
"StringBox", "ArrayBox", "MapBox",
"ConsoleBox", "ResultBox", "MethodBox"
];
// 起動時に自動ロード
fn init_core_boxes() {
for plugin in CORE_BOXES {
plugin_loader.load_required(plugin)
.expect("Core box loading failed");
// 準コアBox（静的だが置換可能）- 4個
const SEMI_CORE_BOXES: &[&str] = &[
"MathBox", "DebugBox", "TimeBox", "RandomBox"
];
// プラグイン推奨Box - 残り全て
const PLUGIN_BOXES: &[&str] = &[
"FileBox", "NetworkBox", "AudioBox",
"P2PBox", "EguiBox", "WebDisplayBox", // ...
];
```
### 2. 革新的な統一レジストリ設計（Codex提案）
```rust
pub struct UnifiedBoxRegistry {
// 型名 → 型ID（安定）
type_registry: HashMap<String, BoxTypeId>,
// 型メタデータ（vtableベースアドレス含む）
type_meta: Vec<TypeMeta>,
// (型ID, メソッド名) → スロット番号（永続的）
slot_index: HashMap<(BoxTypeId, String), SlotIdx>,
// Thunkプール（固定アドレス、原子的更新可能）
thunks: Vec<MethodThunk>,
// グローバルエポック（大規模無効化用）
epoch: AtomicU64,
}
// 型ごとのメタデータ
struct TypeMeta {
version: AtomicU32, // 動的更新のバージョン
vtable_base: *const *const MethodThunk, // vtableベースポインタ
slot_count: u32, // 割り当て済みスロット数
}
// メソッドThunk（間接層）
struct MethodThunk {
target: AtomicPtr<c_void>, // 実装への原子的ポインタ
sig: Signature, // メソッドシグネチャ
flags: MethodFlags, // 純粋性、インライン可能性等
}
```
## 🚀 MIRレベルでの完全統一実装
### 1. 統一MIR命令（最終形）
```rust
pub enum MirInstruction {
// Box生成（すべて同じ）
BoxNew {
dst: ValueId,
type_id: BoxTypeId, // 数値ID（ビルトイン=1、ユーザー=1000でも同じ）
args: Vec<ValueId>,
},
// メソッド呼び出し（すべて同じ）
BoxCall {
dst: Option<ValueId>,
receiver: ValueId,
method_id: MethodId, // 安定したスロット番号
args: Vec<ValueId>,
effects: EffectFlags, // 純粋性、副作用情報
},
}
```
### 2. メソッドID解決戦略（Codex推奨）
```rust
impl MirBuilder {
fn compile_method_call(&mut self, receiver: ValueId, method: &str, args: Vec<ValueId>) {
let receiver_type = self.infer_type(receiver);
// 静的に解決可能な場合
if let Some(slot) = self.registry.resolve_slot(receiver_type, method) {
self.emit(MirInstruction::BoxCall {
dst: Some(self.new_value()),
receiver,
method_id: slot,
args,
effects: self.registry.get_method_flags(receiver_type, slot),
});
} else {
// 動的解決が必要（eval、動的ロード）
self.emit_late_bind_call(receiver, method, args);
}
}
}
```
### メリット
1. **コード削減**: plugin_loader.rs (1217行) を完全削除
2. **統一性**: Everything is Boxの究極の実現
3. **柔軟性**: StringBoxすら置き換え可能
4. **ビルド高速化**: 本体が軽量に
5. **配布の柔軟性**: 必要なBoxだけ選択可能
### 3. VM実装の劇的簡素化
### 考慮事項
#### パフォーマンス
- FFI境界のオーバーヘッドは**ナノ秒レベル**
- 実用上の影響なし
#### デバッグの課題と対策
```rust
// 課題：エラー時のスタックトレース
thread 'main' panicked at 'FFI boundary: 0x7f8b2c001234'
// 対策1：プラグイン側でのロギング
#[no_mangle]
pub extern "C" fn box_method_toString() {
eprintln!("[StringBox::toString] called from {:?}", std::thread::current().id());
// 現在：Box種類で複雑な分岐
match determine_box_kind(&receiver) {
BoxKind::Instance => {
// ユーザー定義Boxの特殊処理
let func_name = format!("{}.{}", class_name, method);
self.call_mir_function(func_name, args)?
},
BoxKind::Plugin => {
// プラグインのFFI呼び出し
unsafe { plugin_invoke(receiver, method, args) }
},
BoxKind::Builtin => {
// ビルトインメソッド直接呼び出し
builtin_dispatch(receiver, method, args)
}
}
// 対策2：デバッグシンボル保持
cargo build --features debug-symbols
// 対策3：プラグイン単体テストの充実
#[test]
fn test_string_box_methods() { /* ... */ }
// 統一後：完全に均一なディスパッチ！
fn execute_boxcall(&mut self, receiver: ValueId, method_id: MethodId, args: Vec<ValueId>) {
// 1. 受信者の型を取得
let type_meta = self.get_type_meta(receiver);
// 2. vtableからThunkを取得
let thunk = unsafe { *type_meta.vtable_base.add(method_id as usize) };
// 3. Thunkのターゲットを原子的に読み取り
let target = thunk.target.load(Ordering::Acquire);
// 4. 統一的な呼び出し
let result = (target)(receiver, args);
self.push(result);
}
```
### 実装ロードマップ
1. **Phase A**: コアBoxのプラグイン化
- StringBox, IntegerBox, BoolBox, ConsoleBox
2. **Phase B**: 起動時自動ロード機構
3. **Phase C**: plugin_loader.rs削除
4. **Phase D**: ドキュメント・テスト整備
## ⚡ 高性能化の核心技術
### 設定ファイル案
```toml
# ~/.nyash/config.toml
[plugins]
core_path = "./plugins/core/"
search_paths = ["./plugins", "/usr/lib/nyash/plugins"]
### 1. Polymorphic Inline Cache (PIC) 実装
[core_boxes]
required = ["string", "integer", "bool", "console"]
optional = ["file", "math", "time"]
```rust
// コールサイトごとのインラインキャッシュ
struct InlineCache {
// モノモーフィックエントリ（最頻出）
mono_type: BoxTypeId,
mono_version: u32,
mono_target: *const fn,
// ポリモーフィックエントリ（2-4個）
poly_entries: [(BoxTypeId, u32, *const fn); 4],
poly_count: u8,
}
// JIT生成コード例（疑似コード）
fn generate_pic_stub(cache: &InlineCache) -> Code {
// 1. 受信者の型IDを取得
// 2. モノモーフィックチェック
if receiver.type_id == cache.mono_type &&
receiver.version == cache.mono_version {
jump cache.mono_target // 直接ジャンプ！
}
// 3. ポリモーフィックチェック
for entry in cache.poly_entries[..cache.poly_count] {
if receiver.type_id == entry.0 && receiver.version == entry.1 {
jump entry.2
}
}
// 4. スローパス
call slow_path_resolver
}
```
これにより、「Everything is Box」哲学が実装レベルでも完全に実現される！
### 2. メソッドスロットの永続性保証
## 🔍 統一デバッグインフラストラクチャ（2025-08-26追記）
```rust
impl UnifiedBoxRegistry {
// スロット予約（一度割り当てたら永続）
pub fn reserve_method_slot(
&mut self,
type_id: BoxTypeId,
method: &str,
sig: &Signature
) -> SlotIdx {
let key = (type_id, method.to_string());
// 既存スロットがあれば返す
if let Some(&slot) = self.slot_index.get(&key) {
return slot;
}
// 新規スロット割り当て（削除後も再利用しない）
let type_meta = &mut self.type_meta[type_id as usize];
let slot = SlotIdx(type_meta.slot_count);
type_meta.slot_count += 1;
self.slot_index.insert(key, slot);
slot
}
}
```
### 3. 安全なプラグインアンロード
```rust
impl PluginManager {
fn unload_plugin(&mut self, plugin_id: PluginId) {
// 1. 影響を受ける型とメソッドを列挙
let affected = self.get_plugin_methods(plugin_id);
for (type_id, slot) in affected {
// 2. Thunkを原子的にスタブに差し替え
let thunk = &self.registry.get_thunk(type_id, slot);
let stub = get_unloaded_method_stub();
thunk.target.store(stub, Ordering::Release);
// 3. 型バージョンをインクリメント（キャッシュ無効化）
let type_meta = &self.registry.type_meta[type_id];
type_meta.version.fetch_add(1, Ordering::AcqRel);
}
// 4. RCU/Hazard Pointerで安全に回収
self.defer_plugin_cleanup(plugin_id);
}
}
// アンロード後のスタブ関数
fn unloaded_method_stub(_: ValueId, _: Vec<ValueId>) -> VMValue {
panic!("Method has been unloaded")
}
```
## 📊 パフォーマンス分析と予測
### 現状のベースライン
- インタープリター比: **13.5倍**高速
- BoxCall実行時間: 全体の**30%**
- 主なオーバーヘッド: 文字列比較、型判定、間接呼び出し
### 改善による期待効果
| 最適化技術 | 個別改善率 | 全体への影響 |
|-----------|----------|-----------|
| メソッドID化 | 50-70% | 15-21% |
| PICキャッシュ | 80-90% | 24-27% |
| インライン化 | 特定サイト10倍 | 10-25% |
| 純粋性解析 | CSE/LICM可能 | 5-15% |
### 20倍達成への道筋
```
現在: 13.5倍
目標: 20.0倍（+48%必要）
達成可能性:
- ID化+PIC: 1.15-1.20倍
- インライン化: 1.10-1.25倍
- 効果解析: 1.05-1.15倍
合計: 1.32-1.73倍 → 17.8-23.4倍（達成可能！）
```
## 🛠️ 実装ロードマップ（詳細版）
### Phase 1: 基盤構築（1週間）
```rust
// Week 1のタスク
- [ ] MethodThunk構造体とアロケーター実装
- [ ] TypeMetaとvtable管理実装
- [ ] スロット予約API（reserve_method_slot）
- [ ] 基本的なレジストリ操作
```
### Phase 2: MIR統合（1週間）
```rust
// Week 2のタスク
- [ ] BoxNew/BoxCallの数値ID化
- [ ] メソッド名→スロット解決
- [ ] late-bind placeholderサポート
- [ ] デバッグ情報サイドテーブル
```
### Phase 3: VM最適化（2週間）
```rust
// Week 3-4のタスク
- [ ] 統一execute_boxcall実装
- [ ] モノモーフィックPIC実装
- [ ] ポリモーフィックPIC拡張
- [ ] ベンチマーク検証
```
### Phase 4: プラグイン対応（1週間）
```rust
// Week 5のタスク
- [ ] プラグインAPIのスロット対応
- [ ] 安全なアンロード実装
- [ ] バージョン管理とキャッシュ無効化
- [ ] 実プラグイン移行（FileBox）
```
### Phase 5: JIT準備（継続的）
```rust
// 継続タスク
- [ ] 純粋性フラグの伝搬
- [ ] インライン可能IRの提供
- [ ] Craneliftメタデータ整備
- [ ] PIC codegenサポート
```
## 🔍 技術的詳細と実装のコツ
### デバッグ情報の管理
```rust
// MIRは数値のみ保持
struct MirDebugInfo {
// (type_id, slot) → 人間可読情報
method_names: HashMap<(BoxTypeId, SlotIdx), MethodDebug>,
// PC → ソース位置
source_map: HashMap<usize, SourceLocation>,
}
struct MethodDebug {
type_name: String,
method_name: String,
signature: String,
source_file: PathBuf,
line: u32,
}
```
### スレッドセーフティ
```rust
// Read-Copy-Update パターン
impl UnifiedBoxRegistry {
fn update_method(&self, type_id: BoxTypeId, slot: SlotIdx, new_impl: *const fn) {
// 1. 新バージョンを準備
let new_thunk = MethodThunk {
target: AtomicPtr::new(new_impl),
// ...
};
// 2. RCUで安全に更新
rcu::synchronize(|| {
self.thunks[slot].target.store(new_impl, Ordering::Release);
});
}
}
```
### メモリレイアウト最適化
```rust
// キャッシュフレンドリーな配置
#[repr(C, align(64))] // キャッシュライン境界
struct TypeVTable {
thunks: [MethodThunk; MAX_METHODS_PER_TYPE],
}
// ホットデータをまとめる
struct HotMethodData {
frequently_called: [MethodThunk; 8], // toString, equals等
cold_methods: *const ColdMethodTable,
}
```
## 💡 結論と次のステップ
### 統一設計の価値
1. **簡潔性**: VM/JIT実装が劇的にシンプルに
2. **性能**: 20倍高速化が現実的に達成可能
3. **安全性**: Thunk indirectionで動的更新も安全
4. **拡張性**: 新Box型追加が容易
### ChatGPT5への相談ポイント
1. **Thunk実装の具体的なアセンブリ**
2. **RCU/Hazard Pointerの実装詳細**
3. **PICのCranelift codegenパターン**
4. **型推論とスロット解決の統合**
5. **デバッガ統合のベストプラクティス**
### 実装の第一歩
```rust
// まずはこれを実装！
pub struct MethodThunk {
target: AtomicPtr<extern "C" fn(*const u8, *const *const u8) -> *const u8>,
#[cfg(debug_assertions)]
debug_name: &'static str,
}
// そしてスロット予約
registry.reserve_method_slot(STRING_BOX_ID, "toString", &sig);
```
「Everything is Box」の理想が、ついに実装レベルで完全に実現される時が来ました！
## 🔍 統一デバッグインフラストラクチャ
### 📍 MIRレベルでの統一デバッグ実現
今までの議論で、MIRレベルでのデバッグ実装が最も理想的であることが判明しました。
MIRレベルでのデバッグ実装が最も理想的であることが判明しました。
Gemini先生とCodex先生の両方が同じ結論に達しました：**設計案2＋3のハイブリッド**が最適解です。
#### 核心設計：メタデータ分離＋プロファイリングAPI
@ -737,7 +625,7 @@ impl DeepInspectorBox {
}
```
### 🚀 実装ロードマップ（2025年後半）
### 🚀 統一デバッグ実装ロードマップ
#### Phase 1: MIRデバッグ基盤（2週間）
- [ ] MIRDebugInfo構造の実装
@ -764,7 +652,7 @@ impl DeepInspectorBox {
- [ ] サンプリングモード
- [ ] 増分参照グラフ更新
### 💎 統一の美しさ
### 💎 統一デバッグの美しさ
この設計により、以下が実現されます：

39
docs/reference/boxes-system/p2p_box.md Normal file
View File

@ -0,0 +1,39 @@
# P2PBox - Modern P2P Node (InProcess)
Status: Experimental (Phase 9.79a)
## Overview
- Structured messaging with `IntentBox(name, payload)`
- Local in-process routing via `MessageBus`
- Deterministic smoke demo available without timers
## API
- `new P2PBox(nodeId: String, transport: String)`
- `send(to: String|Box, intent: IntentBox) -> ResultBox`
- `on(name: String, handler: MethodRef) -> ResultBox`
- `onOnce(name: String, handler: MethodRef) -> ResultBox`
- `off(name: String) -> ResultBox`
- `getNodeId() -> String`
- `isReachable(nodeId: String) -> Bool`
- `getTransportType() -> String`
- `debugNodes() -> String` (inprocess only)
- `debugBusId() -> String` (inprocess only)
- `getLastFrom() -> String` (loopback trace)
- `getLastIntentName() -> String` (loopback trace)
Notes:
- Handlers currently accept a method reference (`MethodBox`) rather than an inline function literal.
- For quick loopback smoke without handlers, send to self and read `getLast*()`.
## Quick Smoke (No Handlers)
```
alice = new P2PBox("alice", "inprocess")
msg = new IntentBox("ping", { })
res = alice.send("alice", msg)
print("last.from=" + alice.getLastFrom())
print("last.intent=" + alice.getLastIntentName())
```
## Two-Node Ping-Pong (Concept)
This is covered in unit tests; handler wiring uses `MethodBox` internally. A higher-level sugar for method references will arrive in later phases.