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

feat(plugin): Fix plugin BoxRef return and Box argument support

Browse Source 
- Fixed deadlock in FileBox plugin copyFrom implementation (single lock)
- Added TLV Handle (tag=8) parsing in calls.rs for returned BoxRefs
- Improved plugin loader with config path consistency and detailed logging
- Fixed loader routing for proper Handle type_id/fini_method_id resolution
- Added detailed logging for TLV encoding/decoding in plugin_loader_v2

Test docs/examples/plugin_boxref_return.nyash now works correctly:
- cloneSelf() returns FileBox Handle properly
- copyFrom(Box) accepts plugin Box arguments
- Both FileBox instances close and fini correctly

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

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Moe Charm
2025-08-21 00:41:26 +09:00
parent af32896574
commit cc2a820af7
274 changed files with 7244 additions and 4608 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/development/README.md Normal file
View File

@ -0,0 +1,33 @@
# Nyash Development Documentation 🔧
開発者向けの進行中タスクと開発計画ドキュメントです。
## 📂 ディレクトリ構造
### current/
- `CURRENT_TASK.md` - 現在進行中のタスク
- アクティブな開発作業の詳細
- 最新の実装状況
### roadmap/
- **phases/** - フェーズ別開発計画
- phase-8/ - AST→MIR変換
- phase-9/ - VM/JIT実装
- phase-10/ - AOT最適化
- **native-plan/** - ネイティブビルド計画
- 実行バックエンド統合
- パフォーマンス目標
### proposals/
- RFC（Request for Comments）
- 新機能提案
- 設計ディスカッション
## 🎯 重要な参照先
- **進行状況**: `current/CURRENT_TASK.md`
- **開発計画**: `roadmap/phases/`
- **技術提案**: `proposals/`
## 📝 注意事項
このディレクトリの内容は開発中であり、頻繁に変更されます。
安定した仕様は`reference/`を参照してください。

53
docs/development/current/CURRENT_TASK.md Normal file
View File

@ -0,0 +1,53 @@
# 🎯 CURRENT TASK - 2025年8月20日
## 📊 現在の状況
### ✅ 完了したタスク
1. **ドキュメント再編成** - 完全完了！
- 283ファイル → 4大カテゴリに整理
- Phaseファイルも統合済み
- 説明書/予定フォルダ削除済み
2. **プラグインBox基本実装** (Phase 9.78c)
- FileBoxプラグイン実装済み
- インタープリター経由の呼び出し成功
- 基本的な引数/戻り値サポート追加（ChatGPT5による）
### 🚧 現在の課題
1. **Bashコマンドエラー問題**
- docs整理で現在のディレクトリが削除された影響
- セッション再起動が必要かも
2. **E2Eテスト状況**（tests/e2e_plugin_filebox.rs）
- インタープリターテスト: ✅ 成功（FileBox.close()が"ok"を返す）
- デリゲーションテスト: ❓ 未実装の可能性
- VMテスト: ❌ 失敗（VMはまだプラグインBox未対応）
### 🎯 次のタスク (Phase 9.78b)
#### Step 3: BoxFactory dyn化（優先度: 高）
- 現在: `HashMap<String, Box<dyn Fn() -> Arc<dyn NyashBox>>>`
- 目標: `HashMap<String, Arc<dyn BoxFactory>>`
- 利点: プラグインBoxもVMで統一処理可能
#### Step 4: グローバル排除
- `get_global_registry()` → `runtime.registry`
- `get_global_loader_v2()` → `runtime.plugin_loader`
#### Step 5: SharedState分解
- 巨大なSharedState構造体を分割
- Box管理、メソッド管理、スコープ管理を分離
### 📝 メモ
- ChatGPT5がプラグインBoxメソッド呼び出しに引数/戻り値サポートを追加
- TLV (Type-Length-Value) エンコーディングで引数をプラグインに渡す実装
- Rustの借用チェッカーとの格闘の跡が見られる（複数回の修正）
### 🔧 推奨アクション
1. セッション再起動してBashコマンドを復活
2. ビルド実行: `cargo build --release -j32`
3. E2Eテスト実行: `cargo test e2e_plugin_filebox --features plugins -- --show-output`
4. VMプラグイン統合の実装開始（Phase 9.78b Step 3）
---
最終更新: 2025年8月20日 22:45

147
docs/development/current/CURRENT_VM_CHANGES.md Normal file
View File

@ -0,0 +1,147 @@
# 🔄 現在のVM変更状態 (2025-08-21)
## 📊 Phase 9.78a VM統一Box処理の実装状況
### ✅ 完了したステップ
#### **Step 1: MIR生成修正** ✅
`src/mir/builder.rs`の変更内容：
```rust
// 変更前: RefNew命令（不適切）
match class.as_str() {
"IntegerBox" | "StringBox" | "BoolBox" => {
emit(MirInstruction::Const { ... })
}
_ => {
emit(MirInstruction::RefNew { ... })
}
}
// 変更後: NewBox命令（統一）
emit(MirInstruction::NewBox {
dst,
box_type: class,
args: arg_values,
})
```
**評価**: ✅ 良い変更。すべてのBox型を統一的に扱える。
#### **Step 2: VM構造体拡張** 🔧 部分完了
`src/backend/vm.rs`の変更内容：
1. **新規インポート追加**:
- `BoxFactory` → ❌ trait/struct混在問題
- `InstanceBox` ✅
- `BoxDeclaration` → ⚠️ interpreter依存
- `ScopeTracker` ✅
2. **VM構造体への追加**:
```rust
box_factory: Arc<BoxFactory>, // ❌ エラー：traitには dyn 必要
plugin_loader: Option<Arc<PluginLoaderV2>>,
scope_tracker: ScopeTracker,
box_declarations: Arc<RwLock<HashMap<String, BoxDeclaration>>>,
```
3. **新規メソッド追加**:
- `new_with_factory()` → 名前変更必要
- `new_with_plugins()`
#### **Step 3: NewBox統一実装** 🔧 部分完了
VM内のNewBox命令処理を統一実装に更新：
```rust
// BoxFactory経由で作成
let new_box = match self.box_factory.create_box(box_type, arg_boxes) {
Ok(boxed) => boxed,
Err(e) => return Err(...),
};
```
**問題**: BoxFactoryがtraitなのでコンパイルエラー
#### **Step 4: BoxCall統一実装** ✅ 完了
- `call_unified_method()`を追加
- 現在は簡易実装（call_box_methodに委譲）
#### **Step 5: ライフサイクル管理** 🔧 部分完了
- `ScopeTracker`を新規作成
- `execute_function()`でスコープ管理追加
- fini実装は簡易版
### 🚨 現在の問題点
1. **BoxFactory trait問題**:
- VMはBoxFactoryをstructとして期待
- 実際はtraitとして定義されている
- `UnifiedBoxRegistry`を使うべきか？
2. **BoxDeclaration依存問題**:
- `interpreter::BoxDeclaration`を使用
- VMからinterpreterへの依存は良くない
3. **ビルドエラー**:
```
error[E0782]: expected a type, found a trait
--> src/backend/vm.rs:175:22
```
## 🎯 推奨アクション
### **Option A: 置いておく（推奨）** ✅
**理由**:
- MIR生成修正（Step 1）は良い変更で保持すべき
- VM拡張の方向性は正しい
- インタープリター整理後に再開が効率的
**実行手順**:
```bash
# 現在の変更を一時保存
git stash push -m "Phase 9.78a VM unified Box handling WIP"
# または feature ブランチに保存
git checkout -b feature/vm-unified-box-wip
git add -A
git commit -m "WIP: Phase 9.78a VM unified Box handling"
git checkout main
```
### **Option B: 部分的に保持**
**保持すべき部分**:
- ✅ MIR生成修正（Step 1）
- ✅ ScopeTracker実装
**巻き戻すべき部分**:
- ❌ VM構造体へのBoxFactory追加
- ❌ interpreter::BoxDeclaration依存
### **Option C: 全て巻き戻す**
**非推奨**: MIR生成修正は価値があり、保持すべき
## 📝 今後の計画
1. **Phase 1**: インタープリター整理
- BoxDeclarationをast.rsへ移動
- SharedState依存を減らす
- NyashRuntime共通基盤作成
2. **Phase 2**: VM実装再開
- 整理されたインターフェースを使用
- UnifiedBoxRegistryベースで実装
- プラグインシステム統合
## 🔧 技術的詳細
### 変更されたファイル
- `src/mir/builder.rs`: -72行（RefNew → NewBox）
- `src/backend/vm.rs`: +164行（構造体拡張、メソッド追加）
- `src/lib.rs`: +1行（scope_trackerモジュール）
- `src/scope_tracker.rs`: 新規ファイル（68行）
### 依存関係の問題
```
VM → interpreter::BoxDeclaration ❌
VM → BoxFactory (trait) ❌
VM → UnifiedBoxRegistry ✅ (推奨)
```
---
**結論**: **Option A（置いておく）**を推奨します。現在の実装は方向性として正しく、インタープリター整理後に続きから再開するのが最も効率的です。

82
docs/development/current/phase_9_78e_summary.md Normal file
View File

@ -0,0 +1,82 @@
# Phase 9.78e: Dynamic Method Dispatch Implementation Summary
## 🎯 Overview
Phase 9.78e aimed to implement dynamic method dispatch through the `call_method` trait method to unify method calling across all Box types.
## ✅ Completed Tasks
### 1. **NyashBox Trait Enhancement**
- Added `call_method` to the NyashBox trait in `src/box_trait.rs`
- Default implementation returns `MethodNotFound` error
- Signature: `fn call_method(&mut self, method_name: &str, args: Vec<NyashValue>) -> Result<NyashValue, RuntimeError>`
### 2. **StringBox Implementation**
- Implemented `call_method` in `src/boxes/string_box.rs`
- Supports all StringBox methods:
- `type_name()`, `equals()`, `length()`
- `concat()`, `split()`, `toUpperCase()`, `toLowerCase()`
- `trim()`, `indexOf()`, `replace()`, `charAt()`, `substring()`
- Includes argument validation and proper error handling
### 3. **InstanceBox Implementation**
- Implemented `call_method` in `src/instance_v2.rs` with delegation pattern:
1. First checks user-defined methods
2. Delegates to inner box for builtin methods
3. Handles InstanceBox-specific methods (`getField`, `setField`, `hasMethod`)
- Enables transparent method calls on wrapped builtin boxes
### 4. **Error Type Updates**
- Added new RuntimeError variants:
- `MethodNotFound { method_name: String, type_name: String }`
- `FieldNotFound { field_name: String, class_name: String }`
### 5. **Interpreter Integration (Partial)**
- Added call_method integration in `src/interpreter/expressions/calls.rs`
- Implemented type conversion logic for Box<dyn NyashBox> to NyashValue
- Added debug output for tracking method dispatch flow
## 🚧 Challenges Encountered
### 1. **Type Conversion Complexity**
- Converting between `Box<dyn NyashBox>`, `Arc<Mutex<dyn NyashBox>>`, and `NyashValue`
- Current workaround: Direct type-based conversion for basic types
### 2. **Binary Compilation Issues**
- Several unrelated compilation errors in the binary prevent full testing
- Library builds successfully with call_method implementation
### 3. **Architecture Considerations**
- The current Box/NyashValue dual system creates friction
- Future consideration: Unified value representation system
## 📋 Test Results
- Basic StringBox creation and string operations work correctly
- Method calls currently fall back to legacy dispatch system
- Call_method infrastructure is in place but needs full integration
## 🔮 Next Steps
### Immediate Tasks:
1. Fix binary compilation errors to enable full testing
2. Complete NyashValue/Box type conversion helpers
3. Implement call_method for remaining builtin Box types
### Long-term Improvements:
1. Consider unified value representation to simplify type conversions
2. Optimize method dispatch performance
3. Add comprehensive test coverage for all Box types
## 💡 Key Insights
- The delegation pattern in InstanceBox successfully enables method calls on wrapped boxes
- Dynamic dispatch through call_method provides a clean abstraction for method calling
- Type conversion between the Box trait system and NyashValue remains a key challenge
## 📝 Code Locations
- Trait definition: `src/box_trait.rs:124-130`
- StringBox impl: `src/boxes/string_box.rs:160-313`
- InstanceBox impl: `src/instance_v2.rs:197-263`
- Interpreter integration: `src/interpreter/expressions/calls.rs:230-288`
---
*Phase 9.78e establishes the foundation for unified method dispatch across all Nyash Box types, with the core infrastructure successfully implemented and ready for expanded integration.*

241
docs/development/proposals/architecture-redesign-proposal.md Normal file
View File

@ -0,0 +1,241 @@
# 🌟 Nyash アーキテクチャ再設計提案
*by Codex exec (2025-08-21)*
## 🎯 核心的洞察
**「実装詳細共有」から「モデル共有・実行時共有」への転換**
現在の問題の本質は、InterpreterとVMが「実装詳細」を共有しようとしていること。正しいアプローチは「モデル（宣言）」と「ランタイム（実行環境）」を共有し、実行戦略だけを分離すること。
## 🏗️ 新アーキテクチャ層構造
```
┌─────────────┐
│ AST/Model │ ← 純粋なデータモデル（依存なし）
└──────┬──────┘
│
┌──────▼──────┐
│ Runtime │ ← 型システム・クラス管理・インスタンス生成
└──────┬──────┘
│
┌──────┴──────┬──────────┬────────────┐
│ Interpreter │ VM │ Plugins │
└─────────────┴──────────┴────────────┘
```
### 各層の責務
**AST/Model層**
- 言語の純データモデル
- BoxDeclaration、ASTNode、型シグネチャ
- 実行時情報を含まない
**Runtime層**
- BoxClass/BoxFactoryによる型システム
- インスタンス生成とライフサイクル管理
- メソッドディスパッチと呼び出し規約
**Backend層**
- Interpreter: AST直接実行
- VM: MIR/Bytecode実行
- 両者ともRuntimeを通じてBoxを操作
## 🔧 具体的な設計
### 1. BoxDeclarationの移動
```rust
// core::model::box_declaration.rs
pub struct BoxDeclaration {
pub name: String,
pub type_params: Vec<TypeParam>,
pub fields: Vec<FieldDecl>,
pub methods: Vec<MethodDecl>,
pub static_methods: Vec<StaticDecl>,
pub attrs: AttrSet,
pub source_span: Option<Span>,
}
pub struct FieldDecl {
pub name: String,
pub ty: TypeRef,
pub attrs: AttrSet,
}
pub struct MethodDecl {
pub name: String,
pub sig: FnSig,
pub body: FnBodyRef, // AST or MIR reference
}
```
### 2. NyashRuntimeの導入
```rust
// runtime::mod.rs
pub struct NyashRuntime {
box_registry: BoxRegistry,
type_space: TypeSpace,
fn_space: FnSpace,
}
pub struct ExecutionSession {
runtime: Arc<NyashRuntime>,
root_box: SharedBox,
frames: Vec<Frame>,
env: Environment,
}
// SharedBox = Arc<dyn NyashBox>
pub type SharedBox = Arc<dyn NyashBox>;
```
### 3. BoxClass/Factoryシステム
```rust
// runtime::box_class.rs
pub trait BoxClass: Send + Sync {
fn name(&self) -> &str;
fn instantiate(
&self,
args: &[SharedBox],
sess: &mut ExecutionSession
) -> Result<SharedBox>;
fn lookup_method(&self, name: &str) -> Option<MethodHandle>;
fn lifecycle(&self) -> Option<&dyn BoxLifecycle>;
}
pub trait BoxFactory: Send + Sync {
fn can_build(&self, decl: &BoxDeclaration) -> bool;
fn build_class(
&self,
decl: &BoxDeclaration,
rt: &NyashRuntime
) -> Result<Arc<dyn BoxClass>>;
}
pub trait BoxLifecycle {
fn on_birth(&self, ctx: &mut InstanceCtx) -> Result<()>;
fn on_fini(&self, ctx: &mut InstanceCtx);
}
```
### 4. 統一されたBox管理
```rust
// runtime::registry.rs
pub struct BoxRegistry {
classes: RwLock<HashMap<String, Arc<dyn BoxClass>>>,
factories: RwLock<Vec<Arc<dyn BoxFactory>>>,
}
impl BoxRegistry {
pub fn register_class(&self, class: Arc<dyn BoxClass>) {
// 登録処理
}
pub fn get_class(&self, name: &str) -> Option<Arc<dyn BoxClass>> {
// クラス取得
}
pub fn create_instance(
&self,
class_name: &str,
args: &[SharedBox],
sess: &mut ExecutionSession
) -> Result<SharedBox> {
let class = self.get_class(class_name)?;
class.instantiate(args, sess)
}
}
```
## 📋 実装手順（最小破壊的移行）
### Step 1: BoxDeclarationの移動
```rust
// 1. core::model モジュールを作成
// 2. BoxDeclarationを移動
// 3. インタープリターで一時的に別名を使用
use core::model::BoxDeclaration as InterpreterBoxDecl;
```
### Step 2: NyashRuntimeの骨組み作成
```rust
// 最初は空の実装から始める
pub struct NyashRuntime {
// 段階的に追加
}
pub struct NyashRuntimeBuilder {
// SharedStateからの移行を支援
}
```
### Step 3: BoxFactoryのdyn化
```rust
// 現在の trait BoxFactory を使用
// すべて Arc<dyn BoxFactory> として扱う
```
### Step 4: グローバル登録の排除
```rust
// 削除: register_user_defined_factory(...)
// 追加: NyashRuntimeBuilder::with_factory(...)
```
### Step 5: SharedStateの段階的分解
```rust
// 一時的なシム
pub struct SharedStateShim {
runtime: Arc<NyashRuntime>,
session: ExecutionSession,
}
// 互換性のためのFrom実装
impl From<SharedState> for SharedStateShim {
// 移行ロジック
}
```
### Step 6-8: 統一と最適化
- Interpreter/VMのコンストラクタ統一
- birth/finiライフサイクルの一元化
- 最終的なSharedState削除
## 🎯 得られる利点
1. **依存関係の明確化**
- VM→Interpreter依存が完全に解消
- 両者はRuntimeのみに依存
2. **テスタビリティ向上**
- グローバル状態なし
- 並行テスト可能
3. **保守性向上**
- 責務が明確に分離
- 新しいBackend追加が容易
4. **Everything is Box哲学の貫徹**
- 統一的なBox管理
- birth/finiライフサイクルの一元化
## ⚠️ 実装上の注意点
1. **trait objectは必ず`Arc<dyn Trait>`**
- `Arc<Trait>`は使わない
- dynキーワードを忘れない
2. **段階的移行**
- 各ステップでテストが通ることを確認
- 互換性レイヤーを活用
3. **ロックの最小化**
- Runtimeは基本的に不変
- 必要最小限のRwLock使用
---
この設計により、Nyashはよりシンプルでエレガントなアーキテクチャとなり、InterpreterとVMの統合が自然に実現されます。

123
docs/development/proposals/instance_v2_unified_box_registry_plan.md Normal file
View File

@ -0,0 +1,123 @@
# Instance v2 統一レジストリ設計メモ（提案）
目的: ユーザー定義 / ビルトイン / プラグインの3系統を instance_v2 で一元管理し、同一の生成（birth）/破棄（fini）ライフサイクルで扱えるようにする。また、wasm-bindgen ターゲットでプラグイン機構を安全に無効化できる切替を用意する。
---
## 現状の整理（実装済み）
- ユーザー定義Box
- インタプリタの AST → InstanceBox 生成で対応済み。
- `execute_new` は最初に統一レジストリを呼び、ユーザー定義については最終的に `InstanceBox` を構築し、birth 相当のコンストラクタ実行を行う。
- ビルトインBox
- 統一レジストリ経由で生成可能。ユーザー定義と同じ呼び出し経路に乗る。
- プラグインBox（v2）
- `nyash.toml v2` を `PluginLoaderV2` が読み込み、`nyash_plugin_invoke` の birth 呼び出しでインスタンスを生成。
- 現状、`PluginBoxV2` は `clone_box=新birth`、`share_box=同一 instance_id` を実装済み。
---
## 目標
1. 3系統（ユーザー定義/ビルトイン/プラグイン）を「統一レジストリ→instance_v2」で一元管理。
2. birth/fini ライフサイクルの整合をとる。
3. wasm-bindgen ターゲット（`wasm32-unknown-unknown`）ではプラグイン機構をコンパイル時に無効化し、ビルド可能にする。
---
## 設計方針
### 1) 統一レジストリの責務
- 名前（クラス名）と引数（`Box<dyn NyashBox>` の配列）を入力に、ユーザー定義/ビルトイン/プラグインの順で解決・生成を試みる。
- 生成に成功したら `Box<dyn NyashBox>` を返す。
- ユーザー定義: `InstanceBox` とし、インタプリタがコンストラクタ（birth）を実行。
- ビルトイン: 直接生成（必要なら簡易birth相当の初期化）
- プラグイン: `PluginLoaderV2` の `invoke_fn(type_id, method_id=0=birth, ...)` を呼ぶ。
### 2) birth / fini ライフサイクル
- birth:
- ユーザー定義: 既存通り AST 上のコンストラクタ（birth）を呼ぶ。
- プラグイン: `nyash.toml` の `methods.birth` の method_id=0 を使い、`invoke_fn` 呼び出しで instance_id を取得済み。
- fini:
- InstanceBox のフィールド差し替え時、旧値が InstanceBox なら `fini()` を呼んで finalize 済みIDとしてマーキング（実装済み）。
- プラグインBoxについても `nyash.toml` で `methods.fini`（例: 0xFFFF）を定義し、差し替えやスコープ終端で `invoke_fn(type_id, method_id=fini, instance_id, ...)` を呼ぶ。エラーは握りつぶさずログ化。
### 3) wasm-bindgen ターゲットでの切り替え
- Cargo features によるコンパイル時ガードを導入：
- `plugins`（デフォルトON）、`wasm-backend`（WASMビルド用）の2フラグを用意。
- `#[cfg(all(feature = "plugins", not(target_arch = "wasm32")))]` のときのみ `plugin_loader_v2` 実体を有効化。
- それ以外では `plugin_loader_v2` のスタブ実装を使う（常に `Err(BidError::PluginError)` を返すなど）。
- 統一レジストリはプラグインFactoryの登録を `#[cfg(feature="plugins")]` でガードし、WASMビルドでもユーザー定義/ビルトインは動かせる。
- `nyash.toml` のファイルI/O（`from_file`）も `cfg` で握り、WASMではロードしない。
---
## nyash.toml v2 との整合
- 既存:
- `libraries.<libname>.boxes = ["FileBox"]`
- `libraries.<libname>.<BoxType>.methods.birth = { method_id = 0 }`
- `... .fini = { method_id = 4294967295 }` など
- 追加検討:
- 将来、ユーザー定義Boxをプラグインで置換したい場合：
- クラス名→プラグインBox型の上書きマップを `nyash.toml` に追加（例：`overrides = { "DataBox" = "libX::RemoteDataBox" }`）。
- 統一レジストリがこのマップを見て、ユーザー定義をスキップしてプラグインへ委譲。
---
## API/コード上の具体案（抜粋）
- features（`Cargo.toml`）:
```toml
[features]
default = ["plugins"]
plugins = []
wasm-backend = []
```
- プラグインローダ（`src/runtime/plugin_loader_v2.rs`）:
```rust
#[cfg(all(feature = "plugins", not(target_arch = "wasm32")))]
pub mod real_loader { /* 現在の実装 */ }
#[cfg(any(not(feature = "plugins"), target_arch = "wasm32"))]
pub mod stub_loader {
use crate::bid::{BidResult, BidError};
use crate::box_trait::NyashBox;
pub struct PluginLoaderV2; // ダミー
impl PluginLoaderV2 { pub fn new() -> Self { Self } }
impl PluginLoaderV2 {
pub fn load_config(&mut self, _p: &str) -> BidResult<()> { Ok(()) }
pub fn load_all_plugins(&self) -> BidResult<()> { Ok(()) }
pub fn create_box(&self, _t: &str, _a: &[Box<dyn NyashBox>]) -> BidResult<Box<dyn NyashBox>> {
Err(BidError::PluginError)
}
}
}
```
- 統一レジストリのFactory登録部は `#[cfg(feature = "plugins")]` でプラグインFactoryの登録を条件化。
---
## マイグレーション手順（段階）
1. Cargo features と cfg ガードの導入（プラグイン機構のスタブ化を含む）。
2. 統一レジストリのプラグインFactory登録の条件化。
3. プラグインBoxの `fini` 呼び出し用メソッドを InstanceBox 置換/破棄パスへ組み込む。
4. 必要に応じて `nyash.toml` の `methods.fini` を明記。
5. 追加要件（ユーザー定義のプラグイン置換）を `overrides` マップで設計 → 実装。
---
## テスト観点
- ユニット:
- birth/fini の呼び出し順と複数回置換時の `fini` 呼び出し保証。
- `plugins` ON/OFF、`wasm-backend` ON の3軸でビルド/テストが通ること。
- 統合テスト:
- `nyash.toml` によるビルトイン→プラグインの透過切替。
- ユーザー定義→ビルトイン→プラグインの優先順位が想定通り。
---
## メモ
- すでに `execute_new` は統一レジストリ優先の実装になっており、この設計と整合が良い。
- WASM ターゲットでは `libloading` が使えないため、コンパイル時に完全にプラグインコードを外す方針（cfg/feature）は自然。
- `nyash.toml` のロードはネイティブ時のみで十分（WASM は将来、バンドルまたは JS 側から供給する計画があるなら別途）。
---
以上。必要であれば、この方針でPRを小さく分割（features→レジストリ→fini→overrides）して入れていきます。

80
docs/development/proposals/issue_62_update_proposal.md Normal file
View File

@ -0,0 +1,80 @@
# Issue 62 Update Proposal: Enable String Constants in WASM Backend First
This is a concrete request to implement minimal string support in the WASM backend so that Issue #62 can proceed. It reflects the current repo state.
## Background
- As noted in Issue #61, the current WASM backend does not support string constants yet.
- Issue #62 depends on string support and cannot be completed without it.
- Current state:
- `src/backend/wasm/codegen.rs` → `generate_const` handles only Integer/Bool/Void; String is not implemented.
- `src/backend/wasm/memory.rs` already defines a basic layout for `StringBox`:
- Header: `[type_id:i32][ref_count:i32][field_count:i32]`
- Fields: `[data_ptr:i32][length:i32]`
- `StringBox` type_id = `0x1001`.
## Goal
Add minimal string constant support to the WASM backend:
- Allow `ConstValue::String` in codegen by embedding UTF-8 string bytes and constructing a `StringBox` with `[data_ptr,length]`.
- Provide a minimal debugging import `env.print_str(ptr,len)` to verify strings at runtime.
- Unblock Issue #62 implementation and tests that require strings.
## Scope
Minimal features required:
1) Data segments for string literals
- Extend `WasmModule` (in `codegen.rs`) with a `data_segments: Vec<String>` field.
- Update `to_wat()` to emit `(data ...)` after memory/globals and before functions/exports.
- For each string constant, create a unique offset and emit a `(data (i32.const <offset>) "...bytes...")` entry.
2) Codegen for `ConstValue::String`
- In `generate_const`, when encountering `ConstValue::String(s)`,
- Allocate a data segment for `s` (UTF-8 bytes) and get its offset and length.
- Allocate a `StringBox` using existing helpers (see `MemoryManager`),
then set its fields: `data_ptr` and `length`.
- Return the `StringBox` pointer (i32) in the destination local.
3) Helper for `StringBox` allocation
- Either:
- Provide a dedicated WAT helper function `$alloc_stringbox` that calls `$malloc`, writes header (`type_id=0x1001`, `ref_count=1`, `field_count=2`), and returns the box pointer, then inline store `data_ptr`/`length`.
- Or:
- Use `$box_alloc` with `(type_id=0x1001, field_count=2)` and then store `data_ptr`/`length` via generated `i32.store` sequences.
4) Runtime import for string output (for verification)
- Extend `RuntimeImports` (`src/backend/wasm/runtime.rs`) with:
- `(import "env" "print_str" (func $print_str (param i32 i32)))`
- In host (Node/Browser), implement `importObject.env.print_str = (ptr,len) => { decode UTF-8 from memory; console.log(...) }`.
5) E2E test
- Add a tiny program that produces/prints a string (e.g., Const String → call `env.print_str(ptr,len)` via a minimal MIR program) and verify it logs the correct text.
- Option: update `test_runner.js` to include `print_str` and decode from memory using `TextDecoder('utf-8')`.
## Out of Scope (for this change)
- String operations (concat/substr/compare), normalization, encoding conversions.
- GC/RC or freeing memory (current allocator is bump-only).
- Returning StringBox directly from `main` (keep verification via `print_str`).
## Acceptance Criteria
- Generated WAT includes `(data ...)` segments for string literals and correct offsets.
- `ConstValue::String` codegen constructs a valid `StringBox` with proper `[data_ptr,length]`.
- `env.print_str` correctly prints UTF-8 strings in both Browser and Node runners.
- Issue #62 tasks that rely on strings can proceed.
## References (repo paths)
- String unsupported path: `src/backend/wasm/codegen.rs` (`generate_const`)
- Memory/layout: `src/backend/wasm/memory.rs` (StringBox, type_id=0x1001)
- Runtime imports: `src/backend/wasm/runtime.rs` (currently only `env.print(i32)`)
- Node runner: `test_runner.js` (has `env.print`; extend with `print_str`)
## Notes
- Data segment approach is the simplest for initial support; future work may add constant pooling and deduplication.
- Keeping verification via `print_str(ptr,len)` avoids complicating function return types for now.
- UTF-8 decoding is available in hosts via `TextDecoder('utf-8')`.

361
docs/development/proposals/mir_reduction_detailed_analysis.md Normal file
View File

@ -0,0 +1,361 @@
# MIR 35→26命令削減: 詳細分析・移行戦略
*実装ベース完全マッピング - 2025年8月17日版*
## 🔍 **現在実装35命令 vs ChatGPT5仕様26命令の完全マッピング**
### **維持する命令 (既存実装 → 26命令仕様)**
| 現在実装 | 26命令仕様 | 効果 | 変更 |
|----------|------------|------|------|
| `Const` | `Const` | pure | ✅ 維持 |
| `BinOp` | `BinOp` | pure | ✅ 維持 |
| `Compare` | `Compare` | pure | ✅ 維持 |
| `Branch` | `Branch` | control | ✅ 維持 |
| `Jump` | `Jump` | control | ✅ 維持 |
| `Phi` | `Phi` | pure | ✅ 維持 |
| `Call` | `Call` | context | ✅ 維持 |
| `Return` | `Return` | control | ✅ 維持 |
| `NewBox` | `NewBox` | mut | ✅ 維持 |
| `BoxCall` | `BoxCall` | context | ✅ 維持 |
| `ExternCall` | `ExternCall` | context | ✅ 維持 |
| `Safepoint` | `Safepoint` | io | ✅ 維持 |
| `RefGet` | `RefGet` | pure | ✅ 維持 |
| `RefSet` | `RefSet` | mut | ✅ 維持 |
| `WeakNew` | `WeakNew` | pure | ✅ 維持 |
| `WeakLoad` | `WeakLoad` | pure | ✅ 維持 |
**小計**: 16命令維持
### **削除する命令 (17命令)**
#### **グループ1: BinOp統合 (1命令)**
| 削除命令 | 置換方法 | 実装例 |
|----------|----------|--------|
| `UnaryOp` | `BinOp`統合 | `not %a` → `%a xor true`<br>`neg %a` → `0 sub %a` |
#### **グループ2: BoxField操作統合 (4命令)**
| 削除命令 | 置換方法 | 実装例 |
|----------|----------|--------|
| `Load` | `BoxFieldLoad` | `load %ptr` → `%ptr.value` |
| `Store` | `BoxFieldStore` | `store %val -> %ptr` → `%ptr.value = %val` |
| `ArrayGet` | `BoxFieldLoad` | `%arr[%idx]` → `%arr.elements[%idx]` |
| `ArraySet` | `BoxFieldStore` | `%arr[%idx] = %val` → `%arr.elements[%idx] = %val` |
#### **グループ3: intrinsic化 (6命令)**
| 削除命令 | intrinsic名 | 実装例 |
|----------|-------------|--------|
| `Print` | `@print` | `print %val` → `call @print, %val` |
| `Debug` | `@debug` | `debug %val "msg"` → `call @debug, %val, "msg"` |
| `TypeCheck` | `@type_check` | `type_check %val "Type"` → `call @type_check, %val, "Type"` |
| `Cast` | `@cast` | `cast %val Type` → `call @cast, %val, Type` |
| `Throw` | `@throw` | `throw %exc` → `call @throw, %exc` |
| `Catch` | `@catch` | `catch Type -> %bb` → `call @catch, Type, %bb` |
#### **グループ4: 完全削除 (3命令)**
| 削除命令 | 削除理由 | 代替方法 |
|----------|----------|----------|
| `Copy` | 最適化パス専用 | 最適化段階でのみ使用 |
| `Nop` | 不要 | 削除（プレースホルダー不要） |
| `RefNew` | 冗長 | `RefGet`で代用可能 |
#### **グループ5: 統合・置換 (3命令)**
| 削除命令 | 統合先 | 実装例 |
|----------|--------|--------|
| `BarrierRead` | `AtomicFence` | `barrier_read %ptr` → `atomic_fence acquire` |
| `BarrierWrite` | `AtomicFence` | `barrier_write %ptr` → `atomic_fence release` |
| `FutureNew` | `NewBox + BoxCall` | `future_new %val` → `%f = new_box "Future"(%val)` |
| `FutureSet` | `BoxCall` | `future_set %f = %val` → `%f.set(%val)` |
| `Await` | `BoxCall` | `await %f` → `%f.await()` |
### **追加する命令 (10命令)**
| 新命令 | 効果 | 目的 | 実装必要度 |
|--------|------|------|------------|
| `BoxFieldLoad` | pure | Everything is Box核心 | 🔥 Critical |
| `BoxFieldStore` | mut | Everything is Box核心 | 🔥 Critical |
| `WeakCheck` | pure | weak参照完全対応 | ⚡ High |
| `Send` | io | Bus操作一次市民化 | ⚡ High |
| `Recv` | io | Bus操作一次市民化 | ⚡ High |
| `TailCall` | control | JIT最適化基盤 | 📝 Medium |
| `Adopt` | mut | 所有権移管明示 | 📝 Medium |
| `Release` | mut | 所有権移管明示 | 📝 Medium |
| `MemCopy` | mut | 最適化基盤 | 📝 Medium |
| `AtomicFence` | io | 並行制御統一 | 📝 Medium |
## 🛠️ **具体的実装戦略**
### **Phase 1: 新命令実装**
#### **BoxFieldLoad/BoxFieldStore実装**
```rust
// src/mir/instruction.rs
pub enum MirInstruction {
// 新規追加
BoxFieldLoad {
dst: ValueId,
box_val: ValueId,
field: String,
},
BoxFieldStore {
box_val: ValueId,
field: String,
value: ValueId,
},
// ...
}
```
#### **WeakCheck実装**
```rust
WeakCheck {
dst: ValueId,
weak_ref: ValueId,
}
```
#### **Send/Recv実装**
```rust
Send {
data: ValueId,
target: ValueId,
},
Recv {
dst: ValueId,
source: ValueId,
},
```
### **Phase 2: intrinsic関数システム実装**
#### **intrinsic レジストリ**
```rust
// src/interpreter/intrinsics.rs
pub struct IntrinsicRegistry {
functions: HashMap<String, IntrinsicFunction>,
}
impl IntrinsicRegistry {
pub fn new() -> Self {
let mut registry = Self { functions: HashMap::new() };
registry.register("@print", intrinsic_print);
registry.register("@debug", intrinsic_debug);
registry.register("@type_check", intrinsic_type_check);
registry.register("@cast", intrinsic_cast);
registry.register("@array_get", intrinsic_array_get);
registry.register("@array_set", intrinsic_array_set);
registry
}
}
```
#### **intrinsic関数実装例**
```rust
fn intrinsic_print(args: &[Value]) -> Result<Value, RuntimeError> {
println!("{}", args[0]);
Ok(Value::Void)
}
fn intrinsic_array_get(args: &[Value]) -> Result<Value, RuntimeError> {
let array = args[0].as_array_box()?;
let index = args[1].as_integer()?;
array.get_element(index as usize)
}
fn intrinsic_array_set(args: &[Value]) -> Result<Value, RuntimeError> {
let array = args[0].as_array_box_mut()?;
let index = args[1].as_integer()?;
let value = args[2].clone();
array.set_element(index as usize, value)
}
```
### **Phase 3: AST→MIR生成更新**
#### **Load/Store → BoxFieldLoad/BoxFieldStore変換**
```rust
// src/mir/builder.rs
impl MirBuilder {
fn visit_field_access(&mut self, node: &FieldAccessNode) -> Result<ValueId, BuildError> {
let box_val = self.visit_expression(&node.object)?;
let dst = self.new_temp_var();
// 旧: Load命令生成
// self.emit(MirInstruction::Load { dst, ptr: box_val });
// 新: BoxFieldLoad命令生成
self.emit(MirInstruction::BoxFieldLoad {
dst,
box_val,
field: node.field.clone(),
});
Ok(dst)
}
fn visit_field_assignment(&mut self, node: &FieldAssignmentNode) -> Result<(), BuildError> {
let box_val = self.visit_expression(&node.object)?;
let value = self.visit_expression(&node.value)?;
// 旧: Store命令生成
// self.emit(MirInstruction::Store { value, ptr: box_val });
// 新: BoxFieldStore命令生成
self.emit(MirInstruction::BoxFieldStore {
box_val,
field: node.field.clone(),
value,
});
Ok(())
}
}
```
#### **配列操作 → BoxField + intrinsic変換**
```rust
fn visit_array_access(&mut self, node: &ArrayAccessNode) -> Result<ValueId, BuildError> {
let array = self.visit_expression(&node.array)?;
let index = self.visit_expression(&node.index)?;
let dst = self.new_temp_var();
// intrinsic化
self.emit(MirInstruction::Call {
dst: Some(dst),
func: self.get_intrinsic_id("@array_get"),
args: vec![array, index],
effects: EffectMask::PURE,
});
Ok(dst)
}
```
### **Phase 4: バックエンド対応**
#### **Interpreter実装**
```rust
// src/backend/interpreter.rs
impl Interpreter {
fn execute_box_field_load(&mut self, dst: ValueId, box_val: ValueId, field: &str) -> Result<(), RuntimeError> {
let box_obj = self.get_value(box_val)?;
let field_value = box_obj.get_field(field)?;
self.set_value(dst, field_value);
Ok(())
}
fn execute_box_field_store(&mut self, box_val: ValueId, field: &str, value: ValueId) -> Result<(), RuntimeError> {
let mut box_obj = self.get_value_mut(box_val)?;
let field_value = self.get_value(value)?;
box_obj.set_field(field, field_value)?;
Ok(())
}
}
```
#### **VM実装**
```rust
// src/backend/vm.rs
impl VM {
fn exec_box_field_load(&mut self, dst: RegId, box_val: RegId, field_id: FieldId) -> VMResult<()> {
let box_ptr = self.registers[box_val as usize];
let field_value = unsafe {
self.load_field(box_ptr, field_id)
};
self.registers[dst as usize] = field_value;
Ok(())
}
}
```
#### **WASM実装**
```rust
// src/backend/wasm/codegen.rs
impl WasmCodegen {
fn generate_box_field_load(&mut self, dst: ValueId, box_val: ValueId, field: &str) -> Result<(), CodegenError> {
let box_addr = self.get_value_address(box_val)?;
let field_offset = self.get_field_offset(field)?;
// WASM: i32.load offset=field_offset
self.emit_wasm(&format!("i32.load offset={}", field_offset));
self.set_value_register(dst);
Ok(())
}
}
```
## 📊 **移行スケジュール詳細**
### **Week 1: 基盤実装 (8/18-8/24)**
- [ ] 新命令構造体定義
- [ ] intrinsicレジストリ実装
- [ ] パーサー拡張（新旧両対応）
### **Week 2: フロントエンド移行 (8/25-8/31)**
- [ ] AST→MIR変換更新
- [ ] 配列操作intrinsic化
- [ ] Load/Store→BoxField変換
### **Week 3: 最適化パス移行 (9/1-9/7)**
- [ ] Effect分類実装
- [ ] 所有権森検証
- [ ] BoxFieldLoad/Store最適化
### **Week 4: バックエンド移行 (9/8-9/14)**
- [ ] Interpreter新命令実装
- [ ] VM新命令実装
- [ ] WASM新命令実装
### **Week 5: クリーンアップ (9/15-9/21)**
- [ ] 旧命令完全削除
- [ ] テスト更新
- [ ] ドキュメント整備
## 🧪 **テスト・検証計画**
### **段階的テスト**
```bash
# Week 1終了時
./scripts/test_mir_parsing_26.sh
# Week 2終了時
./scripts/test_frontend_migration.sh
# Week 3終了時
./scripts/test_optimization_passes.sh
# Week 4終了時
./scripts/test_all_backends.sh
# Week 5終了時
./scripts/test_golden_mir_final.sh
```
### **性能回帰テスト**
```bash
# 削減前後性能比較
./scripts/benchmark_mir_reduction.sh
```
## 🎯 **リスク対策**
### **高リスク箇所**
1. **配列操作intrinsic化**: パフォーマンス影響大
2. **BoxField統合**: Box型システムとの整合性
3. **Effect分類変更**: 最適化ロジック全面見直し
### **対策**
- **プロトタイプ実装**: 高リスク箇所の事前検証
- **性能測定**: 各段階での性能チェック
- **ロールバック**: 問題発生時の迅速復旧
---
**分析完了**: 2025年8月17日
**実装開始**: 2025年8月18日
**完了予定**: 2025年9月21日

267
docs/development/proposals/nyash.link/README.md Normal file
View File

@ -0,0 +1,267 @@
# nyash.linkシステム設計 - モジュール・依存関係管理革命
## 🎯 設計背景
### 📊 現状調査結果
- **include使用状況**: 主にexamples/text_adventureで10件程度、実用性は限定的
- **usingキーワード**: **未実装**（トークナイザーにも存在しない）
- **namespace設計**: Phase 9.75eで仕様完成、実装待ち
### 🌟 Gemini先生の推奨
> 「技術的に非常に妥当であり、現代的なプログラミング言語の設計として強く推奨される」
**結論**: includeほぼ未使用 + using未実装 = 完全に新設計で進められる！🎉
## 🚀 設計方針
### 💡 基本コンセプト
```
依存関係管理（nyash.link） + モジュールインポート（using） = 完璧な統合
```
### 🎯 他言語成功モデル
- **Rust**: `Cargo.toml + mod/use` - 厳格で分かりやすい
- **Node.js**: `package.json + import/export` - エコシステム成功
- **Python**: `pyproject.toml + import` - 依存関係分離
## 📋 nyash.linkファイル仕様
### 基本フォーマット
```toml
# nyash.link (プロジェクトルート)
[project]
name = "my-nyash-project"
version = "0.1.0"
description = "素晴らしいNyashプロジェクト"
[dependencies]
# 標準ライブラリ
nyashstd = { path = "./stdlib/nyashstd.nyash" }
# ユーザーライブラリ
mylib = { path = "./libs/mylib.nyash" }
utils = { path = "./src/utils.nyash" }
# 将来の外部パッケージ（例）
# http_client = { version = "1.0.0", registry = "nyash-pkg" }
[search_paths]
stdlib = "./stdlib/"
libs = "./libs/"
src = "./src/"
[build]
entry_point = "./src/main.nyash"
```
### 依存関係タイプ
#### 1. **ローカル依存**
```toml
[dependencies]
my_module = { path = "./src/my_module.nyash" }
```
#### 2. **標準ライブラリ**
```toml
[dependencies]
nyashstd = { stdlib = true } # 特別扱い
```
#### 3. **将来の外部パッケージ**
```toml
[dependencies]
awesome_lib = { version = "^1.2.0", registry = "nyash-pkg" }
```
## 🔧 usingシステム設計
### 1. トークナイザー拡張
```rust
// src/tokenizer.rs に追加
pub enum TokenType {
// 既存...
USING, // using (モジュールインポート)
NAMESPACE, // namespace (名前空間宣言)
}
```
### 2. パーサー拡張
```rust
// AST拡張
pub enum Statement {
// 既存...
UsingStatement {
module_path: Vec<String>, // ["nyashstd", "string"]
alias: Option<String>, // using nyashstd.string as str
},
NamespaceDeclaration {
name: String,
body: Vec<Statement>,
},
}
```
### 3. 基本構文
```nyash
// ===== using構文パターン =====
// パターンA: 名前空間全体
using nyashstd
string.upper("hello") // nyashstd.string.upper
math.sin(3.14) // nyashstd.math.sin
// パターンB: 特定機能（将来拡張）
using nyashstd.string
upper("hello") // string.upperを直接
// パターンC: エイリアス（将来拡張）
using nyashstd.string as str
str.upper("hello")
// パターンD: 完全修飾名（常時利用可能）
nyashstd.string.upper("hello") // using不要
```
## 📁 推奨ディレクトリ構造
### 基本プロジェクト構造
```
my-nyash-project/
├── nyash.link # 依存関係定義
├── src/
│ ├── main.nyash # エントリーポイント
│ ├── utils.nyash # ユーティリティモジュール
│ └── models/
│ └── user.nyash # モデル定義
├── libs/ # プロジェクト固有ライブラリ
│ └── mylib.nyash
├── stdlib/ # 標準ライブラリ（システム配布）
│ └── nyashstd.nyash
└── tests/ # テストファイル
└── test_main.nyash
```
### 標準ライブラリ構造
```
stdlib/
├── nyashstd.nyash # メインエントリー
├── string/
│ └── mod.nyash # string関連機能
├── math/
│ └── mod.nyash # 数学関数
├── http/
│ └── mod.nyash # HTTP関連
└── io/
└── mod.nyash # I/O関連
```
## 🔄 動作フロー
### 1. プロジェクト初期化
```bash
# 将来のCLI例
nyash init my-project # nyash.linkテンプレート生成
cd my-project
```
### 2. 実行時解決
```
main.nyash実行
↓
nyash.link読み込み
↓
using nyashstd解析
↓
./stdlib/nyashstd.nyash読み込み
↓
namespace nyashstd解析・登録
↓
string.upper()利用可能
```
### 3. 名前解決アルゴリズム
```
string.upper() 呼び出し
↓
1. ローカルスコープ検索
2. usingでインポートされた名前空間検索
3. 完全修飾名として解釈
4. エラー（未定義）
```
## 🧪 実装段階
### Phase 1: 最小実装
```nyash
// ✅ 実装目標
using mylib // 単純パス解決
mylib.hello() // 関数呼び出し
// nyash.link
[dependencies]
mylib = { path = "./mylib.nyash" }
```
### Phase 2: 名前空間サポート
```nyash
// ✅ 実装目標
using nyashstd
string.upper("hello")
// nyashstd.nyash
namespace nyashstd {
static box string {
static upper(str) { ... }
}
}
```
### Phase 3: 高度機能
- エイリアス（`using ... as ...`）
- 選択インポート（`using nyashstd.string`）
- 循環依存検出
- パッケージレジストリ連携
## ⚡ 実装優先順位
### 🚨 Critical（即時）
1. **UsingTokenizer実装** - Token::USINGを追加
2. **基本パーサー** - using文AST構築
3. **nyash.link解析** - TOML読み込み機能
### ⚡ High（今週）
4. **名前解決エンジン** - モジュール→ファイル解決
5. **基本テスト** - using mylib動作確認
6. **エラー処理** - 未定義モジュール等
### 📝 Medium（来週）
7. **namespace構文** - static box解析
8. **標準ライブラリ設計** - nyashstd.nyash作成
9. **完全修飾名** - nyashstd.string.upper()
### 🔮 Future（今後）
10. **IDE連携** - Language Server補完
11. **パッケージマネージャー** - 外部レジストリ
12. **循環依存検出** - 高度エラー処理
## 🎉 期待効果
### 📈 開発体験向上
- **IDE補完**: `ny`→全標準機能表示
- **探索可能性**: モジュール構造が明確
- **エラー削減**: 名前衝突・未定義の事前検出
### 🏗️ プロジェクト管理
- **依存関係明確化**: nyash.linkで一元管理
- **ビルド再現性**: 他環境での確実な動作
- **スケーラビリティ**: 大規模プロジェクト対応
### 🌍 エコシステム発展
- **ライブラリ共有**: 標準化されたモジュール形式
- **コミュニティ成長**: パッケージレジストリ基盤
- **言語成熟度**: モダンな言語仕様
---
**🐾 この設計でNyashが真にモダンなプログラミング言語になるにゃ！**

654
docs/development/proposals/nyash.link/bid-using-integration.md Normal file
View File

@ -0,0 +1,654 @@
# BID×usingシステム統合：技術実装詳細
## 🎯 統合設計の核心
### 📊 既存システムとの整合性
- ✅ **MIR ExternCall**: 既にFFI-ABI対応実装済み
- ✅ **WASM RuntimeImports**: BID→WASM自動生成基盤あり
- ✅ **VM ExternStub**: スタブ実行環境実装済み
- 🔧 **統合課題**: usingシステムとBIDの橋渡し実装
### 🚀 統合アーキテクチャ概要
```
User Code (using statements)
↓
UniversalNamespaceRegistry
↓
CallTarget Resolution
↓ ↓ ↓
Builtin FFI-ABI NyashModule
↓ ↓ ↓
MIR Generation (BuiltinCall/ExternCall/ModuleCall)
↓
Backend Execution (VM/WASM/AOT)
```
## 🏗️ 詳細技術実装
### 1. BID定義システム
#### **BIDファイル構造拡張**
```yaml
# apis/enhanced_canvas.yaml
version: 1
metadata:
name: "Enhanced Canvas API"
description: "Extended Canvas API with batch operations"
target_environments: ["browser", "node-canvas", "skia"]
nyash_namespace: "canvas_api" # usingで使用する名前空間
interfaces:
- name: canvas_api.canvas
box: Canvas
methods:
# 基本描画
- name: fillRect
params:
- {string: canvas_id, description: "Canvas element ID"}
- {i32: x, description: "X coordinate"}
- {i32: y, description: "Y coordinate"}
- {i32: width, description: "Rectangle width"}
- {i32: height, description: "Rectangle height"}
- {string: color, description: "Fill color (CSS format)"}
returns: void
effect: io
optimization_hints:
batch_compatible: true # バッチ処理可能
gpu_accelerated: true # GPU加速対応
# バッチ描画（最適化版）
- name: fillRectBatch
params:
- {string: canvas_id}
- {array_of_rect: rects, element_type: "CanvasRect"}
returns: void
effect: io
optimization_hints:
prefer_over: ["fillRect"] # 複数fillRectの代替
min_batch_size: 3
# テキスト描画
- name: fillText
params:
- {string: canvas_id}
- {string: text}
- {i32: x}
- {i32: y}
- {string: font}
- {string: color}
returns: void
effect: io
# カスタム型定義
custom_types:
- name: CanvasRect
fields:
- {i32: x}
- {i32: y}
- {i32: width}
- {i32: height}
- {string: color}
```
#### **BID読み込み・検証システム**
```rust
// 新ファイル: src/bid/mod.rs
use serde::{Deserialize, Serialize};
use std::collections::HashMap;
#[derive(Debug, Clone, Deserialize, Serialize)]
pub struct BidDefinition {
pub version: u32,
pub metadata: BidMetadata,
pub interfaces: Vec<BidInterface>,
pub custom_types: Option<Vec<BidCustomType>>,
}
#[derive(Debug, Clone, Deserialize, Serialize)]
pub struct BidMetadata {
pub name: String,
pub description: String,
pub target_environments: Vec<String>,
pub nyash_namespace: String, // using文で使用する名前空間名
}
#[derive(Debug, Clone, Deserialize, Serialize)]
pub struct BidInterface {
pub name: String, // "canvas_api.canvas"
pub box_name: String, // "Canvas"
pub methods: Vec<BidMethod>,
}
#[derive(Debug, Clone, Deserialize, Serialize)]
pub struct BidMethod {
pub name: String,
pub params: Vec<BidParam>,
pub returns: BidType,
pub effect: BidEffect,
pub optimization_hints: Option<BidOptimizationHints>,
pub description: Option<String>,
}
#[derive(Debug, Clone, Deserialize, Serialize)]
pub struct BidOptimizationHints {
pub batch_compatible: Option<bool>,
pub gpu_accelerated: Option<bool>,
pub prefer_over: Option<Vec<String>>,
pub min_batch_size: Option<usize>,
}
impl BidDefinition {
pub fn load_from_file(path: &Path) -> Result<Self, BidError> {
let content = std::fs::read_to_string(path)?;
let bid: BidDefinition = serde_yaml::from_str(&content)?;
// バリデーション
bid.validate()?;
Ok(bid)
}
pub fn validate(&self) -> Result<(), BidError> {
// バージョン確認
if self.version > 1 {
return Err(BidError::UnsupportedVersion(self.version));
}
// 名前空間重複チェック
let mut interface_names = HashSet::new();
for interface in &self.interfaces {
if interface_names.contains(&interface.name) {
return Err(BidError::DuplicateInterface(interface.name.clone()));
}
interface_names.insert(interface.name.clone());
}
// パラメータ型確認
for interface in &self.interfaces {
for method in &interface.methods {
for param in &method.params {
self.validate_type(&param.param_type)?;
}
self.validate_type(&method.returns)?;
}
}
Ok(())
}
pub fn resolve_method(&self, box_name: &str, method_name: &str)
-> Option<&BidMethod> {
for interface in &self.interfaces {
// インターフェース名から最後の部分を取得
// "canvas_api.canvas" → "canvas"
let interface_box_name = interface.name.split('.').last().unwrap_or(&interface.name);
if interface_box_name == box_name {
for method in &interface.methods {
if method.name == method_name {
return Some(method);
}
}
}
}
None
}
}
```
### 2. 統合名前空間レジストリ詳細
#### **UniversalNamespaceRegistry実装**
```rust
// src/registry/universal.rs
use crate::stdlib::BuiltinStdlib;
use crate::bid::BidDefinition;
use crate::module::ExternalModule;
use crate::mir::Effect;
pub struct UniversalNamespaceRegistry {
/// 組み込み標準ライブラリ
builtin_stdlib: Arc<BuiltinStdlib>,
/// FFI-ABI定義（BID）
bid_definitions: HashMap<String, Arc<BidDefinition>>,
/// Nyashモジュール（従来）
nyash_modules: HashMap<String, Arc<ExternalModule>>,
/// ファイル別usingコンテキスト
using_contexts: Arc<RwLock<HashMap<String, UsingContext>>>,
/// 最適化情報キャッシュ
optimization_cache: Arc<RwLock<OptimizationCache>>,
}
#[derive(Debug, Clone)]
pub struct UsingContext {
pub file_id: String,
pub builtin_namespaces: Vec<String>, // ["nyashstd"]
pub bid_namespaces: Vec<String>, // ["canvas_api", "console_api"]
pub module_namespaces: Vec<String>, // ["mylib", "utils"]
}
impl UniversalNamespaceRegistry {
pub fn new() -> Self {
UniversalNamespaceRegistry {
builtin_stdlib: Arc::new(BuiltinStdlib::new()),
bid_definitions: HashMap::new(),
nyash_modules: HashMap::new(),
using_contexts: Arc::new(RwLock::new(HashMap::new())),
optimization_cache: Arc::new(RwLock::new(OptimizationCache::new())),
}
}
pub fn load_from_nyash_link(&mut self, nyash_link: &NyashLink)
-> Result<(), RegistryError> {
// BID依存関係読み込み
for (namespace_name, dependency) in &nyash_link.dependencies {
match dependency {
Dependency::Bid { bid_path, .. } => {
let bid = BidDefinition::load_from_file(Path::new(bid_path))?;
self.bid_definitions.insert(namespace_name.clone(), Arc::new(bid));
},
Dependency::Path { path } => {
let module = ExternalModule::load_from_file(Path::new(path))?;
self.nyash_modules.insert(namespace_name.clone(), Arc::new(module));
},
Dependency::Builtin { .. } => {
// 組み込みライブラリは既に初期化済み
},
}
}
Ok(())
}
/// 統合using処理
pub fn process_using(&mut self, namespace_name: &str, file_id: &str)
-> Result<(), RuntimeError> {
let mut contexts = self.using_contexts.write().unwrap();
let context = contexts.entry(file_id.to_string()).or_insert_with(|| {
UsingContext {
file_id: file_id.to_string(),
builtin_namespaces: Vec::new(),
bid_namespaces: Vec::new(),
module_namespaces: Vec::new(),
}
});
// 組み込み標準ライブラリチェック
if self.builtin_stdlib.has_namespace(namespace_name) {
if !context.builtin_namespaces.contains(&namespace_name.to_string()) {
context.builtin_namespaces.push(namespace_name.to_string());
}
return Ok(());
}
// BID定義チェック
if let Some(bid) = self.bid_definitions.get(namespace_name) {
if !context.bid_namespaces.contains(&namespace_name.to_string()) {
context.bid_namespaces.push(namespace_name.to_string());
}
return Ok(());
}
// Nyashモジュールチェック
if let Some(_module) = self.nyash_modules.get(namespace_name) {
if !context.module_namespaces.contains(&namespace_name.to_string()) {
context.module_namespaces.push(namespace_name.to_string());
}
return Ok(());
}
Err(RuntimeError::UndefinedNamespace(namespace_name.to_string()))
}
/// 統合関数解決
pub fn resolve_call(&self, file_id: &str, call_path: &[String])
-> Result<ResolvedCall, RuntimeError> {
if call_path.len() != 2 {
return Err(RuntimeError::InvalidCallPath(call_path.join(".")));
}
let box_name = &call_path[0];
let method_name = &call_path[1];
let contexts = self.using_contexts.read().unwrap();
if let Some(context) = contexts.get(file_id) {
// 1. 組み込み標準ライブラリ解決
for namespace in &context.builtin_namespaces {
if let Some(method) = self.builtin_stdlib.resolve_method(namespace, box_name, method_name) {
return Ok(ResolvedCall::Builtin {
namespace: namespace.clone(),
box_name: box_name.clone(),
method_name: method_name.clone(),
method_info: method,
});
}
}
// 2. BID定義解決
for namespace in &context.bid_namespaces {
if let Some(bid) = self.bid_definitions.get(namespace) {
if let Some(method) = bid.resolve_method(box_name, method_name) {
return Ok(ResolvedCall::BidCall {
namespace: namespace.clone(),
interface_name: format!("{}.{}", namespace, box_name),
method_name: method_name.clone(),
method_info: method.clone(),
bid_definition: bid.clone(),
});
}
}
}
// 3. Nyashモジュール解決
for namespace in &context.module_namespaces {
if let Some(module) = self.nyash_modules.get(namespace) {
if let Some(function) = module.resolve_function(box_name, method_name) {
return Ok(ResolvedCall::ModuleCall {
namespace: namespace.clone(),
module_name: namespace.clone(),
function_name: format!("{}.{}", box_name, method_name),
function_info: function,
});
}
}
}
}
Err(RuntimeError::UndefinedMethod(format!("{}.{}", box_name, method_name)))
}
}
#[derive(Debug, Clone)]
pub enum ResolvedCall {
Builtin {
namespace: String,
box_name: String,
method_name: String,
method_info: BuiltinMethodInfo,
},
BidCall {
namespace: String,
interface_name: String,
method_name: String,
method_info: BidMethod,
bid_definition: Arc<BidDefinition>,
},
ModuleCall {
namespace: String,
module_name: String,
function_name: String,
function_info: ModuleFunctionInfo,
},
}
```
### 3. MIR生成統合
#### **統合MIR Builder**
```rust
// src/mir/builder.rs拡張
impl MirBuilder {
pub fn build_unified_method_call(&mut self, resolved_call: ResolvedCall, args: Vec<ValueId>)
-> Result<Option<ValueId>, MirError> {
match resolved_call {
ResolvedCall::Builtin { method_info, .. } => {
let result = self.new_value_id();
self.emit(MirInstruction::BuiltinCall {
qualified_name: method_info.qualified_name(),
args,
result,
effect: method_info.effect(),
});
Ok(Some(result))
},
ResolvedCall::BidCall { interface_name, method_name, method_info, .. } => {
let result = if method_info.returns == BidType::Void {
None
} else {
Some(self.new_value_id())
};
self.emit(MirInstruction::ExternCall {
interface: interface_name,
method: method_name,
args,
result,
effect: self.bid_effect_to_mir_effect(&method_info.effect),
bid_signature: BidSignature::from_method(&method_info),
});
Ok(result)
},
ResolvedCall::ModuleCall { module_name, function_name, function_info, .. } => {
let result = self.new_value_id();
self.emit(MirInstruction::ModuleCall {
module: module_name,
function: function_name,
args,
result,
effect: Effect::Io, // Nyashモジュールはデフォルトでio
});
Ok(Some(result))
},
}
}
fn bid_effect_to_mir_effect(&self, bid_effect: &BidEffect) -> Effect {
match bid_effect {
BidEffect::Pure => Effect::Pure,
BidEffect::Mut => Effect::Mut,
BidEffect::Io => Effect::Io,
BidEffect::Control => Effect::Control,
}
}
}
```
### 4. バックエンド統合
#### **WASM生成統合**
```rust
// src/backend/wasm/codegen.rs拡張
impl WasmCodegen {
pub fn generate_unified_call(&mut self, instruction: &MirInstruction)
-> Result<(), WasmError> {
match instruction {
MirInstruction::ExternCall { interface, method, args, bid_signature, .. } => {
// BIDから自動生成されたWASM import名
let wasm_import_name = self.bid_to_wasm_import_name(interface, method);
// 引数の型変換・マーシャリング
let marshalled_args = self.marshal_args_for_wasm(args, &bid_signature.params)?;
// WASM関数呼び出し生成
self.emit_call(&wasm_import_name, &marshalled_args)?;
// 戻り値のアンマーシャリング
if bid_signature.returns != BidType::Void {
self.unmarshal_return_value(&bid_signature.returns)?;
}
Ok(())
},
// 他の命令は既存実装
_ => self.generate_instruction_legacy(instruction),
}
}
fn bid_to_wasm_import_name(&self, interface: &str, method: &str) -> String {
// "canvas_api.canvas" + "fillRect" → "canvas_api_canvas_fillRect"
format!("{}_{}", interface.replace(".", "_"), method)
}
fn marshal_args_for_wasm(&mut self, args: &[ValueId], params: &[BidParam])
-> Result<Vec<WasmValue>, WasmError> {
let mut marshalled = Vec::new();
for (i, param) in params.iter().enumerate() {
let arg_value = self.get_value(args[i])?;
match &param.param_type {
BidType::String => {
// 文字列を (ptr, len) にマーシャル
let (ptr, len) = self.string_to_wasm_memory(&arg_value)?;
marshalled.push(WasmValue::I32(ptr));
marshalled.push(WasmValue::I32(len));
},
BidType::I32 => {
marshalled.push(WasmValue::I32(arg_value.to_i32()?));
},
BidType::F64 => {
marshalled.push(WasmValue::F64(arg_value.to_f64()?));
},
// その他の型...
}
}
Ok(marshalled)
}
}
```
#### **VM実行統合**
```rust
// src/backend/vm.rs拡張
impl VmBackend {
pub fn execute_unified_instruction(&mut self, instruction: &MirInstruction)
-> Result<(), VmError> {
match instruction {
MirInstruction::ExternCall { interface, method, args, bid_signature, .. } => {
// VM環境ではスタブまたはネイティブ呼び出し
let evaluated_args = self.evaluate_args(args)?;
if let Some(native_impl) = self.find_native_implementation(interface, method) {
// ネイティブ実装がある場合（例：ファイルI/O）
let result = native_impl.call(evaluated_args, bid_signature)?;
if let Some(result_id) = &instruction.result {
self.set_value(*result_id, result);
}
} else {
// スタブ実装（ログ出力等）
self.execute_stub_call(interface, method, evaluated_args, bid_signature)?;
}
Ok(())
},
// 他の命令は既存実装
_ => self.execute_instruction_legacy(instruction),
}
}
fn find_native_implementation(&self, interface: &str, method: &str)
-> Option<&dyn NativeImplementation> {
// VM環境で利用可能なネイティブ実装を検索
match (interface, method) {
("env.console", "log") => Some(&self.console_impl),
("env.filesystem", "read") => Some(&self.filesystem_impl),
("env.filesystem", "write") => Some(&self.filesystem_impl),
_ => None,
}
}
}
```
## 🧪 統合テスト戦略
### Phase別テスト実装
#### **Phase 0: 基本統合テスト**
```nyash
# test_basic_integration.nyash
using nyashstd
# 組み込み標準ライブラリのみ
assert(string.upper("test") == "TEST")
assert(math.sin(0) == 0)
```
#### **Phase 1: BID統合テスト**
```nyash
# test_bid_integration.nyash
using nyashstd
using console_api
# 組み込み + FFI-ABI
string.upper("hello") # 組み込み
console.log("Testing") # FFI-ABI
```
#### **Phase 2: 完全統合テスト**
```nyash
# test_full_integration.nyash
using nyashstd
using console_api
using mylib
# 3種類すべて
string.upper("test") # 組み込み
console.log("Integration") # FFI-ABI
mylib.process("data") # Nyashモジュール
```
### エラーハンドリングテスト
```nyash
# test_error_handling.nyash
try {
using nonexistent_api
} catch error {
assert(error.type == "UndefinedNamespace")
}
try {
console.nonexistent_method("test")
} catch error {
assert(error.type == "UndefinedMethod")
assert(error.message.contains("Available methods:"))
}
```
## 📊 実装マイルストーン
### ✅ Phase 0完了条件
- [ ] UniversalNamespaceRegistry基盤実装
- [ ] 組み込み標準ライブラリ統合
- [ ] 基本using文処理
- [ ] MIR BuiltinCall生成
### ✅ Phase 1完了条件
- [ ] BID定義読み込み・検証
- [ ] BID→MIR ExternCall統合
- [ ] WASM RuntimeImports自動生成
- [ ] VM スタブ実行
### ✅ Phase 2完了条件
- [ ] Nyashモジュール統合
- [ ] 統合エラーハンドリング
- [ ] 最適化キャッシュ
- [ ] 全バックエンド対応
---
**🎯 この詳細実装により、BIDとusingシステムの完全統合が実現でき、「なんでもAPI計画」の技術基盤が完成するにゃ！🚀🐱**

456
docs/development/proposals/nyash.link/builtin-stdlib-architecture.md Normal file
View File

@ -0,0 +1,456 @@
# 組み込みnyashstd名前空間アーキテクチャ設計
## 🏗️ 技術的実装アーキテクチャ
### 📊 現在のインタープリター構造分析
#### **NyashInterpreter構造**
```rust
pub struct NyashInterpreter {
pub(super) shared: SharedState, // 共有状態
pub(super) local_vars: HashMap<String, SharedNyashBox>,
pub(super) outbox_vars: HashMap<String, SharedNyashBox>,
// その他の制御フロー状態...
}
```
#### **設計判断：SharedStateに組み込み**
- **理由**: 標準ライブラリは不変・全インタープリターで共有可能
- **利点**: メモリ効率、パフォーマンス向上
- **実装**: SharedStateに`builtin_stdlib`フィールド追加
## 🌟 最適化されたアーキテクチャ設計
### 1. SharedState拡張
#### **src/interpreter/core.rs**
```rust
#[derive(Clone)]
pub struct SharedState {
// 既存フィールド...
pub global_vars: Arc<RwLock<HashMap<String, SharedNyashBox>>>,
pub functions: Arc<RwLock<HashMap<String, Function>>>,
pub box_definitions: Arc<RwLock<HashMap<String, Box<UserDefinedBoxDefinition>>>>,
pub loop_counter: Arc<AtomicU64>,
pub included_files: Arc<RwLock<HashSet<String>>>,
// 🌟 新規追加: 組み込み標準ライブラリ
pub builtin_stdlib: Arc<BuiltinStdlib>,
pub using_imports: Arc<RwLock<HashMap<String, UsingContext>>>, // ファイル別インポート管理
}
#[derive(Debug, Clone)]
pub struct UsingContext {
pub imported_namespaces: Vec<String>, // ["nyashstd"]
pub file_id: String, // インポート元ファイル識別
}
```
### 2. BuiltinStdlib効率化設計
#### **新ファイル: src/stdlib/builtin.rs**
```rust
//! 🚀 高性能組み込み標準ライブラリ
//!
//! 設計方針:
//! - Zero-allocation関数実行
//! - 高速名前解決
//! - 既存Box実装の最大活用
use crate::boxes::*;
use std::collections::HashMap;
/// 組み込み標準ライブラリのメイン構造体
#[derive(Debug)]
pub struct BuiltinStdlib {
/// 高速アクセス用：フラットな関数マップ
/// "string.upper" -> BuiltinFunction
pub flat_functions: HashMap<String, BuiltinFunction>,
/// IDE補完用：階層構造
/// "nyashstd" -> { "string" -> ["upper", "lower", ...] }
pub hierarchical_map: HashMap<String, HashMap<String, Vec<String>>>,
}
/// 組み込み関数の実装
pub struct BuiltinFunction {
pub namespace: &'static str, // "nyashstd"
pub box_name: &'static str, // "string"
pub method_name: &'static str, // "upper"
pub implementation: BuiltinMethodImpl,
pub arg_count: Option<usize>, // None = 可変長
pub description: &'static str, // エラーメッセージ・ヘルプ用
}
/// 高性能関数実装
pub type BuiltinMethodImpl = fn(&[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError>;
impl BuiltinStdlib {
/// 🚀 標準ライブラリ初期化（起動時1回のみ）
pub fn new() -> Self {
let mut stdlib = BuiltinStdlib {
flat_functions: HashMap::new(),
hierarchical_map: HashMap::new(),
};
// 標準関数登録
stdlib.register_all_functions();
stdlib
}
/// ⚡ 高速関数解決
pub fn get_function(&self, qualified_name: &str) -> Option<&BuiltinFunction> {
// "string.upper" で直接アクセス
self.flat_functions.get(qualified_name)
}
/// 🔍 IDE補完用：利用可能関数一覧取得
pub fn get_available_methods(&self, namespace: &str, box_name: &str) -> Option<&Vec<String>> {
self.hierarchical_map.get(namespace)?.get(box_name)
}
/// 📋 全名前空間取得（IDE補完用）
pub fn get_all_namespaces(&self) -> Vec<&String> {
self.hierarchical_map.keys().collect()
}
}
```
### 3. 標準関数実装（高性能版）
#### **文字列関数実装**
```rust
impl BuiltinStdlib {
fn register_all_functions(&mut self) {
// === nyashstd.string.* ===
self.register_function("string.upper", BuiltinFunction {
namespace: "nyashstd",
box_name: "string",
method_name: "upper",
implementation: |args| {
if args.len() != 1 {
return Err(RuntimeError::InvalidArguments(
"string.upper(str) takes exactly 1 argument".to_string()
));
}
// 🚀 既存StringBox実装活用
let input_str = args[0].to_string_box().value;
let result = StringBox::new(&input_str.to_uppercase());
Ok(Box::new(result))
},
arg_count: Some(1),
description: "Convert string to uppercase",
});
self.register_function("string.lower", BuiltinFunction {
namespace: "nyashstd",
box_name: "string",
method_name: "lower",
implementation: |args| {
if args.len() != 1 {
return Err(RuntimeError::InvalidArguments(
"string.lower(str) takes exactly 1 argument".to_string()
));
}
let input_str = args[0].to_string_box().value;
let result = StringBox::new(&input_str.to_lowercase());
Ok(Box::new(result))
},
arg_count: Some(1),
description: "Convert string to lowercase",
});
self.register_function("string.split", BuiltinFunction {
namespace: "nyashstd",
box_name: "string",
method_name: "split",
implementation: |args| {
if args.len() != 2 {
return Err(RuntimeError::InvalidArguments(
"string.split(str, separator) takes exactly 2 arguments".to_string()
));
}
// 🚀 既存StringBox.split()メソッド活用
let string_box = StringBox::new(&args[0].to_string_box().value);
let separator = &args[1].to_string_box().value;
string_box.split(separator)
},
arg_count: Some(2),
description: "Split string by separator into array",
});
// === nyashstd.math.* ===
self.register_function("math.sin", BuiltinFunction {
namespace: "nyashstd",
box_name: "math",
method_name: "sin",
implementation: |args| {
if args.len() != 1 {
return Err(RuntimeError::InvalidArguments(
"math.sin(x) takes exactly 1 argument".to_string()
));
}
// 🚀 既存MathBox実装活用
let math_box = MathBox::new();
let x = args[0].to_integer_box().value as f64;
let result = math_box.sin(x)?;
Ok(result)
},
arg_count: Some(1),
description: "Calculate sine of x (in radians)",
});
// 階層マップも同時構築
self.build_hierarchical_map();
}
fn register_function(&mut self, qualified_name: &str, function: BuiltinFunction) {
self.flat_functions.insert(qualified_name.to_string(), function);
}
fn build_hierarchical_map(&mut self) {
for (qualified_name, function) in &self.flat_functions {
let namespace_map = self.hierarchical_map
.entry(function.namespace.to_string())
.or_insert_with(HashMap::new);
let method_list = namespace_map
.entry(function.box_name.to_string())
.or_insert_with(Vec::new);
method_list.push(function.method_name.to_string());
}
// ソートして一貫性確保
for namespace_map in self.hierarchical_map.values_mut() {
for method_list in namespace_map.values_mut() {
method_list.sort();
}
}
}
}
```
### 4. インタープリター統合
#### **NyashInterpreter拡張**
```rust
impl NyashInterpreter {
/// using文実行
pub fn execute_using(&mut self, namespace_name: &str) -> Result<(), RuntimeError> {
// 組み込み名前空間存在チェック
if !self.shared.builtin_stdlib.hierarchical_map.contains_key(namespace_name) {
return Err(RuntimeError::UndefinedNamespace(namespace_name.to_string()));
}
// 現在ファイルのusingコンテキスト更新
let file_id = self.get_current_file_id();
let mut using_imports = self.shared.using_imports.write().unwrap();
let context = using_imports.entry(file_id.clone()).or_insert(UsingContext {
imported_namespaces: Vec::new(),
file_id: file_id.clone(),
});
if !context.imported_namespaces.contains(&namespace_name.to_string()) {
context.imported_namespaces.push(namespace_name.to_string());
}
Ok(())
}
/// ⚡ 高速名前解決：string.upper() → nyashstd.string.upper()
pub fn resolve_qualified_call(&self, path: &[String]) -> Option<String> {
if path.len() != 2 {
return None; // Phase 0では2段階のみ対応
}
let box_name = &path[0];
let method_name = &path[1];
let file_id = self.get_current_file_id();
// 現在ファイルのusingインポート確認
if let Ok(using_imports) = self.shared.using_imports.read() {
if let Some(context) = using_imports.get(&file_id) {
for namespace in &context.imported_namespaces {
let qualified_name = format!("{}.{}", box_name, method_name);
// 実際に関数が存在するかチェック
if self.shared.builtin_stdlib.get_function(&qualified_name).is_some() {
return Some(qualified_name);
}
}
}
}
None
}
/// 🚀 組み込み関数実行
pub fn call_builtin_function(&self, qualified_name: &str, args: Vec<Box<dyn NyashBox>>)
-> Result<Box<dyn NyashBox>, RuntimeError> {
if let Some(function) = self.shared.builtin_stdlib.get_function(qualified_name) {
// 引数数チェック
if let Some(expected_count) = function.arg_count {
if args.len() != expected_count {
return Err(RuntimeError::InvalidArguments(
format!("{}.{}() takes exactly {} arguments, got {}",
function.box_name, function.method_name,
expected_count, args.len())
));
}
}
// 関数実行
(function.implementation)(&args)
} else {
Err(RuntimeError::UndefinedMethod(qualified_name.to_string()))
}
}
}
```
### 5. 式実行統合
#### **src/interpreter/expressions.rs修正**
```rust
impl NyashInterpreter {
pub fn execute_expression(&mut self, node: &ASTNode) -> Result<Box<dyn NyashBox>, RuntimeError> {
match node {
// 既存のケース...
// メソッド呼び出し処理修正
ASTNode::MethodCall { object, method, args, .. } => {
// オブジェクトが単純な識別子かチェック
if let ASTNode::Variable { name: box_name, .. } = object.as_ref() {
// using経由での短縮呼び出しチェック
let path = vec![box_name.clone(), method.clone()];
if let Some(qualified_name) = self.resolve_qualified_call(&path) {
// 引数評価
let evaluated_args = self.evaluate_arguments(args)?;
// 組み込み関数実行
return self.call_builtin_function(&qualified_name, evaluated_args);
}
}
// 既存のメソッド呼び出し処理
// ...
}
// using文実行
ASTNode::UsingStatement { namespace_name, .. } => {
self.execute_using(namespace_name)?;
Ok(Box::new(VoidBox::new()))
}
// 他の既存ケース...
}
}
}
```
## 📊 パフォーマンス特性
### ⚡ 最適化ポイント
#### **1. Zero-Allocation関数解決**
```rust
// ❌ 遅い：毎回文字列生成
let qualified = format!("{}.{}", box_name, method_name);
// ✅ 高速：事前計算済みマップ
if let Some(func) = stdlib.flat_functions.get(&qualified_name) { ... }
```
#### **2. 高速名前解決**
```rust
// O(1)アクセス：HashMap直接ルックアップ
// "string.upper" -> BuiltinFunction
```
#### **3. 既存Box実装活用**
```rust
// 既存の最適化済みStringBox.split()を直接使用
string_box.split(separator) // 新規実装不要
```
## 🧪 テストカバレッジ
### Phase 0必須テスト
#### **基本機能テスト**
```nyash
# test_builtin_stdlib_basic.nyash
using nyashstd
# 文字列操作
assert(string.upper("hello") == "HELLO")
assert(string.lower("WORLD") == "world")
assert(string.split("a,b,c", ",").length() == 3)
# 数学関数
assert(math.sin(0) == 0)
assert(math.cos(0) == 1)
# 配列操作
local arr = [1, 2, 3]
assert(array.length(arr) == 3)
assert(array.get(arr, 1) == 2)
```
#### **エラーハンドリング**
```nyash
# test_builtin_stdlib_errors.nyash
using nyashstd
# 引数数エラー
try {
string.upper("hello", "extra") # 2引数でエラー
assert(false, "Should have thrown error")
} catch e {
assert(e.contains("takes exactly 1 argument"))
}
# 未定義名前空間
try {
using nonexistent
assert(false, "Should have thrown error")
} catch e {
assert(e.contains("UndefinedNamespace"))
}
```
#### **IDE補完サポート**
```rust
// テスト：補完候補取得
let methods = stdlib.get_available_methods("nyashstd", "string");
assert!(methods.unwrap().contains(&"upper".to_string()));
assert!(methods.unwrap().contains(&"lower".to_string()));
```
## 🎯 実装順序
### 🚨 Critical（即時実装）
1. **BuiltinStdlib基盤** - src/stdlib/builtin.rs作成
2. **SharedState統合** - builtin_stdlibフィールド追加
3. **using文パーサー** - ASTNode::UsingStatement
### ⚡ High（今週中）
4. **string関数4種** - upper, lower, split, join
5. **基本テスト** - using nyashstd動作確認
6. **エラーハンドリング** - 適切なエラーメッセージ
### 📝 Medium（来週）
7. **math関数5種** - sin, cos, sqrt, floor, random
8. **array関数4種** - length, get, push, slice
9. **io関数3種** - print, println, debug
---
**⚡ この高性能アーキテクチャで、複雑なファイル依存関係なしに即座に実用的なnamespace/usingが実現できるにゃ！🚀**

394
docs/development/proposals/nyash.link/examples.md Normal file
View File

@ -0,0 +1,394 @@
# nyash.linkシステム使用例
## 🎯 基本的な使用例
### 📁 プロジェクト構造例
```
my-awesome-app/
├── nyash.link # 依存関係定義
├── src/
│ ├── main.nyash # メインファイル
│ ├── models/
│ │ └── user.nyash # ユーザーモデル
│ └── utils/
│ └── helpers.nyash # ヘルパー関数
├── libs/
│ └── custom_lib.nyash # カスタムライブラリ
└── stdlib/
└── nyashstd.nyash # 標準ライブラリ
```
### 📋 nyash.linkファイル例
```toml
[project]
name = "my-awesome-app"
version = "1.0.0"
description = "Everything is Box philosophy in action!"
[dependencies]
# 標準ライブラリ
nyashstd = { path = "./stdlib/nyashstd.nyash" }
# プロジェクト内モジュール
user_model = { path = "./src/models/user.nyash" }
helpers = { path = "./src/utils/helpers.nyash" }
# カスタムライブラリ
custom_lib = { path = "./libs/custom_lib.nyash" }
[search_paths]
stdlib = "./stdlib/"
src = "./src/"
libs = "./libs/"
[build]
entry_point = "./src/main.nyash"
```
## 🌟 実用的なコード例
### 1. 基本的なusing使用
```nyash
# ===== src/main.nyash =====
using nyashstd
using helpers
static box Main {
init { console }
main() {
me.console = new ConsoleBox()
# 標準ライブラリ使用
local text = "hello world"
local upper_text = string.upper(text) # nyashstd.string.upper
me.console.log("Upper: " + upper_text)
# ヘルパー関数使用
local processed = helpers.process_data("sample data")
me.console.log("Processed: " + processed)
# 数学関数
local result = math.sin(3.14159)
me.console.log("Sin: " + result.toString())
}
}
```
### 2. 標準ライブラリ定義例
```nyash
# ===== stdlib/nyashstd.nyash =====
namespace nyashstd {
static box string {
static upper(str) {
local string_box = new StringBox(str)
return string_box.upper()
}
static lower(str) {
local string_box = new StringBox(str)
return string_box.lower()
}
static split(str, separator) {
local string_box = new StringBox(str)
return string_box.split(separator)
}
static join(array, separator) {
local sep_box = new StringBox(separator)
return sep_box.join(array)
}
}
static box math {
static sin(x) {
local math_box = new MathBox()
return math_box.sin(x)
}
static cos(x) {
local math_box = new MathBox()
return math_box.cos(x)
}
static random() {
local random_box = new RandomBox()
return random_box.nextFloat()
}
static floor(x) {
local math_box = new MathBox()
return math_box.floor(x)
}
}
static box io {
static read_file(path) {
local file_box = new FileBox()
return file_box.read(path)
}
static write_file(path, content) {
local file_box = new FileBox()
return file_box.write(path, content)
}
}
}
```
### 3. ヘルパーモジュール例
```nyash
# ===== src/utils/helpers.nyash =====
using nyashstd
static function process_data(data) {
# データ処理のヘルパー
local trimmed = string.trim(data)
local upper = string.upper(trimmed)
return "PROCESSED: " + upper
}
static function calculate_score(points, multiplier) {
local result = points * multiplier
return math.floor(result)
}
static function format_user_name(first, last) {
return string.upper(first) + " " + string.upper(last)
}
```
### 4. モデル定義例
```nyash
# ===== src/models/user.nyash =====
using nyashstd
using helpers
box User {
init { name, email, score }
birth(user_name, user_email) {
me.name = user_name
me.email = user_email
me.score = 0
}
add_points(points) {
me.score = me.score + points
return me.score
}
get_formatted_name() {
local parts = string.split(me.name, " ")
if parts.length() >= 2 {
return helpers.format_user_name(parts.get(0), parts.get(1))
} else {
return string.upper(me.name)
}
}
save_to_file() {
local data = "User: " + me.name + ", Email: " + me.email + ", Score: " + me.score.toString()
local filename = "user_" + string.lower(me.name) + ".txt"
io.write_file(filename, data)
}
}
```
## 🎮 実用アプリケーション例
### 1. シンプルなWebサーバー
```nyash
# ===== web_server.nyash =====
using nyashstd
using custom_lib
static box WebServer {
init { server, port }
birth(server_port) {
me.port = server_port
me.server = new HttpServerBox()
}
start() {
me.server.bind("localhost", me.port)
me.server.on("request", me.handle_request)
local console = new ConsoleBox()
console.log("Server started on port " + me.port.toString())
me.server.listen()
}
handle_request(request, response) {
local url = request.getUrl()
if url == "/" {
local html = io.read_file("./public/index.html")
response.setStatus(200)
response.setHeader("Content-Type", "text/html")
response.send(html)
} else {
response.setStatus(404)
response.send("Not Found")
}
}
}
# メイン実行
local server = new WebServer(3000)
server.start()
```
### 2. データ処理パイプライン
```nyash
# ===== data_processor.nyash =====
using nyashstd
using helpers
static box DataProcessor {
init { input_file, output_file }
birth(input_path, output_path) {
me.input_file = input_path
me.output_file = output_path
}
process() {
# データ読み込み
local raw_data = io.read_file(me.input_file)
local lines = string.split(raw_data, "\n")
# 処理済みデータ配列
local processed_lines = new ArrayBox()
# 各行を処理
local i = 0
loop(i < lines.length()) {
local line = lines.get(i)
local processed = helpers.process_data(line)
processed_lines.push(processed)
i = i + 1
}
# 結果をファイルに保存
local result = string.join(processed_lines, "\n")
io.write_file(me.output_file, result)
return processed_lines.length()
}
}
# メイン処理
local processor = new DataProcessor("input.txt", "output.txt")
local count = processor.process()
local console = new ConsoleBox()
console.log("Processed " + count.toString() + " lines")
```
## 🔧 高度な使用パターン
### 1. 条件付きモジュール読み込み（将来拡張）
```nyash
# 開発環境では詳細ログ、本番環境ではシンプルログ
using nyashstd
static function get_logger() {
local env = os.get_env("NYASH_ENV")
if env == "development" {
using dev_logger
return new dev_logger.DetailLogger()
} else {
using prod_logger
return new prod_logger.SimpleLogger()
}
}
```
### 2. エイリアス使用例（将来拡張）
```nyash
# 長い名前空間のエイリアス
using very.long.namespace.name as short
local result = short.helper_function("data")
# 複数の類似ライブラリ
using json_v1 as json1
using json_v2 as json2
local data1 = json1.parse(input)
local data2 = json2.parse(input)
```
### 3. 部分インポート（将来拡張）
```nyash
# 名前空間全体ではなく特定機能のみ
using nyashstd.string
using nyashstd.math
# これで直接呼び出せる
local result = upper("hello") # string.upper不要
local sin_val = sin(3.14) # math.sin不要
```
## 📊 移行例：既存includeからusingへ
### Before（現在のinclude使用）
```nyash
# ===== 既存のtext_adventure例 =====
include "text_adventure/items.nyash"
include "text_adventure/rooms.nyash"
# アイテム作成
local sword = new Weapon("Sword", 10)
```
### After（新しいusing使用）
```nyash
# ===== nyash.link =====
[dependencies]
game_items = { path = "./text_adventure/items.nyash" }
game_rooms = { path = "./text_adventure/rooms.nyash" }
# ===== main.nyash =====
using game_items
using game_rooms
# アイテム作成（名前空間経由）
local sword = game_items.create_weapon("Sword", 10)
```
## 🎉 期待される開発体験
### IDE補完の改善
```nyash
using nyashstd
# "st" と入力すると...
st → string (補完候補)
# "string." と入力すると...
string. → upper, lower, split, join, trim, ... (全メソッド表示)
```
### エラーメッセージの改善
```nyash
using nyashstd
# 間違った呼び出し
local result = string.uppper("hello") # typo
# エラー:
# Error: Method 'uppper' not found in nyashstd.string
# Did you mean: 'upper'?
# Available methods: upper, lower, split, join, trim
```
---
**🌟 これらの例でnyash.linkシステムの実用性と美しさが伝わるにゃ！🐱**

406
docs/development/proposals/nyash.link/final-implementation-strategy.md Normal file
View File

@ -0,0 +1,406 @@
# 最終実装戦略：標準関数優先namespace/usingシステム
## 🎯 実装戦略まとめ
### 📋 設計完了項目
- ✅ **基本戦略**: nyash.link前の段階的実装
- ✅ **アーキテクチャ**: SharedState統合による高性能設計
- ✅ **標準関数**: 組み込みnyashstd名前空間
- ✅ **実装順序**: Critical → High → Medium
### 🚀 最終実装ロードマップ
## Phase 0: 組み込みnyashstd基盤（1-2週間）
### 🚨 Critical実装（即時）
#### **1. トークナイザー拡張**
```rust
// src/tokenizer.rs
pub enum TokenType {
// 既存...
USING, // using キーワード追加
}
// キーワード認識
fn tokenize_keyword(word: &str) -> TokenType {
match word {
// 既存...
"using" => TokenType::USING,
_ => TokenType::IDENTIFIER(word.to_string()),
}
}
```
#### **2. AST最小拡張**
```rust
// src/ast.rs
pub enum ASTNode {
// 既存...
UsingStatement {
namespace_name: String, // Phase 0: "nyashstd"のみ
span: Span,
},
}
```
#### **3. BuiltinStdlib基盤**
```rust
// 新ファイル: src/stdlib/mod.rs
pub mod builtin;
pub use builtin::*;
// 新ファイル: src/stdlib/builtin.rs
// （前回設計したBuiltinStdlib実装）
```
#### **4. SharedState統合**
```rust
// src/interpreter/core.rs
#[derive(Clone)]
pub struct SharedState {
// 既存フィールド...
pub builtin_stdlib: Arc<BuiltinStdlib>,
pub using_imports: Arc<RwLock<HashMap<String, UsingContext>>>,
}
impl SharedState {
pub fn new() -> Self {
SharedState {
// 既存初期化...
builtin_stdlib: Arc::new(BuiltinStdlib::new()),
using_imports: Arc::new(RwLock::new(HashMap::new())),
}
}
}
```
### ⚡ High実装（今週中）
#### **5. using文パーサー**
```rust
// src/parser/statements.rs
impl NyashParser {
pub fn parse_statement(&mut self) -> Result<ASTNode, ParseError> {
match &self.current_token().token_type {
// 既存ケース...
TokenType::USING => self.parse_using(),
// 他の既存ケース...
}
}
fn parse_using(&mut self) -> Result<ASTNode, ParseError> {
let start_span = self.current_token().span.clone();
self.advance(); // consume 'using'
if let TokenType::IDENTIFIER(namespace_name) = &self.current_token().token_type {
let name = namespace_name.clone();
self.advance();
// Phase 0制限：nyashstdのみ許可
if name != "nyashstd" {
return Err(ParseError::UnsupportedFeature(
format!("Only 'nyashstd' namespace is supported in Phase 0, got '{}'", name)
));
}
Ok(ASTNode::UsingStatement {
namespace_name: name,
span: start_span,
})
} else {
Err(ParseError::ExpectedIdentifier(
"Expected namespace name after 'using'".to_string()
))
}
}
}
```
#### **6. 基本string関数実装**
```rust
// src/stdlib/builtin.rs拡張
impl BuiltinStdlib {
fn register_string_functions(&mut self) {
// string.upper
self.register_function("string.upper", BuiltinFunction {
namespace: "nyashstd",
box_name: "string",
method_name: "upper",
implementation: |args| {
if args.len() != 1 {
return Err(RuntimeError::InvalidArguments(
"string.upper() takes exactly 1 argument".to_string()
));
}
let input = &args[0].to_string_box().value;
let result = StringBox::new(&input.to_uppercase());
Ok(Box::new(result))
},
arg_count: Some(1),
description: "Convert string to uppercase",
});
// string.lower
self.register_function("string.lower", BuiltinFunction {
namespace: "nyashstd",
box_name: "string",
method_name: "lower",
implementation: |args| {
if args.len() != 1 {
return Err(RuntimeError::InvalidArguments(
"string.lower() takes exactly 1 argument".to_string()
));
}
let input = &args[0].to_string_box().value;
let result = StringBox::new(&input.to_lowercase());
Ok(Box::new(result))
},
arg_count: Some(1),
description: "Convert string to lowercase",
});
// string.split
self.register_function("string.split", BuiltinFunction {
namespace: "nyashstd",
box_name: "string",
method_name: "split",
implementation: |args| {
if args.len() != 2 {
return Err(RuntimeError::InvalidArguments(
"string.split() takes exactly 2 arguments".to_string()
));
}
let string_box = StringBox::new(&args[0].to_string_box().value);
let separator = &args[1].to_string_box().value;
string_box.split(separator)
},
arg_count: Some(2),
description: "Split string by separator",
});
// string.join
self.register_function("string.join", BuiltinFunction {
namespace: "nyashstd",
box_name: "string",
method_name: "join",
implementation: |args| {
if args.len() != 2 {
return Err(RuntimeError::InvalidArguments(
"string.join() takes exactly 2 arguments".to_string()
));
}
let array_arg = &args[0];
let separator = &args[1].to_string_box().value;
let separator_box = StringBox::new(separator);
separator_box.join(array_arg.clone())
},
arg_count: Some(2),
description: "Join array elements with separator",
});
}
}
```
#### **7. インタープリター統合**
```rust
// src/interpreter/expressions.rs
impl NyashInterpreter {
pub fn execute_expression(&mut self, node: &ASTNode) -> Result<Box<dyn NyashBox>, RuntimeError> {
match node {
// using文処理
ASTNode::UsingStatement { namespace_name, .. } => {
self.execute_using(namespace_name)?;
Ok(Box::new(VoidBox::new()))
}
// メソッド呼び出し処理拡張
ASTNode::MethodCall { object, method, args, .. } => {
// 組み込み関数チェック
if let ASTNode::Variable { name: box_name, .. } = object.as_ref() {
let path = vec![box_name.clone(), method.clone()];
if let Some(qualified_name) = self.resolve_qualified_call(&path) {
let evaluated_args = self.evaluate_arguments(args)?;
return self.call_builtin_function(&qualified_name, evaluated_args);
}
}
// 既存のメソッド呼び出し処理
// ...
}
// 既存の他のケース...
}
}
}
```
### 📝 Medium実装（来週）
#### **8. math関数実装**
```rust
// math.sin, cos, sqrt, floor, random
```
#### **9. array関数実装**
```rust
// array.length, get, push, slice
```
#### **10. io関数実装**
```rust
// io.print, println, debug
```
## Phase 1: 拡張機能（2-3週間後）
### 🌟 完全修飾名対応
```nyash
# using不要でも使える
nyashstd.string.upper("hello")
nyashstd.math.sin(3.14)
```
#### **実装**
```rust
// ASTNode::QualifiedCall追加
ASTNode::QualifiedCall {
path: Vec<String>, // ["nyashstd", "string", "upper"]
args: Vec<ASTNode>,
span: Span,
}
// パーサーで "identifier.identifier.identifier()" 構文解析
```
### 🔧 エラーハンドリング強化
```rust
// より詳細なエラーメッセージ
RuntimeError::UndefinedBuiltinMethod {
namespace: String,
box_name: String,
method_name: String,
available_methods: Vec<String>, // "Did you mean: ..."
span: Span,
}
```
### 📊 IDE補完サポート
```rust
// Language Server連携用API
impl BuiltinStdlib {
pub fn get_completion_candidates(&self, prefix: &str) -> Vec<CompletionItem> {
// "ny" -> ["nyashstd"]
// "nyashstd." -> ["string", "math", "array", "io"]
// "nyashstd.string." -> ["upper", "lower", "split", "join"]
}
}
```
## Phase 2: nyash.link準備（1ヶ月後）
### 🔗 外部モジュール対応基盤
```rust
// ModuleResolver拡張
pub enum NamespaceSource {
Builtin(Arc<BuiltinStdlib>), // 組み込み
External(PathBuf), // nyash.linkで管理
}
// NamespaceRegistry統合
pub struct NamespaceRegistry {
builtin: Arc<BuiltinStdlib>,
external: HashMap<String, ExternalModule>,
}
```
### 📁 nyash.link対応
```toml
[dependencies]
mylib = { path = "./mylib.nyash" }
# using mylib # Phase 2で対応
```
## 🧪 段階的テスト戦略
### Phase 0テスト
```nyash
# test_phase0_basic.nyash
using nyashstd
# 基本動作
assert(string.upper("hello") == "HELLO")
assert(string.lower("WORLD") == "world")
# エラー処理
try {
using unknown_namespace
} catch e {
assert(e.contains("nyashstd"))
}
```
### Phase 1テスト
```nyash
# test_phase1_qualified.nyash
# using不要のテスト
assert(nyashstd.string.upper("hello") == "HELLO")
assert(nyashstd.math.sin(0) == 0)
```
### Phase 2テスト
```nyash
# test_phase2_external.nyash
using mylib
assert(mylib.custom.process("data") == "processed: data")
```
## 📊 実装マイルストーン
### ✅ Phase 0完了条件
- [ ] USINGトークン認識
- [ ] using nyashstd構文解析
- [ ] 組み込みstring関数4種動作
- [ ] 基本テスト全通過
- [ ] エラーハンドリング適切
### ✅ Phase 1完了条件
- [ ] 完全修飾名 nyashstd.string.upper() 動作
- [ ] math/array/io関数実装
- [ ] IDE補完候補API実装
- [ ] 詳細エラーメッセージ
### ✅ Phase 2完了条件
- [ ] 外部モジュール基盤実装
- [ ] nyash.link基本対応
- [ ] 依存関係解決機能
- [ ] 全機能統合テスト
## 🔥 即座に開始すべき実装
### 今日やること
1. **src/stdlib/mod.rs作成** - モジュール基盤
2. **TokenType::USING追加** - トークナイザー拡張
3. **BuiltinStdlib::new()実装** - 空の基盤作成
### 今週やること
4. **using文パーサー実装** - 基本構文解析
5. **string.upper()実装** - 最初の関数
6. **基本テスト作成** - 動作確認
### 来週やること
7. **string関数完成** - lower, split, join
8. **math関数開始** - sin, cos, sqrt
9. **IDE補完設計** - Language Server準備
---
**🎯 この段階的戦略で、複雑なnyash.linkなしに即座に実用的なnamespace/usingシステムが実現できるにゃ！**
**🚀 Phase 0実装を今すぐ開始して、Nyashをモダンなプログラミング言語に進化させよう！🐱✨**

471
docs/development/proposals/nyash.link/implementation-plan.md Normal file
View File

@ -0,0 +1,471 @@
# nyash.linkシステム実装計画
## 🎯 実装戦略
### 📊 現状確認
- ✅ **include**: 限定的使用（text_adventure例のみ）→廃止OK
- ✅ **using**: 未実装→完全新規作成
- ✅ **namespace**: 設計完了→実装のみ
- ✅ **Gemini推奨**: 技術的妥当性確認済み
## 📋 段階的実装ロードマップ
### 🚀 **Phase 1: 基盤構築（1-2週間）**
#### 1.1 トークナイザー拡張
```rust
// src/tokenizer.rs
pub enum TokenType {
// 既存...
USING, // using キーワード
NAMESPACE, // namespace キーワード
AS, // as キーワード（将来のエイリアス用）
}
// キーワード認識追加
fn tokenize_identifier(input: &str) -> TokenType {
match input {
// 既存...
"using" => TokenType::USING,
"namespace" => TokenType::NAMESPACE,
"as" => TokenType::AS,
_ => TokenType::IDENTIFIER(input.to_string()),
}
}
```
#### 1.2 AST拡張
```rust
// src/ast.rs
pub enum ASTNode {
// 既存...
UsingStatement {
module_path: Vec<String>, // ["nyashstd"] or ["mylib"]
alias: Option<String>, // using mylib as lib
span: Span,
},
NamespaceDeclaration {
name: String,
body: Vec<ASTNode>,
span: Span,
},
QualifiedCall {
path: Vec<String>, // ["nyashstd", "string", "upper"]
args: Vec<ASTNode>,
span: Span,
},
}
```
#### 1.3 パーサー基本実装
```rust
// src/parser/statements.rs
impl NyashParser {
pub fn parse_using(&mut self) -> Result<ASTNode, ParseError> {
self.advance(); // consume 'using'
let module_path = self.parse_module_path()?;
// using mylib → ["mylib"]
// using nyashstd.string → ["nyashstd", "string"]
Ok(ASTNode::UsingStatement {
module_path,
alias: None, // Phase 1では未サポート
span: self.current_span(),
})
}
fn parse_module_path(&mut self) -> Result<Vec<String>, ParseError> {
let mut path = vec![];
// 最初の識別子
if let TokenType::IDENTIFIER(name) = &self.current_token().token_type {
path.push(name.clone());
self.advance();
} else {
return Err(ParseError::ExpectedIdentifier);
}
// ドット区切りで追加パス（将来拡張）
// using nyashstd.string のような構文
Ok(path)
}
}
```
### ⚡ **Phase 2: nyash.link基盤（2-3週間）**
#### 2.1 nyash.linkパーサー
```rust
// 新ファイル: src/link_file.rs
use serde::{Deserialize, Serialize};
use std::collections::HashMap;
#[derive(Debug, Deserialize, Serialize)]
pub struct NyashLink {
pub project: Option<ProjectInfo>,
pub dependencies: HashMap<String, Dependency>,
pub search_paths: Option<HashMap<String, String>>,
pub build: Option<BuildConfig>,
}
#[derive(Debug, Deserialize, Serialize)]
pub struct ProjectInfo {
pub name: String,
pub version: String,
pub description: Option<String>,
}
#[derive(Debug, Deserialize, Serialize)]
#[serde(untagged)]
pub enum Dependency {
Path { path: String },
Stdlib { stdlib: bool },
Registry { version: String, registry: String },
}
#[derive(Debug, Deserialize, Serialize)]
pub struct BuildConfig {
pub entry_point: Option<String>,
}
impl NyashLink {
pub fn from_file(path: &Path) -> Result<Self, LinkError> {
let content = std::fs::read_to_string(path)?;
let link: NyashLink = toml::from_str(&content)?;
Ok(link)
}
pub fn resolve_dependency(&self, name: &str) -> Option<PathBuf> {
if let Some(dep) = self.dependencies.get(name) {
match dep {
Dependency::Path { path } => Some(PathBuf::from(path)),
Dependency::Stdlib { .. } => {
// 標準ライブラリパス解決ロジック
self.resolve_stdlib_path(name)
}
_ => None, // Phase 2では未サポート
}
} else {
None
}
}
}
```
#### 2.2 依存関係解決エンジン
```rust
// 新ファイル: src/module_resolver.rs
pub struct ModuleResolver {
nyash_link: NyashLink,
loaded_modules: HashMap<String, Arc<ParsedModule>>,
loading_stack: Vec<String>, // 循環依存検出用
}
impl ModuleResolver {
pub fn new(link_path: &Path) -> Result<Self, ResolverError> {
let nyash_link = NyashLink::from_file(link_path)?;
Ok(ModuleResolver {
nyash_link,
loaded_modules: HashMap::new(),
loading_stack: Vec::new(),
})
}
pub fn resolve_using(&mut self, module_name: &str) -> Result<Arc<ParsedModule>, ResolverError> {
// 既にロード済みかチェック
if let Some(module) = self.loaded_modules.get(module_name) {
return Ok(module.clone());
}
// 循環依存チェック
if self.loading_stack.contains(&module_name.to_string()) {
return Err(ResolverError::CircularDependency(
self.loading_stack.clone()
));
}
// ファイルパス解決
let file_path = self.nyash_link.resolve_dependency(module_name)
.ok_or(ResolverError::ModuleNotFound(module_name.to_string()))?;
// 再帰的読み込み防止
self.loading_stack.push(module_name.to_string());
// ファイル読み込み・パース
let content = std::fs::read_to_string(&file_path)?;
let ast = NyashParser::parse_from_string(&content)?;
// モジュール作成
let module = Arc::new(ParsedModule {
name: module_name.to_string(),
file_path,
ast,
exports: self.extract_exports(&ast)?,
});
// キャッシュに保存
self.loaded_modules.insert(module_name.to_string(), module.clone());
self.loading_stack.pop();
Ok(module)
}
}
```
### 📈 **Phase 3: 名前空間システム（3-4週間）**
#### 3.1 namespace解析
```rust
impl NyashParser {
pub fn parse_namespace(&mut self) -> Result<ASTNode, ParseError> {
self.advance(); // consume 'namespace'
let name = self.expect_identifier()?;
self.expect_token(TokenType::LBRACE)?;
let mut body = vec![];
while !self.check_token(&TokenType::RBRACE) {
body.push(self.parse_statement()?);
}
self.expect_token(TokenType::RBRACE)?;
Ok(ASTNode::NamespaceDeclaration {
name,
body,
span: self.current_span(),
})
}
}
```
#### 3.2 名前空間レジストリ
```rust
// 新ファイル: src/namespace_registry.rs
pub struct NamespaceRegistry {
namespaces: HashMap<String, Namespace>,
using_imports: HashMap<String, Vec<String>>, // ファイル別インポート
}
pub struct Namespace {
pub name: String,
pub static_boxes: HashMap<String, StaticBox>,
}
pub struct StaticBox {
pub name: String,
pub static_methods: HashMap<String, MethodSignature>,
}
impl NamespaceRegistry {
pub fn register_namespace(&mut self, name: String, namespace: Namespace) {
self.namespaces.insert(name, namespace);
}
pub fn add_using_import(&mut self, file_id: String, namespace_name: String) {
self.using_imports
.entry(file_id)
.or_insert_with(Vec::new)
.push(namespace_name);
}
pub fn resolve_call(&self, file_id: &str, path: &[String]) -> Option<MethodSignature> {
// 例: string.upper() → nyashstd.string.upper()
if path.len() == 2 {
let box_name = &path[0];
let method_name = &path[1];
// usingでインポートされた名前空間を検索
if let Some(imports) = self.using_imports.get(file_id) {
for namespace_name in imports {
if let Some(namespace) = self.namespaces.get(namespace_name) {
if let Some(static_box) = namespace.static_boxes.get(box_name) {
if let Some(method) = static_box.static_methods.get(method_name) {
return Some(method.clone());
}
}
}
}
}
}
None
}
}
```
### 🎯 **Phase 4: インタープリター統合（4-5週間）**
#### 4.1 using文実行
```rust
// src/interpreter/core.rs
impl NyashInterpreter {
pub fn execute_using(&mut self, module_path: &[String]) -> Result<(), RuntimeError> {
let module_name = module_path.join(".");
// モジュール解決・読み込み
let module = self.module_resolver.resolve_using(&module_name)?;
// 名前空間登録
if let Some(namespace) = self.extract_namespace_from_module(&module) {
self.namespace_registry.register_namespace(module_name.clone(), namespace);
self.namespace_registry.add_using_import(
self.current_file_id.clone(),
module_name
);
}
Ok(())
}
fn extract_namespace_from_module(&self, module: &ParsedModule) -> Option<Namespace> {
// ASTからnamespace宣言を探して解析
for node in &module.ast {
if let ASTNode::NamespaceDeclaration { name, body, .. } = node {
return Some(self.build_namespace_from_body(name, body));
}
}
None
}
}
```
#### 4.2 qualified call実行
```rust
impl NyashInterpreter {
pub fn execute_qualified_call(&mut self, path: &[String], args: &[ASTNode])
-> Result<Box<dyn NyashBox>, RuntimeError> {
// 名前解決
if let Some(method_sig) = self.namespace_registry.resolve_call(
&self.current_file_id,
path
) {
// 引数評価
let evaluated_args = self.evaluate_args(args)?;
// メソッド実行（既存のBox呼び出しシステム活用）
return self.call_static_method(&method_sig, evaluated_args);
}
// 完全修飾名として試行
if path.len() >= 3 {
// nyashstd.string.upper() の場合
let namespace_name = &path[0];
let box_name = &path[1];
let method_name = &path[2];
if let Some(namespace) = self.namespace_registry.namespaces.get(namespace_name) {
if let Some(static_box) = namespace.static_boxes.get(box_name) {
if let Some(method) = static_box.static_methods.get(method_name) {
let evaluated_args = self.evaluate_args(args)?;
return self.call_static_method(method, evaluated_args);
}
}
}
}
Err(RuntimeError::UndefinedMethod(path.join(".")))
}
}
```
## 🧪 テスト戦略
### Phase 1テスト
```nyash
# test_basic_using.nyash
# 基本using文テスト
# ファイル: mylib.nyash
static function hello() {
return "Hello from mylib!"
}
# ファイル: main.nyash
using mylib
local result = mylib.hello()
assert(result == "Hello from mylib!")
```
### Phase 2テスト
```nyash
# test_nyash_link.nyash
# nyash.linkファイル連携テスト
# nyash.link内容:
# [dependencies]
# mylib = { path = "./mylib.nyash" }
using mylib
local result = mylib.process("data")
assert(result == "processed: data")
```
### Phase 3テスト
```nyash
# test_namespace.nyash
# 名前空間システムテスト
# nyashstd.nyash:
# namespace nyashstd {
# static box string {
# static upper(str) { ... }
# }
# }
using nyashstd
local result = string.upper("hello")
assert(result == "HELLO")
# 完全修飾名
local result2 = nyashstd.string.upper("world")
assert(result2 == "WORLD")
```
## 📊 実装マイルストーン
### ✅ 完了条件
#### Phase 1
- [ ] USING/NAMESPACE トークン認識
- [ ] using文AST構築
- [ ] 基本パーサーテスト通過
#### Phase 2
- [ ] nyash.linkファイル読み込み
- [ ] 依存関係解決
- [ ] モジュールキャッシュ機能
#### Phase 3
- [ ] namespace宣言解析
- [ ] 名前空間レジストリ動作
- [ ] 静的メソッド解決
#### Phase 4
- [ ] インタープリター統合
- [ ] qualified call実行
- [ ] 全テストケース通過
## 🔮 将来拡張
### Phase 5: 高度機能
- エイリアス（`using mylib as lib`）
- 選択インポート（`using nyashstd.string`）
- 動的モジュール読み込み
### Phase 6: 標準ライブラリ
- nyashstd.nyash完全実装
- string/math/io/http モジュール
- ドキュメント生成
### Phase 7: エコシステム
- パッケージレジストリ設計
- CLI ツール（nyash init/install）
- IDE Language Server連携
---
**🎯 この実装計画でnyash.linkシステムを段階的に完成させるにゃ！**

372
docs/development/proposals/nyash.link/master-architecture.md Normal file
View File

@ -0,0 +1,372 @@
# なんでもAPI計画：最終統合アーキテクチャ
## 🌟 革命的ビジョンの実現
### 📊 統合設計完了状況
- ✅ **nyash.link基盤**: 依存関係管理システム設計完了
- ✅ **FFI-ABI統合**: BID×MIR×バックエンド統合設計完了
- ✅ **usingシステム**: 3種類API統一インポート設計完了
- ✅ **実世界例**: ゲーム・データサイエンス・Web・システムプログラミング実証
- 🎯 **最終統合**: 全システム統合による革命的開発体験実現
### 🚀 完成後の開発体験
```nyash
# === たった一つの構文ですべてが使える ===
using nyashstd # 組み込み標準ライブラリ
using browser_api # ブラウザAPI（Canvas, DOM, WebAudio...）
using system_api # システムAPI（libc, filesystem, network...）
using ml_api # 機械学習（TensorFlow, PyTorch, OpenCV...）
using game_api # ゲーム開発（SDL, OpenGL, Vulkan...）
using mylib # 自作Nyashモジュール
# 全部同じ記法・同じパフォーマンス・同じエラーハンドリング！
string.upper("hello") # 組み込み標準
browser.canvas.fillRect("game", 10, 10, 100, 100, "red") # ブラウザAPI
system.file.read("/etc/passwd") # システムAPI
ml.opencv.loadImage("photo.jpg") # 機械学習API
game.sdl.createWindow("Game", 800, 600) # ゲームAPI
mylib.processData("input") # 自作モジュール
```
## 🏗️ 最終統合アーキテクチャ
### 1. 全体システム構成
```
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Nyash Code │ │ nyash.link │ │ BID Files │
│ │ │ │ │ │
│ using browser_api│ │ [dependencies] │ │ browser_api: │
│ using system_api │───▶│ browser_api = │───▶│ canvas.yaml │
│ using mylib │ │ {bid=...} │ │ dom.yaml │
│ canvas.fillRect │ │ system_api = │ │ system_api: │
│ file.read │ │ {bid=...} │ │ libc.yaml │
│ mylib.process │ │ mylib = {path} │ │ filesystem.yaml│
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
└────────────────────────┼────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ UniversalNamespaceRegistry │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │BuiltinStdlib│ │BidDefinition│ │ExternalModules │ │
│ │ │ │ │ │ │ │
│ │nyashstd.* │ │browser_api.*│ │mylib.* │ │
│ │string.upper │ │canvas.fill* │ │custom functions │ │
│ │math.sin │ │dom.events │ │ │ │
│ │array.length │ │system.file* │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ MIR Generation │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │BuiltinCall │ │ExternCall │ │ModuleCall │ │
│ │ │ │ │ │ │ │
│ │string.upper │ │canvas.fill* │ │mylib.process │ │
│ │effect:pure │ │effect:io │ │effect:io │ │
│ │optimize:yes │ │gpu_accel:yes│ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Backend Execution │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │ VM │ │ WASM │ │ AOT │ │
│ │ │ │ │ │ │ │
│ │Native Impl │ │RuntimeImport│ │LLVM ExternFunc │ │
│ │Stub Calls │ │Auto-generated│ │Native Libraries │ │
│ │ │ │from BID │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────┘
```
### 2. nyash.link統合仕様（最終版）
```toml
# nyash.link - 全API統一管理設定
[project]
name = "ultimate-nyash-app"
version = "2.0.0"
description = "Everything is accessible through unified APIs"
license = "MIT"
[dependencies]
# === 組み込み標準ライブラリ ===
nyashstd = { builtin = true }
# === ブラウザ・Web API ===
browser_api = {
bid = ["./apis/canvas.yaml", "./apis/dom.yaml", "./apis/webaudio.yaml"],
target_environments = ["browser"]
}
webgl_api = {
bid = "./apis/webgl.yaml",
target_environments = ["browser"]
}
# === システム・OS API ===
system_api = {
bid = ["./apis/libc.yaml", "./apis/filesystem.yaml", "./apis/network.yaml"],
library = "system",
target_environments = ["linux", "macos", "windows"]
}
posix_api = {
bid = "./apis/posix.yaml",
library = "system",
target_environments = ["linux", "macos"]
}
# === 機械学習・データサイエンス ===
ml_api = {
bid = ["./apis/opencv.yaml", "./apis/numpy.yaml"],
library = ["./libs/opencv.so", "./libs/numpy.so"],
target_environments = ["linux", "macos"]
}
tensorflow_api = {
bid = "./apis/tensorflow.yaml",
library = "./libs/tensorflow.so",
optional = true # 環境によってオプション
}
# === ゲーム開発 ===
game_api = {
bid = ["./apis/sdl.yaml", "./apis/opengl.yaml"],
library = ["SDL2", "OpenGL"],
target_environments = ["linux", "macos", "windows"]
}
# === データベース ===
database_api = {
bid = ["./apis/sqlite.yaml", "./apis/postgresql.yaml"],
library = ["sqlite3", "pq"],
}
# === ネットワーク・Web ===
http_api = {
bid = "./apis/http_client.yaml",
library = "curl"
}
# === Nyashモジュール（従来通り） ===
mylib = { path = "./src/mylib.nyash" }
utils = { path = "./src/utils/" }
models = { path = "./src/models.nyash" }
# === 将来の外部パッケージ ===
awesome_lib = {
version = "^1.2.0",
registry = "nyash-pkg",
bid = "auto" # パッケージレジストリから自動取得
}
[build]
entry_point = "./src/main.nyash"
backends = ["vm", "wasm", "aot"]
optimization_level = "release"
[targets]
browser = ["browser_api", "webgl_api"]
desktop = ["system_api", "game_api", "ml_api"]
server = ["system_api", "database_api", "http_api"]
[optimization]
# MIRレベル最適化設定
enable_effect_optimization = true
enable_batch_optimization = true # FFI-ABI呼び出しバッチ化
enable_gpu_acceleration = true
cache_bid_compilation = true
```
### 3. BIDエコシステム（標準API集）
```
nyash-std-apis/ # 標準APIライブラリ
├── browser/
│ ├── canvas.yaml # Canvas API
│ ├── dom.yaml # DOM API
│ ├── webaudio.yaml # Web Audio API
│ ├── webgl.yaml # WebGL API
│ └── fetch.yaml # Fetch API
├── system/
│ ├── libc.yaml # C標準ライブラリ
│ ├── filesystem.yaml # ファイルシステム
│ ├── network.yaml # ネットワーク
│ ├── process.yaml # プロセス管理
│ └── threads.yaml # スレッド・並行処理
├── ml/
│ ├── opencv.yaml # コンピューターヴィジョン
│ ├── numpy.yaml # 数値計算
│ ├── tensorflow.yaml # 機械学習
│ └── pytorch.yaml # 深層学習
├── game/
│ ├── sdl.yaml # SDL2ライブラリ
│ ├── opengl.yaml # OpenGL API
│ ├── vulkan.yaml # Vulkan API
│ └── physics.yaml # 物理エンジン
├── database/
│ ├── sqlite.yaml # SQLite
│ ├── postgresql.yaml # PostgreSQL
│ ├── mysql.yaml # MySQL
│ └── redis.yaml # Redis
└── crypto/
├── openssl.yaml # OpenSSL
├── libsodium.yaml # libsodium
└── bcrypt.yaml # bcrypt
```
## 🚀 段階的実装戦略（現実的ロードマップ）
### Phase 0: 基盤構築（2-3週間）
```rust
// 🎯 最小実装目標
// using nyashstd → 動作
```
#### **実装内容**
1. **USINGトークナイザー** - `TokenType::USING`追加
2. **基本パーサー** - `using nyashstd`構文解析
3. **BuiltinStdlib基盤** - 組み込み標準ライブラリ
4. **基本string関数** - upper, lower, split, join
#### **テスト**
```nyash
using nyashstd
assert(string.upper("hello") == "HELLO")
```
### Phase 1: BID基盤（4-6週間）
```rust
// 🎯 外部API基盤目標
// using console_api → 動作（VM Stub）
```
#### **実装内容**
1. **BID読み込み** - YAML解析・検証システム
2. **UniversalNamespaceRegistry** - 統合名前空間管理
3. **MIR ExternCall統合** - BID→MIR変換
4. **VM Stub実装** - console.log等の基本スタブ
#### **テスト**
```nyash
using nyashstd
using console_api
string.upper("test")
console.log("BID integration works!")
```
### Phase 2: WASM統合（6-8週間）
```rust
// 🎯 WASM動作目標
// ブラウザでCanvas API動作
```
#### **実装内容**
1. **WASM RuntimeImports自動生成** - BID→WASM import
2. **文字列マーシャリング** - UTF-8 (ptr,len)対応
3. **Canvas API完全実装** - fillRect, fillText等
4. **ブラウザテスト環境** - HTML/JS統合
#### **テスト**
```nyash
using browser_api
canvas.fillRect("game-canvas", 10, 10, 100, 100, "red")
```
### Phase 3: システムAPI統合（8-12週間）
```rust
// 🎯 ネイティブライブラリ動作目標
// ファイルI/O, システムコール等
```
#### **実装内容**
1. **AOTバックエンド統合** - LLVM IR外部関数
2. **システムライブラリ連携** - libc, filesystem等
3. **エラーハンドリング統合** - 統一エラーモデル
4. **パフォーマンス最適化** - バッチ処理・GPU加速
#### **テスト**
```nyash
using system_api
local content = file.read("/etc/passwd")
file.write("./output.txt", content)
```
### Phase 4: 完全エコシステム（12-16週間）
```rust
// 🎯 実用的アプリケーション開発
// ゲーム・ML・Webアプリ等
```
#### **実装内容**
1. **標準APIライブラリ** - nyash-std-apis完成
2. **パッケージレジストリ** - BID共有システム
3. **IDE Language Server** - 統合補完・エラー検出
4. **最適化エンジン** - Effect System活用
#### **実用例**
```nyash
# 本格的なゲーム開発
using game_api
using audio_api
game.sdl.createWindow("My Game", 1024, 768)
audio.mixer.playMusic("bgm.ogg")
```
## 📊 既存実装との整合性
### Phase 9.75eとの関係
```
Phase 9.75e (既存計画) なんでもAPI計画 (新設計)
↓ ↓
namespace構文 using統一構文
依存関係システム → nyash.link統合管理
外部ファイル読み込み → BID統合システム
↓
完全統合アーキテクチャ
```
### 既存MIR/バックエンドとの統合
- ✅ **MIR ExternCall**: 既存実装活用
- ✅ **WASM RuntimeImports**: 既存基盤拡張
- ✅ **VM Backend**: 既存スタブシステム活用
- 🔧 **統合課題**: usingシステムとの橋渡し
## 🌟 長期ビジョン：Nyashの未来
### 2025年目標
- **Phase 0-1完了**: 基盤・BID統合
- **実用アプリ**: シンプルなブラウザゲーム・ツール
- **コミュニティ**: 開発者コミュニティ形成
### 2026年目標
- **Phase 2-3完了**: WASM・システムAPI統合
- **本格アプリ**: ゲーム・データサイエンス・Webアプリ
- **エコシステム**: BIDライブラリエコシステム
### 2027年目標
- **Phase 4完了**: 完全エコシステム
- **産業利用**: 企業での実用的活用
- **言語標準化**: BID標準の業界採用
## 🎯 即座に開始すべき実装
### 今日のアクション
1. **src/stdlib/mod.rs作成** - 組み込み標準ライブラリ基盤
2. **TokenType::USING追加** - トークナイザー拡張
3. **Phase 0実装開始** - using nyashstd基本動作
### 今週のアクション
4. **BuiltinStdlib::new()実装** - string関数4種
5. **基本テスト作成** - using動作確認
6. **Phase 1設計** - BID統合詳細設計
### 来週のアクション
7. **BID読み込み基盤** - YAML解析システム
8. **UniversalNamespaceRegistry** - 統合名前空間管理
9. **console.log実装** - 最初のBID統合テスト
---
**🎉 この最終統合アーキテクチャにより、Nyashが真に「なんでもできる」革命的プログラミング言語になるにゃ！**
**🚀 今すぐPhase 0実装を開始して、プログラミング言語の未来を創造しよう！🐱✨**

435
docs/development/proposals/nyash.link/minimal-stdlib-first.md Normal file
View File

@ -0,0 +1,435 @@
# 最小実装：標準関数優先namespace/usingシステム
## 🎯 基本戦略：nyash.link前の段階的実装
### 📊 現状分析
- **既存Box型**: 25種類以上の豊富なBox実装
- **include使用**: 限定的（text_adventure例のみ）
- **using実装**: 完全未実装→新規作成可能
- **最優先課題**: 複雑なファイル依存関係システムより、まず標準関数のIDE補完
### 🌟 段階的実装アプローチ
#### **Phase 0: 組み込みnyashstd（最小実装）**
```
ファイル読み込み一切なし → インタープリターに直接組み込み
```
#### **Phase 1: using構文**
```nyash
using nyashstd
string.upper("hello") # ✅ 動作
```
#### **Phase 2: 将来のnyash.link対応**
```
外部ファイル・依存関係システム（後日実装）
```
## 🏗️ 組み込みnyashstd設計
### 優先順位別Box分類
#### 🚨 **Tier 1: 最優先基本機能**
```rust
// 使用頻度最高・IDE補完必須
- string_box.rs → nyashstd.string.*
- math_box.rs → nyashstd.math.*
- array/mod.rs → nyashstd.array.*
- console_box.rs → nyashstd.io.*
```
#### ⚡ **Tier 2: 重要機能**
```rust
// 標準的な機能
- time_box.rs → nyashstd.time.*
- random_box.rs → nyashstd.random.*
- map_box.rs → nyashstd.map.*
```
#### 📝 **Tier 3: 特殊用途**
```rust
// 特定用途・後で追加
- debug_box.rs → nyashstd.debug.*
- http_server_box.rs → nyashstd.http.*
- p2p_box.rs → nyashstd.p2p.*
```
### 最小実装スコープ（Phase 0）
#### **nyashstd.string機能**
```nyash
using nyashstd
string.upper("hello") # "HELLO"
string.lower("WORLD") # "world"
string.split("a,b,c", ",") # ["a", "b", "c"]
string.join(["a","b"], "-") # "a-b"
string.length("test") # 4
```
#### **nyashstd.math機能**
```nyash
using nyashstd
math.sin(3.14159) # 0.0 (approximately)
math.cos(0) # 1.0
math.sqrt(16) # 4.0
math.floor(3.7) # 3
math.random() # 0.0-1.0のランダム値
```
#### **nyashstd.array機能**
```nyash
using nyashstd
array.length([1,2,3]) # 3
array.push([1,2], 3) # [1,2,3]
array.get([1,2,3], 1) # 2
array.slice([1,2,3,4], 1, 3) # [2,3]
```
#### **nyashstd.io機能**
```nyash
using nyashstd
io.print("Hello") # コンソール出力
io.println("World") # 改行付き出力
io.debug("Debug info") # デバッグ出力
```
## 💻 技術実装戦略
### 1. インタープリター組み込み方式
#### **新ファイル: `src/stdlib/mod.rs`**
```rust
//! 組み込み標準ライブラリ
//! nyash.linkなしで動作する基本的な標準関数群
use crate::boxes::*;
use std::collections::HashMap;
pub struct BuiltinStdlib {
pub namespaces: HashMap<String, BuiltinNamespace>,
}
pub struct BuiltinNamespace {
pub name: String,
pub static_boxes: HashMap<String, BuiltinStaticBox>,
}
pub struct BuiltinStaticBox {
pub name: String,
pub methods: HashMap<String, BuiltinMethod>,
}
pub type BuiltinMethod = fn(&[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError>;
impl BuiltinStdlib {
pub fn new() -> Self {
let mut stdlib = BuiltinStdlib {
namespaces: HashMap::new(),
};
// nyashstd名前空間登録
stdlib.register_nyashstd();
stdlib
}
fn register_nyashstd(&mut self) {
let mut nyashstd = BuiltinNamespace {
name: "nyashstd".to_string(),
static_boxes: HashMap::new(),
};
// string static box
nyashstd.static_boxes.insert("string".to_string(), self.create_string_box());
// math static box
nyashstd.static_boxes.insert("math".to_string(), self.create_math_box());
// array static box
nyashstd.static_boxes.insert("array".to_string(), self.create_array_box());
// io static box
nyashstd.static_boxes.insert("io".to_string(), self.create_io_box());
self.namespaces.insert("nyashstd".to_string(), nyashstd);
}
}
```
#### **文字列関数実装例**
```rust
impl BuiltinStdlib {
fn create_string_box(&self) -> BuiltinStaticBox {
let mut string_box = BuiltinStaticBox {
name: "string".to_string(),
methods: HashMap::new(),
};
// string.upper(str) -> String
string_box.methods.insert("upper".to_string(), |args| {
if args.len() != 1 {
return Err(RuntimeError::InvalidArguments(
"string.upper() takes exactly 1 argument".to_string()
));
}
let string_arg = args[0].to_string_box();
let result = StringBox::new(&string_arg.value.to_uppercase());
Ok(Box::new(result))
});
// string.lower(str) -> String
string_box.methods.insert("lower".to_string(), |args| {
if args.len() != 1 {
return Err(RuntimeError::InvalidArguments(
"string.lower() takes exactly 1 argument".to_string()
));
}
let string_arg = args[0].to_string_box();
let result = StringBox::new(&string_arg.value.to_lowercase());
Ok(Box::new(result))
});
// string.split(str, separator) -> Array
string_box.methods.insert("split".to_string(), |args| {
if args.len() != 2 {
return Err(RuntimeError::InvalidArguments(
"string.split() takes exactly 2 arguments".to_string()
));
}
let string_arg = args[0].to_string_box();
let sep_arg = args[1].to_string_box();
let string_box = StringBox::new(&string_arg.value);
let result = string_box.split(&sep_arg.value)?;
Ok(result)
});
string_box
}
}
```
### 2. インタープリター統合
#### **インタープリター拡張: `src/interpreter/core.rs`**
```rust
use crate::stdlib::BuiltinStdlib;
pub struct NyashInterpreter {
// 既存フィールド...
pub builtin_stdlib: BuiltinStdlib,
pub using_imports: HashMap<String, Vec<String>>, // ファイル別インポート
}
impl NyashInterpreter {
pub fn new() -> Self {
NyashInterpreter {
// 既存初期化...
builtin_stdlib: BuiltinStdlib::new(),
using_imports: HashMap::new(),
}
}
// using文実行
pub fn execute_using(&mut self, namespace_name: &str) -> Result<(), RuntimeError> {
// 組み込み名前空間かチェック
if self.builtin_stdlib.namespaces.contains_key(namespace_name) {
// 現在ファイルのインポートリストに追加
self.using_imports
.entry(self.current_file_id.clone())
.or_insert_with(Vec::new)
.push(namespace_name.to_string());
Ok(())
} else {
Err(RuntimeError::UndefinedNamespace(namespace_name.to_string()))
}
}
// 短縮名解決: string.upper() -> nyashstd.string.upper()
pub fn resolve_short_call(&self, box_name: &str, method_name: &str)
-> Option<(&str, &str, &str)> { // (namespace, box, method)
if let Some(imports) = self.using_imports.get(&self.current_file_id) {
for namespace_name in imports {
if let Some(namespace) = self.builtin_stdlib.namespaces.get(namespace_name) {
if namespace.static_boxes.contains_key(box_name) {
return Some((namespace_name, box_name, method_name));
}
}
}
}
None
}
// 組み込み関数呼び出し
pub fn call_builtin_method(&self, namespace: &str, box_name: &str, method_name: &str, args: Vec<Box<dyn NyashBox>>)
-> Result<Box<dyn NyashBox>, RuntimeError> {
if let Some(ns) = self.builtin_stdlib.namespaces.get(namespace) {
if let Some(static_box) = ns.static_boxes.get(box_name) {
if let Some(method) = static_box.methods.get(method_name) {
return method(&args);
}
}
}
Err(RuntimeError::UndefinedMethod(
format!("{}.{}.{}", namespace, box_name, method_name)
))
}
}
```
### 3. パーサー最小拡張
#### **トークナイザー: `src/tokenizer.rs`**
```rust
pub enum TokenType {
// 既存...
USING, // using キーワード
// NAMESPACE は後のPhaseで追加
}
```
#### **AST最小拡張: `src/ast.rs`**
```rust
pub enum ASTNode {
// 既存...
UsingStatement {
namespace_name: String, // "nyashstd" のみ対応
span: Span,
},
// QualifiedCall は後のPhaseで追加
}
```
#### **パーサー: `src/parser/statements.rs`**
```rust
impl NyashParser {
pub fn parse_using(&mut self) -> Result<ASTNode, ParseError> {
self.advance(); // consume 'using'
if let TokenType::IDENTIFIER(namespace_name) = &self.current_token().token_type {
let name = namespace_name.clone();
self.advance();
// Phase 0では "nyashstd" のみ許可
if name != "nyashstd" {
return Err(ParseError::UnsupportedNamespace(name));
}
Ok(ASTNode::UsingStatement {
namespace_name: name,
span: self.current_span(),
})
} else {
Err(ParseError::ExpectedIdentifier)
}
}
}
```
## 🧪 テスト戦略
### Phase 0テストケース
#### **基本using文テスト**
```nyash
# test_using_basic.nyash
using nyashstd
local result = string.upper("hello")
assert(result == "HELLO")
local lower = string.lower("WORLD")
assert(lower == "world")
```
#### **数学関数テスト**
```nyash
# test_math_basic.nyash
using nyashstd
local sin_result = math.sin(0)
assert(sin_result == 0)
local sqrt_result = math.sqrt(16)
assert(sqrt_result == 4)
```
#### **配列操作テスト**
```nyash
# test_array_basic.nyash
using nyashstd
local arr = [1, 2, 3]
local length = array.length(arr)
assert(length == 3)
local item = array.get(arr, 1)
assert(item == 2)
```
## 📊 実装マイルストーン
### ✅ Phase 0完了条件
- [ ] USING トークン認識
- [ ] using nyashstd 構文解析
- [ ] 組み込みnyashstd.string実装
- [ ] 組み込みnyashstd.math実装
- [ ] 組み込みnyashstd.array実装
- [ ] 組み込みnyashstd.io実装
- [ ] 基本テストケース全通過
### 🔮 将来の発展
#### **Phase 1: 完全修飾名対応**
```nyash
# using不要でも使える
nyashstd.string.upper("hello")
```
#### **Phase 2: namespace構文対応**
```nyash
# 組み込み以外の名前空間
namespace mylib {
static box utils {
static process(data) { ... }
}
}
```
#### **Phase 3: nyash.link統合**
```toml
# nyash.link
[dependencies]
mylib = { path = "./mylib.nyash" }
```
## 🎯 実装優先順位
### 🚨 Critical（今すぐ）
1. **USINGトークナイザー** - Token::USING追加
2. **using文パーサー** - "using nyashstd"解析
3. **BuiltinStdlib基盤** - src/stdlib/mod.rs作成
### ⚡ High（今週中）
4. **string関数実装** - upper, lower, split, join
5. **math関数実装** - sin, cos, sqrt, floor
6. **基本テスト** - using nyashstd動作確認
### 📝 Medium（来週）
7. **array関数実装** - length, get, push, slice
8. **io関数実装** - print, println, debug
9. **エラーハンドリング** - 適切なエラーメッセージ
---
**🎉 この戦略なら複雑なファイル依存関係システムなしで、すぐに実用的なnamespace/usingが実現できるにゃ！🐱**

625
docs/development/proposals/nyash.link/real-world-examples.md Normal file
View File

@ -0,0 +1,625 @@
# なんでもAPI計画：実世界での具体例
## 🌟 革命的開発体験の実例
### 🎮 ゲーム開発例：Nyashブラウザゲーム
```nyash
# === nyash.link ===
[dependencies]
nyashstd = { builtin = true }
canvas_api = { bid = "./apis/canvas.yaml" }
dom_api = { bid = "./apis/dom.yaml" }
audio_api = { bid = "./apis/webaudio.yaml" }
# === game.nyash ===
using nyashstd
using canvas_api
using dom_api
using audio_api
static box Game {
init { canvas_id, score, player_x, player_y, enemies }
main() {
me.canvas_id = "game-canvas"
me.score = 0
me.player_x = 200
me.player_y = 300
me.enemies = new ArrayBox()
# DOMイベント設定（FFI-ABI経由）
dom.addEventListener("keydown", me.handleKeyDown)
# ゲームループ開始
me.gameLoop()
}
gameLoop() {
loop(true) {
me.update()
me.render()
# ブラウザのrequestAnimationFrame（FFI-ABI）
dom.requestAnimationFrame(me.gameLoop)
}
}
update() {
# 敵の移動（組み込み標準ライブラリ）
local i = 0
loop(i < array.length(me.enemies)) {
local enemy = array.get(me.enemies, i)
enemy.y = enemy.y + enemy.speed
i = i + 1
}
# 当たり判定（組み込み数学関数）
local distance = math.sqrt(
math.pow(me.player_x - enemy.x, 2) +
math.pow(me.player_y - enemy.y, 2)
)
if distance < 30 {
me.gameOver()
}
}
render() {
# 画面クリア（Canvas API - FFI-ABI）
canvas.fillRect(me.canvas_id, 0, 0, 800, 600, "black")
# プレイヤー描画
canvas.fillRect(me.canvas_id, me.player_x, me.player_y, 20, 20, "blue")
# 敵描画
local i = 0
loop(i < array.length(me.enemies)) {
local enemy = array.get(me.enemies, i)
canvas.fillRect(me.canvas_id, enemy.x, enemy.y, 15, 15, "red")
i = i + 1
}
# スコア表示
local score_text = "Score: " + string.toString(me.score)
canvas.fillText(me.canvas_id, score_text, 10, 30, "20px Arial", "white")
}
handleKeyDown(event) {
# キーボード入力処理（DOM API経由）
local key = dom.getEventKey(event)
if key == "ArrowLeft" {
me.player_x = me.player_x - 10
} else if key == "ArrowRight" {
me.player_x = me.player_x + 10
} else if key == " " { # スペースキー
me.shoot()
}
}
shoot() {
# 効果音再生（Web Audio API - FFI-ABI）
audio.playSound("shoot.wav")
# 弾の生成・発射処理
# ...
}
gameOver() {
# ゲームオーバー処理
audio.playSound("gameover.wav")
dom.alert("Game Over! Score: " + string.toString(me.score))
}
}
```
### 🔬 データサイエンス例：画像処理アプリ
```nyash
# === nyash.link ===
[dependencies]
nyashstd = { builtin = true }
opencv_api = { bid = "./apis/opencv.yaml", library = "./libs/opencv.so" }
numpy_api = { bid = "./apis/numpy.yaml", library = "./libs/numpy.so" }
matplotlib_api = { bid = "./apis/matplotlib.yaml", library = "./libs/matplotlib.so" }
file_api = { bid = "./apis/file.yaml" }
# === image_processor.nyash ===
using nyashstd
using opencv_api
using numpy_api
using matplotlib_api
using file_api
static box ImageProcessor {
init { input_path, output_path, processed_data }
main() {
me.input_path = "./images/input.jpg"
me.output_path = "./images/output.jpg"
# 画像読み込み（OpenCV - FFI-ABI）
local image = opencv.imread(me.input_path)
# 前処理
local gray = opencv.cvtColor(image, "BGR2GRAY")
local blurred = opencv.gaussianBlur(gray, 5, 5)
# エッジ検出
local edges = opencv.canny(blurred, 50, 150)
# NumPy配列操作（NumPy - FFI-ABI）
local edge_array = numpy.fromOpenCV(edges)
local normalized = numpy.normalize(edge_array, 0, 255)
# 統計計算（組み込み標準ライブラリ）
local edge_count = me.countEdgePixels(normalized)
local percentage = (edge_count * 100) / (image.width * image.height)
# 結果表示
io.println("Edge pixels: " + string.toString(edge_count))
io.println("Edge percentage: " + string.toString(percentage) + "%")
# 結果画像保存（OpenCV）
opencv.imwrite(me.output_path, edges)
# グラフ生成（Matplotlib - FFI-ABI）
me.generateHistogram(normalized)
}
countEdgePixels(image_array) {
local count = 0
local height = numpy.shape(image_array, 0)
local width = numpy.shape(image_array, 1)
local y = 0
loop(y < height) {
local x = 0
loop(x < width) {
local pixel = numpy.get(image_array, y, x)
if pixel > 0 {
count = count + 1
}
x = x + 1
}
y = y + 1
}
return count
}
generateHistogram(image_array) {
# ヒストグラム計算（NumPy）
local histogram = numpy.histogram(image_array, 256)
# グラフ描画（Matplotlib）
matplotlib.figure(800, 600)
matplotlib.plot(histogram.bins, histogram.values)
matplotlib.title("Edge Pixel Histogram")
matplotlib.xlabel("Pixel Intensity")
matplotlib.ylabel("Frequency")
matplotlib.savefig("./images/histogram.png")
matplotlib.show()
}
}
```
### 🌐 Webサーバー例：RESTful API
```nyash
# === nyash.link ===
[dependencies]
nyashstd = { builtin = true }
http_server_api = { bid = "./apis/http_server.yaml" }
sqlite_api = { bid = "./apis/sqlite.yaml", library = "./libs/sqlite.so" }
json_api = { bid = "./apis/json.yaml" }
crypto_api = { bid = "./apis/crypto.yaml", library = "./libs/openssl.so" }
# === api_server.nyash ===
using nyashstd
using http_server_api
using sqlite_api
using json_api
using crypto_api
static box ApiServer {
init { server, database, port }
main() {
me.port = 8080
me.server = http_server.create()
me.database = sqlite.open("./data/app.db")
# データベース初期化
me.initDatabase()
# ルート設定
http_server.route(me.server, "GET", "/api/users", me.getUsers)
http_server.route(me.server, "POST", "/api/users", me.createUser)
http_server.route(me.server, "PUT", "/api/users/:id", me.updateUser)
http_server.route(me.server, "DELETE", "/api/users/:id", me.deleteUser)
# サーバー開始
io.println("Server starting on port " + string.toString(me.port))
http_server.listen(me.server, me.port)
}
initDatabase() {
local sql = "CREATE TABLE IF NOT EXISTS users (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
email TEXT UNIQUE NOT NULL,
password_hash TEXT NOT NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
)"
sqlite.exec(me.database, sql)
}
getUsers(request, response) {
# クエリ実行（SQLite - FFI-ABI）
local sql = "SELECT id, name, email, created_at FROM users"
local results = sqlite.query(me.database, sql)
# JSON変換（JSON API - FFI-ABI）
local json_response = json.stringify(results)
# レスポンス送信（HTTP Server API）
http_server.setHeader(response, "Content-Type", "application/json")
http_server.setStatus(response, 200)
http_server.send(response, json_response)
}
createUser(request, response) {
# リクエストボディ解析
local body = http_server.getBody(request)
local user_data = json.parse(body)
# バリデーション（組み込み標準ライブラリ）
if string.length(user_data.name) < 2 {
me.sendError(response, 400, "Name must be at least 2 characters")
return
}
if not me.isValidEmail(user_data.email) {
me.sendError(response, 400, "Invalid email format")
return
}
# パスワードハッシュ化（Crypto API - FFI-ABI）
local password_hash = crypto.hashPassword(user_data.password)
# データベース挿入
local sql = "INSERT INTO users (name, email, password_hash) VALUES (?, ?, ?)"
local params = [user_data.name, user_data.email, password_hash]
try {
local user_id = sqlite.insert(me.database, sql, params)
# 作成されたユーザー情報を返す
local created_user = map.create()
map.set(created_user, "id", user_id)
map.set(created_user, "name", user_data.name)
map.set(created_user, "email", user_data.email)
local json_response = json.stringify(created_user)
http_server.setHeader(response, "Content-Type", "application/json")
http_server.setStatus(response, 201)
http_server.send(response, json_response)
} catch error {
io.println("Database error: " + error.message)
me.sendError(response, 500, "Failed to create user")
}
}
isValidEmail(email) {
# 簡単なメール検証（組み込み文字列関数）
local at_pos = string.indexOf(email, "@")
local dot_pos = string.lastIndexOf(email, ".")
return at_pos > 0 and dot_pos > at_pos and dot_pos < string.length(email) - 1
}
sendError(response, status, message) {
local error_obj = map.create()
map.set(error_obj, "error", message)
local json_error = json.stringify(error_obj)
http_server.setHeader(response, "Content-Type", "application/json")
http_server.setStatus(response, status)
http_server.send(response, json_error)
}
}
```
### 🔧 システムプログラミング例：ファイル監視ツール
```nyash
# === nyash.link ===
[dependencies]
nyashstd = { builtin = true }
libc_api = { bid = "./apis/libc.yaml", library = "system" }
inotify_api = { bid = "./apis/inotify.yaml", library = "system" }
filesystem_api = { bid = "./apis/filesystem.yaml" }
# === file_monitor.nyash ===
using nyashstd
using libc_api
using inotify_api
using filesystem_api
static box FileMonitor {
init { watch_path, inotify_fd, watch_descriptors, callbacks }
main() {
me.watch_path = "./watched_directory"
me.watch_descriptors = new ArrayBox()
me.callbacks = map.create()
# inotify初期化（Linux inotify - FFI-ABI）
me.inotify_fd = inotify.init()
if me.inotify_fd < 0 {
io.println("Failed to initialize inotify")
return
}
# ディレクトリ監視設定
me.addWatch(me.watch_path)
# コールバック設定
me.setupCallbacks()
io.println("File monitor started. Watching: " + me.watch_path)
# メインループ
me.eventLoop()
}
addWatch(path) {
# 監視フラグ（inotify constants）
local flags = inotify.IN_CREATE or inotify.IN_DELETE or
inotify.IN_MODIFY or inotify.IN_MOVED_FROM or
inotify.IN_MOVED_TO
local wd = inotify.addWatch(me.inotify_fd, path, flags)
if wd >= 0 {
array.push(me.watch_descriptors, wd)
io.println("Added watch for: " + path)
} else {
io.println("Failed to add watch for: " + path)
}
}
setupCallbacks() {
# ファイル作成コールバック
map.set(me.callbacks, "CREATE", static function(event) {
io.println("File created: " + event.name)
# ファイル情報取得（Filesystem API）
local file_info = filesystem.stat(event.path)
local size = file_info.size
local permissions = file_info.permissions
io.println(" Size: " + string.toString(size) + " bytes")
io.println(" Permissions: " + permissions)
})
# ファイル変更コールバック
map.set(me.callbacks, "MODIFY", static function(event) {
io.println("File modified: " + event.name)
# 変更時刻記録
local timestamp = time.now()
local formatted_time = time.format(timestamp, "%Y-%m-%d %H:%M:%S")
io.println(" Modified at: " + formatted_time)
})
# ファイル削除コールバック
map.set(me.callbacks, "DELETE", static function(event) {
io.println("File deleted: " + event.name)
# ログファイルに記録
me.logEvent("DELETE", event.name, time.now())
})
}
eventLoop() {
local buffer_size = 4096
local buffer = libc.malloc(buffer_size)
loop(true) {
# inotify eventsを読み取り（blocking read）
local bytes_read = libc.read(me.inotify_fd, buffer, buffer_size)
if bytes_read > 0 {
me.processEvents(buffer, bytes_read)
} else if bytes_read == 0 {
# EOF
break
} else {
# エラー
local error_code = libc.errno()
io.println("Read error: " + string.toString(error_code))
break
}
}
libc.free(buffer)
}
processEvents(buffer, bytes_read) {
local offset = 0
loop(offset < bytes_read) {
# inotify_event構造体解析（libc memory operations）
local event = inotify.parseEvent(buffer, offset)
# イベントタイプ判定
local event_type = me.getEventType(event.mask)
# 対応するコールバック実行
if map.has(me.callbacks, event_type) {
local callback = map.get(me.callbacks, event_type)
callback(event)
}
# 次のイベントへ
offset = offset + event.size
}
}
getEventType(mask) {
if mask and inotify.IN_CREATE {
return "CREATE"
} else if mask and inotify.IN_MODIFY {
return "MODIFY"
} else if mask and inotify.IN_DELETE {
return "DELETE"
} else if mask and inotify.IN_MOVED_FROM {
return "MOVE_FROM"
} else if mask and inotify.IN_MOVED_TO {
return "MOVE_TO"
} else {
return "UNKNOWN"
}
}
logEvent(event_type, filename, timestamp) {
local log_entry = time.format(timestamp, "%Y-%m-%d %H:%M:%S") +
" [" + event_type + "] " + filename + "\n"
# ログファイルに追記（Filesystem API）
filesystem.appendFile("./file_monitor.log", log_entry)
}
}
```
## 📊 MIR同時拡張による最適化効果
### 🚀 最適化前後の比較
#### **従来の実装（最適化なし）**
```mir
; 非効率：毎回関数呼び出し
%1 = ExternCall env.canvas.fillRect ["canvas", 10, 10, 100, 100, "red"]
%2 = ExternCall env.canvas.fillRect ["canvas", 110, 10, 100, 100, "blue"]
%3 = ExternCall env.canvas.fillRect ["canvas", 220, 10, 100, 100, "green"]
```
#### **MIR最適化後（バッチ処理）**
```mir
; 効率化：バッチ処理
%rects = ArrayConstruct [
{x: 10, y: 10, w: 100, h: 100, color: "red"},
{x: 110, y: 10, w: 100, h: 100, color: "blue"},
{x: 220, y: 10, w: 100, h: 100, color: "green"}
]
%1 = ExternCall env.canvas.fillRectBatch ["canvas", %rects]
```
#### **Effect Systemによる並列化**
```mir
; pure関数は並列実行可能
%1 = BuiltinCall string.upper ["hello"] ; effect: pure
%2 = BuiltinCall math.sin [3.14] ; effect: pure
%3 = BuiltinCall string.lower ["WORLD"] ; effect: pure
; ↑ これらは並列実行される
%4 = ExternCall env.console.log [%1] ; effect: io
%5 = ExternCall env.console.log [%2] ; effect: io
; ↑ これらは順序保持される
```
### 🎯 バックエンド別最適化
#### **WASM最適化**
```wasm
;; BIDから自動生成された最適化WASM
(func $optimized_canvas_batch
(param $canvas_id i32) (param $canvas_id_len i32)
(param $rects_ptr i32) (param $rect_count i32)
;; ループ展開による高速化
(local $i i32)
(local $rect_ptr i32)
loop $rect_loop
;; 直接メモリアクセス（境界チェック済み）
local.get $rect_ptr
i32.load ;; x
local.get $rect_ptr
i32.load offset=4 ;; y
;; ... 高速描画処理
local.get $rect_ptr
i32.const 20
i32.add
local.set $rect_ptr
local.get $i
i32.const 1
i32.add
local.tee $i
local.get $rect_count
i32.lt_u
br_if $rect_loop
end
)
```
#### **AOT最適化（LLVM IR）**
```llvm
; LLVM IRレベルでの最適化
define void @optimized_image_processing(i8* %image_data, i32 %width, i32 %height) {
entry:
; ベクトル化された画像処理
%0 = bitcast i8* %image_data to <16 x i8>*
; SIMD命令による並列処理
br label %loop.header
loop.header:
%i = phi i32 [ 0, %entry ], [ %i.next, %loop.body ]
%cmp = icmp ult i32 %i, %height
br i1 %cmp, label %loop.body, label %exit
loop.body:
; 16ピクセル同時処理（AVX2/NEON活用）
%pixel_ptr = getelementptr <16 x i8>, <16 x i8>* %0, i32 %i
%pixels = load <16 x i8>, <16 x i8>* %pixel_ptr
; ベクトル化されたエッジ検出
%edges = call <16 x i8> @vectorized_edge_detection(<16 x i8> %pixels)
store <16 x i8> %edges, <16 x i8>* %pixel_ptr
%i.next = add i32 %i, 1
br label %loop.header
exit:
ret void
}
```
## 🌟 革命的効果
### 🚀 開発者体験の向上
- **学習コスト**: 一つの構文ですべてのAPIが使える
- **IDE統合**: 全APIの統一補完・エラー検出
- **デバッグ**: 統一エラーモデルによる一貫したデバッグ体験
### ⚡ パフォーマンス向上
- **MIRレベル最適化**: すべてのAPIで同じ最適化技術
- **Effect System**: 安全な並列化・順序最適化
- **バックエンド最適化**: WASM/AOT固有の最適化
### 🌍 エコシステム拡大
- **ライブラリ統合**: 既存C/Rustライブラリの簡単統合
- **クロスプラットフォーム**: 同じコードが全環境で動作
- **標準化**: BIDによる外部API標準化
---
**🎉 これが「なんでもAPI計画」の真の実力だにゃ！あらゆる開発が統一された美しい構文で実現できるにゃ！🚀🐱**

563
docs/development/proposals/nyash.link/universal-api-integration.md Normal file
View File

@ -0,0 +1,563 @@
# なんでもAPI計画：nyash.link × FFI-ABI × MIR 統合設計
## 🌟 革命的統合ビジョン
### 📊 現状把握
- ✅ **nyash.linkシステム**: 標準関数・モジュール管理設計完了
- ✅ **FFI-ABI仕様**: BID(Box Interface Definition)による外部API統一
- ✅ **MIR ExternCall**: 外部関数呼び出しのMIRレベル実装
- 🎯 **統合目標**: 3つのシステムを統合し「なんでもAPI」を実現
### 🚀 統合後の開発体験
```nyash
# === 単一のusing構文ですべてが使える！ ===
using nyashstd # 組み込み標準ライブラリ
using console_api # ブラウザConsole API (FFI-ABI)
using canvas_api # Canvas API (FFI-ABI)
using opencv_api # OpenCV外部ライブラリ (FFI-ABI)
using mylib # 自作Nyashモジュール
# 全部同じ記法で使える！
string.upper("hello") # 組み込み標準ライブラリ
console.log("Hello Nyash!") # ブラウザAPI
canvas.fillRect("game", 10, 10, 80, 60, "red") # Canvas API
opencv.loadImage("photo.jpg") # 外部ライブラリ
mylib.processData("input") # 自作モジュール
```
## 🏗️ 統合アーキテクチャ設計
### 1. 拡張nyash.link仕様
#### **依存関係タイプの統合**
```toml
# nyash.link - 全API統一管理
[project]
name = "awesome-nyash-app"
version = "1.0.0"
[dependencies]
# === 組み込み標準ライブラリ ===
nyashstd = { builtin = true }
# === FFI-ABI経由外部API ===
console_api = { bid = "./apis/console.yaml" }
canvas_api = { bid = "./apis/canvas.yaml" }
webgl_api = { bid = "./apis/webgl.yaml" }
dom_api = { bid = "./apis/dom.yaml" }
# === システムライブラリ ===
libc = { bid = "./apis/libc.yaml", library = "system" }
math_lib = { bid = "./apis/math.yaml", library = "libm" }
# === 外部共有ライブラリ ===
opencv = { bid = "./apis/opencv.yaml", library = "./libs/opencv.so" }
sqlite = { bid = "./apis/sqlite.yaml", library = "./libs/sqlite.so" }
# === Nyashモジュール（従来通り） ===
mylib = { path = "./src/mylib.nyash" }
utils = { path = "./src/utils.nyash" }
models = { path = "./src/models/" }
# === 将来の外部パッケージ ===
# http_client = { version = "1.0.0", registry = "nyash-pkg" }
[build]
entry_point = "./src/main.nyash"
backends = ["vm", "wasm", "aot"] # 対象バックエンド指定
```
#### **BIDファイル例**
```yaml
# apis/console.yaml - Console API定義
version: 0
metadata:
name: "Browser Console API"
description: "Standard browser console interface"
target_environments: ["browser", "node"]
interfaces:
- name: console_api.console
box: Console
namespace: console_api
methods:
- name: log
params: [ {string: message} ]
returns: void
effect: io
description: "Output message to console"
- name: warn
params: [ {string: message} ]
returns: void
effect: io
- name: error
params: [ {string: message} ]
returns: void
effect: io
# apis/canvas.yaml - Canvas API定義
version: 0
interfaces:
- name: canvas_api.canvas
box: Canvas
namespace: canvas_api
methods:
- name: fillRect
params:
- {string: canvas_id}
- {i32: x}
- {i32: y}
- {i32: width}
- {i32: height}
- {string: color}
returns: void
effect: io
- name: fillText
params:
- {string: canvas_id}
- {string: text}
- {i32: x}
- {i32: y}
- {string: font}
- {string: color}
returns: void
effect: io
```
### 2. 統合名前空間レジストリ
#### **UniversalNamespaceRegistry設計**
```rust
// 新ファイル: src/registry/universal.rs
use crate::stdlib::BuiltinStdlib;
use crate::bid::BidDefinition;
use crate::module::ExternalModule;
pub struct UniversalNamespaceRegistry {
/// 組み込み標準ライブラリ
builtin: Arc<BuiltinStdlib>,
/// FFI-ABI経由の外部API
ffi_apis: HashMap<String, Arc<BidDefinition>>,
/// Nyashモジュール
nyash_modules: HashMap<String, Arc<ExternalModule>>,
/// using imports（ファイル別）
using_imports: Arc<RwLock<HashMap<String, UsingContext>>>,
}
#[derive(Debug, Clone)]
pub struct UsingContext {
pub builtin_imports: Vec<String>, // ["nyashstd"]
pub ffi_imports: Vec<String>, // ["console_api", "canvas_api"]
pub module_imports: Vec<String>, // ["mylib", "utils"]
pub file_id: String,
}
impl UniversalNamespaceRegistry {
pub fn new(nyash_link: &NyashLink) -> Result<Self, RegistryError> {
let mut registry = UniversalNamespaceRegistry {
builtin: Arc::new(BuiltinStdlib::new()),
ffi_apis: HashMap::new(),
nyash_modules: HashMap::new(),
using_imports: Arc::new(RwLock::new(HashMap::new())),
};
// nyash.linkからFFI-ABI定義読み込み
registry.load_ffi_apis(nyash_link)?;
// Nyashモジュール読み込み
registry.load_nyash_modules(nyash_link)?;
Ok(registry)
}
/// 統合using文処理
pub fn execute_using(&mut self, namespace_name: &str, file_id: &str)
-> Result<(), RuntimeError> {
let context = self.using_imports
.write().unwrap()
.entry(file_id.to_string())
.or_insert_with(|| UsingContext {
builtin_imports: Vec::new(),
ffi_imports: Vec::new(),
module_imports: Vec::new(),
file_id: file_id.to_string(),
});
// 組み込み標準ライブラリ
if self.builtin.has_namespace(namespace_name) {
if !context.builtin_imports.contains(&namespace_name.to_string()) {
context.builtin_imports.push(namespace_name.to_string());
}
return Ok(());
}
// FFI-ABI API
if self.ffi_apis.contains_key(namespace_name) {
if !context.ffi_imports.contains(&namespace_name.to_string()) {
context.ffi_imports.push(namespace_name.to_string());
}
return Ok(());
}
// Nyashモジュール
if self.nyash_modules.contains_key(namespace_name) {
if !context.module_imports.contains(&namespace_name.to_string()) {
context.module_imports.push(namespace_name.to_string());
}
return Ok(());
}
Err(RuntimeError::UndefinedNamespace(namespace_name.to_string()))
}
/// 統合関数解決
pub fn resolve_call(&self, file_id: &str, path: &[String])
-> Result<CallTarget, RuntimeError> {
if path.len() != 2 {
return Err(RuntimeError::InvalidQualifiedName(path.join(".")));
}
let box_name = &path[0];
let method_name = &path[1];
if let Ok(imports) = self.using_imports.read() {
if let Some(context) = imports.get(file_id) {
// 1. 組み込み標準ライブラリ検索
for namespace in &context.builtin_imports {
if let Some(target) = self.builtin.resolve_call(namespace, box_name, method_name) {
return Ok(CallTarget::Builtin(target));
}
}
// 2. FFI-ABI API検索
for namespace in &context.ffi_imports {
if let Some(bid) = self.ffi_apis.get(namespace) {
if let Some(target) = bid.resolve_method(box_name, method_name) {
return Ok(CallTarget::FfiAbi(target));
}
}
}
// 3. Nyashモジュール検索
for namespace in &context.module_imports {
if let Some(module) = self.nyash_modules.get(namespace) {
if let Some(target) = module.resolve_method(box_name, method_name) {
return Ok(CallTarget::NyashModule(target));
}
}
}
}
}
Err(RuntimeError::UndefinedMethod(format!("{}.{}", box_name, method_name)))
}
}
#[derive(Debug)]
pub enum CallTarget {
Builtin(BuiltinMethodTarget),
FfiAbi(FfiMethodTarget),
NyashModule(NyashMethodTarget),
}
```
### 3. MIRレベル統合
#### **MIR命令拡張**
```rust
// src/mir/instruction.rs拡張
#[derive(Debug, Clone)]
pub enum MirInstruction {
// 既存命令...
// === 統合関数呼び出し ===
/// 組み込み標準ライブラリ呼び出し
BuiltinCall {
target: String, // "string.upper"
args: Vec<ValueId>,
result: ValueId,
effect: Effect,
},
/// FFI-ABI外部API呼び出し
ExternCall {
interface: String, // "console_api.console"
method: String, // "log"
args: Vec<ValueId>,
result: Option<ValueId>,
effect: Effect,
bid_signature: BidMethodSignature,
},
/// Nyashモジュール関数呼び出し
ModuleCall {
module: String, // "mylib"
function: String, // "processData"
args: Vec<ValueId>,
result: ValueId,
effect: Effect,
},
}
#[derive(Debug, Clone)]
pub enum Effect {
Pure, // 副作用なし、並び替え可能
Mut, // 同リソース内で順序保持
Io, // プログラム順序保持
Control, // 制御フロー影響
}
```
#### **MIR生成統合**
```rust
// src/mir/builder.rs拡張
impl MirBuilder {
pub fn build_unified_call(&mut self, target: CallTarget, args: Vec<ValueId>)
-> Result<ValueId, MirError> {
match target {
CallTarget::Builtin(builtin_target) => {
let result = self.new_value_id();
self.emit(MirInstruction::BuiltinCall {
target: builtin_target.qualified_name(),
args,
result,
effect: builtin_target.effect(),
});
Ok(result)
},
CallTarget::FfiAbi(ffi_target) => {
let result = if ffi_target.returns_void() {
None
} else {
Some(self.new_value_id())
};
self.emit(MirInstruction::ExternCall {
interface: ffi_target.interface_name(),
method: ffi_target.method_name(),
args,
result,
effect: ffi_target.effect(),
bid_signature: ffi_target.signature().clone(),
});
result.ok_or(MirError::VoidReturn)
},
CallTarget::NyashModule(module_target) => {
let result = self.new_value_id();
self.emit(MirInstruction::ModuleCall {
module: module_target.module_name(),
function: module_target.function_name(),
args,
result,
effect: Effect::Io, // デフォルト
});
Ok(result)
},
}
}
}
```
### 4. バックエンド統合実装
#### **VM実行統合**
```rust
// src/backend/vm.rs拡張
impl VmBackend {
pub fn execute_instruction(&mut self, instr: &MirInstruction)
-> Result<(), VmError> {
match instr {
MirInstruction::BuiltinCall { target, args, result, .. } => {
let evaluated_args = self.evaluate_args(args)?;
let output = self.builtin_executor.call(target, evaluated_args)?;
self.set_value(*result, output);
Ok(())
},
MirInstruction::ExternCall { interface, method, args, result, bid_signature, .. } => {
// VM環境ではスタブ実装
let evaluated_args = self.evaluate_args(args)?;
let output = self.extern_stub.call(interface, method, evaluated_args, bid_signature)?;
if let Some(res_id) = result {
self.set_value(*res_id, output);
}
Ok(())
},
MirInstruction::ModuleCall { module, function, args, result, .. } => {
let evaluated_args = self.evaluate_args(args)?;
let output = self.module_executor.call(module, function, evaluated_args)?;
self.set_value(*result, output);
Ok(())
},
// 既存命令処理...
}
}
}
```
#### **WASM生成統合**
```rust
// src/backend/wasm/codegen.rs拡張
impl WasmCodegen {
pub fn generate_instruction(&mut self, instr: &MirInstruction)
-> Result<(), WasmError> {
match instr {
MirInstruction::BuiltinCall { target, args, result, .. } => {
// 組み込み関数は直接実装
self.generate_builtin_call(target, args, *result)
},
MirInstruction::ExternCall { interface, method, args, bid_signature, .. } => {
// BIDから自動生成されたWASM import呼び出し
let import_name = format!("{}_{}",
interface.replace(".", "_"),
method
);
self.generate_extern_call(&import_name, args, bid_signature)
},
MirInstruction::ModuleCall { module, function, args, result, .. } => {
// 内部関数呼び出し
let function_name = format!("{}_{}", module, function);
self.generate_function_call(&function_name, args, *result)
},
}
}
/// BIDからWASM RuntimeImports自動生成
pub fn generate_runtime_imports(&mut self, bid_definitions: &[BidDefinition])
-> Result<String, WasmError> {
let mut imports = String::new();
for bid in bid_definitions {
for interface in &bid.interfaces {
for method in &interface.methods {
let import_name = format!("{}_{}",
interface.name.replace(".", "_"),
method.name
);
let signature = self.bid_to_wasm_signature(&method.params, &method.returns)?;
imports.push_str(&format!(
"(import \"env\" \"{}\" {})\n",
import_name, signature
));
}
}
}
Ok(imports)
}
}
```
#### **AOT生成統合**
```rust
// src/backend/aot/compiler.rs拡張
impl AotCompiler {
pub fn compile_instruction(&mut self, instr: &MirInstruction)
-> Result<(), AotError> {
match instr {
MirInstruction::ExternCall { interface, method, args, bid_signature, .. } => {
// LLVM IR外部関数宣言生成
let extern_func_name = format!("{}_{}",
interface.replace(".", "_"),
method
);
let signature = self.bid_to_llvm_signature(bid_signature)?;
self.declare_external_function(&extern_func_name, &signature)?;
self.generate_call(&extern_func_name, args)?;
Ok(())
},
// その他の命令処理...
}
}
}
```
## 🎯 段階的実装戦略
### Phase 0: 基盤統合（2-3週間）
1. **UniversalNamespaceRegistry実装** - 全API統一管理
2. **nyash.link拡張** - BID依存関係サポート
3. **統合using文** - 3種類のAPI統一インポート
### Phase 1: FFI-ABI統合（3-4週間）
1. **BID読み込み機能** - YAML解析・検証
2. **MIR ExternCall統合** - FFI-ABI→MIR変換
3. **WASM RuntimeImports自動生成** - BID→WASM import
### Phase 2: 完全統合（4-6週間）
1. **全バックエンド対応** - VM/WASM/AOT統合実装
2. **エラーハンドリング統合** - 統一エラーモデル
3. **パフォーマンス最適化** - 高速名前解決
## 🧪 統合テスト戦略
### 基本統合テスト
```nyash
# test_universal_integration.nyash
using nyashstd
using console_api
using mylib
# 3種類のAPIが同じように使える
assert(string.upper("test") == "TEST") # 組み込み
console.log("Integration test successful") # FFI-ABI
assert(mylib.process("data") == "processed") # Nyash
```
### FFI-ABI統合テスト
```nyash
# test_ffi_abi_integration.nyash
using canvas_api
# Canvas API経由での描画
canvas.fillRect("game-canvas", 10, 10, 100, 100, "red")
canvas.fillText("game-canvas", "Score: 100", 10, 30, "16px Arial", "white")
```
## 🌟 期待される革命的効果
### 🚀 開発者体験
- **統一API**: 組み込み・外部・自作すべて同じ書き方
- **IDE補完**: すべてのAPIが`ny`で補完される
- **エラー処理**: 統一エラーモデルで一貫性
### 🏗️ アーキテクチャ
- **MIRレベル統合**: 全バックエンドで同じパフォーマンス最適化
- **Effect System**: pure/mut/io/controlによる安全性保証
- **言語非依存**: BIDによる外部ライブラリ標準化
### 🌍 エコシステム
- **なんでもAPI**: あらゆる外部ライブラリがNyashから使える
- **バックエンド統一**: 同じコードがVM/WASM/AOTで動作
- **将来拡張**: パッケージレジストリでBID共有
---
**🎉 この統合設計で、Nyashが真に「なんでもできる」モダン言語になるにゃ！🚀🐱**

10
docs/development/proposals/nyir/README.md Normal file
View File

@ -0,0 +1,10 @@
# NyIR ドキュメント索引
- 仕様（骨子）: `spec.md`
- フェーズ計画（Phase 9.10）: `../予定/native-plan/issues/phase_9_10_nyir_spec.md`
- BIDサンプル: `bid_samples/`（console.yaml / canvas.yaml）
- 計画全体（Copilot用フルテキスト 9.7以降）: `../予定/native-plan/copilot_issues.txt`
- 関連: ABI/BIDドラフトは `../予定/native-plan/box_ffi_abi.md`
補足:
- NyIR Core（25命令）は凍結。拡張は NyIR-Ext（exceptions/concurrency/atomics）で段階導入。

26
docs/development/proposals/nyir/bid_samples/canvas.yaml Normal file
View File

@ -0,0 +1,26 @@
version: 0
interfaces:
- name: env.canvas
box: Canvas
methods:
- name: fillRect
params:
- { string: canvas_id }
- { i32: x }
- { i32: y }
- { i32: w }
- { i32: h }
- { string: color }
returns: void
effect: io
- name: fillText
params:
- { string: canvas_id }
- { string: text }
- { i32: x }
- { i32: y }
- { string: font }
- { string: color }
returns: void
effect: io

10
docs/development/proposals/nyir/bid_samples/console.yaml Normal file
View File

@ -0,0 +1,10 @@
version: 0
interfaces:
- name: env.console
box: Console
methods:
- name: log
params:
- { string: msg }
returns: void
effect: io

70
docs/development/proposals/nyir/phase_9_10_nyir_spec.md Normal file
View File

@ -0,0 +1,70 @@
# Phase 9.10: NyIR v1 仕様・フォーマット・検証器（公開IRの確立）
目的
- NyashのMIRを公開IR（NyIR v1）として凍結し、あらゆるフロントエンド/バックエンドの共通契約とする。
- 仕様・テキスト/バイナリフォーマット・厳格検証器・ツール群を整備し、移植性と一貫性を保証する。
成果物（Deliverables）
- 仕様書: `docs/nyir.md`（命令仕様/効果/未定義なし/検証ルール/等価変換指針）
- フォーマット: `.nyir`（テキスト）, `.nybc`（バイナリ）
- 検証器: `nyir-verify`（CLI/ライブラリ）
- 変換/実行ツール:
- `nyashel -S`（Nyash→NyIRダンプ）
- `nyir-run`（NyIRインタプリタ）
- 参考: `nyir-ll`（NyIR→LLVM IR、Phase 10で拡張）
- Golden NyIR: `golden/*.nyir`（代表サンプルを固定、CIで全バックエンド一致を検証）
仕様の要点（NyIR v1）
- 命令セット: 25命令（Tier-0/1/2）を凍結
- Tier-0: Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
- Tier-1: NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, Safepoint, RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
- Tier-2: TailCall, Adopt, Release, MemCopy, AtomicFence
- 効果（Effects）: pure / mut / io / control（再順序化規則を明文化）
- 所有フォレスト: 強参照の森（strong in-degree ≤ 1）、強循環禁止、weakは非伝播
- Weak: 失効時の挙動を決定（WeakLoad=null / WeakCheck=false）、世代タグ設計を想定
- Bus: ローカルは順序保証、リモートは at-least-once（または選択可能）
- 未定義動作なし: 各命令の事前条件/失敗時挙動を明示
- バージョニング: `nyir{major.minor}`、featureビットで拡張告知
テキスト形式（.nyir）
- 人間可読・差分レビュー向け
- 構造: moduleヘッダ / const pool / functions（blocks, instrs）
- コメント/メタデータ/featureビットを扱える簡潔な構文
バイナリ形式（.nybc）
- セクション化: header / features / const pool / functions / metadata
- エンコード: LEB128等の可変長を採用、識別子はstring table参照
- 将来の後方互換に備えた保守的設計
検証器（Verifier）
- 検査: 所有森/強循環/weak規則/効果整合/到達性/終端性/Phi入力整合
- 失敗時は明確なエラーを返し、ロード拒否
- CLI/ライブラリの二態（コンパイラ/実行系どちらからも利用）
Golden / Differential テスト
- `golden/*.nyir` を固定し、interp/vm/wasm/jit/llvm（順次）で出力一致をCIで検証
- 弱失効/分割fini/境界条件系を重点的に含める
タスク（Copilot TODO）
1) 仕様スケルトン: `docs/nyir.md` ひな形生成（命令/効果/検証/等価変換の目次）
2) `.nyir` パーサ/プリンタ（最小）
3) `.nybc` エンコーダ/デコーダ（最小）
4) `nyir-verify`（所有森/効果/Phi/到達/終端の基本チェック）
5) `nyashel -S` をNyIR出力対応に（既存MIRダンプ経路から移行）
6) Goldenサンプル作成（3〜5本）＋CIワークフロー雛形
受け入れ基準（Acceptance）
- 代表サンプルが `.nyir` で表現・検証・実行可能（`nyir-run`）
- `.nybc` 読み書き往復で等価
- CIでinterp/vm/wasmの結果一致（最小ケース）
依存/関連
- 8.5: 25命令の確定仕様
- 9.7: ExternCall/ABI（NyIRにもmethodノードor外部呼を表現）。v1ではExternCallは拡張セクションで可
- 10.x: NyIR→LLVM IR（別Phase）
リスク
- 仕様凍結の硬直化 → 拡張はfeatureビット＋拡張セクションへ
- 実装の重複 → Verifier/フォーマットは共有ライブラリ化
最終更新: 2025-08-14

126
docs/development/proposals/nyir/spec.md Normal file
View File

@ -0,0 +1,126 @@
# NyIR v1 Specification (Draft Skeleton)
Purpose
- Define NyIR (public intermediate representation) as the portable contract for all frontends/backends.
- Freeze the 25-instruction set, effects, ownership forest, weak semantics, and bus contract.
Status
- Version: nyir1.0 (draft)
- Change policy: backward-compatible extensions via feature bits; no undefined behavior.
1. Instruction Set (26) — Semantic Summary
- Tier-0: Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
- Tier-1: NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, ExternCall, Safepoint, RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
- Tier-2: TailCall, Adopt, Release, MemCopy, AtomicFence
For each instruction (to be filled):
- Semantics: preconditions, side-effects, failure behavior
- Effects: pure/mut/io/control
- Verification: structural/formal checks
- Example: minimal snippet
2. Effects Model
- pure: no observable side effects; can reorder with pure
- mut: mutates owned state; preserve order per resource
- io: interacts with outside world; preserve program order
- control: affects control flow/terminators
3. Ownership Forest
- Strong edges form a forest (strong in-degree ≤ 1).
- No strong cycles.
- Weak edges do not propagate ownership.
- Adopt/Release rules; Safepoint and split-fini notes.
4. Weak Semantics
- Representation: {ptr, generation}
- WeakLoad: returns null if generation mismatch
- WeakCheck: returns false if invalid
- O(1) on-access validation
5. Bus Contract
- Local: in-order delivery
- Remote: at-least-once (or selectable); specify ordering/dup policy
6. Formats
- Text .nyir: human-readable; module header, features, const pool, functions (blocks, instrs)
- Binary .nybc: sectioned; header, features, const pool, functions, metadata; varint encodings
- Feature bits and extension sections for evolution
7. Verification
- Program well-formedness: reachability, termination, dominance
- Phi input consistency
- Effects ordering constraints
- Ownership forest & weak/generation rules
- Bus safety checks
8. External Calls (Core)
- ExternCall: Interface to external libraries as Everything is Box principle
- Format: ExternCall { dst, iface_name, method_name, args }
- Effect annotation required (pure/mut/io/control)
- BID (Box Interface Definition) provides external API contracts
9. Mapping Guidelines
- WASM: imports, memory rules, (ptr,len) strings
- VM: function table mapping
- LLVM: declare signatures; effect to attributes (readonly/readnone, etc.)
10. Golden/Differential Testing
- Golden .nyir corpus; cross-backend consistency (interp/vm/wasm/llvm)
11. Versioning & Compatibility
- nyir{major.minor}; feature negotiation and safe fallback
12. Glossary
- Box, Effect, Ownership forest, Weak, Safepoint, Bus, Feature bit
Appendix
- Minimal examples (to be added)
- Rationale notes
------------------------------------------------------------
NyIR-Ext（拡張セット）
------------------------------------------------------------
目的
- NyIR Core（26命令）は基本セマンティクス凍結。外部世界接続（ExternCall）を含む基本機能確立。
- 拡張は言語固有機能に限定：「例外」「軽量並行/非同期」「アトミック」の3領域を段階追加。
- Core機能: すべての言語で必要な基本セマンティクス（制御フロー・Box操作・外部呼び出し）
- Extension機能: 特定言語でのみ必要な高級機能（例外処理・並行処理・アトミック操作）
Ext-1: 例外/アンワインド（exceptions）
- 命令（案）：
- Throw(value)
- TryBegin
- TryEnd(handlers=[type:block])
- 効果: control（脱出）。mut/io と混在する場合は当該効果も従属。
- 検証: Try の整合（入れ子/終端）、未捕捉 Throw のスコープ明示、no-throw 関数属性の尊重。
- バックエンド指針:
- LLVM: 言語EH or setjmp/longjmp 系へ lower
- WASM: v0は例外未使用なら「エラー戻り値」へ降格（no-exception モード）
Ext-2: 軽量並行/非同期（concurrency）
- 命令（案）：
- Spawn(fn, args...)
- Join(handle)
- Await(task|event) // または Wait
- 効果: io（スケジューラ相互作用）＋ control（待機・解除）。
- 検証: Join/Spawn のライフサイクル均衡、待機の整合（任意でデッドロック静的ヒント）。
- バックエンド指針:
- LLVM: pthread/std::thread/独自ランタイム
- WASM: スレッド未使用ならランループ/Promise/MessageChannel 等で近似
Ext-3: アトミック（atomics）
- 命令（案）：
- AtomicRmw(op, addr, val, ordering=seq_cst)
- CAS(addr, expect, replace, ordering=seq_cst)
- 既存の AtomicFence は維持。
- 効果: mut（アトミック副作用）。必要に応じて atomic/volatile フラグを effect/属性で付与。
- バックエンド指針:
- LLVM: `atomicrmw`, `cmpxchg`
- WASM: Threads 提案が前提。未サポート環境では未実装 or 疑似ロック（デモ用途）
備考
- 可変引数は slice 表現で代替（IR 追加不要）。
- クロージャ捕捉は Box + env フィールド + BoxCall で表現（IR 追加不要）。
- 動的言語（辞書/配列/プロトタイプ）は標準Box（std）で受ける（IR 追加不要）。
- 関数属性に「エラー戻り値モード/no-exception」などのメタを付与し、例外禁止環境へも対応する。

44
docs/development/proposals/nyir/vision_universal_exchange.md Normal file
View File

@ -0,0 +1,44 @@
# NyIR を共通交換フォーマットにする計画（All Languages → NyIR → All Targets）
目的（Goal）
- あらゆる言語のプログラムを NyIR（= Nyash MIR の公開版）へ落とし、そこから任意の実行形態（WASM/LLVM/VM/他言語）に変換する。
- 最適化は二の次。まずは意味保存（semantics-preserving）を最優先で実現し、可搬性と一貫性を担保する。
中核方針（Core Policy）
- NyIR Core（26命令）は基本セマンティクス凍結。ExternCallによる外部世界接続を含む。
- 拡張は NyIR-Ext（exceptions/concurrency/atomics）で言語固有機能を段階導入。
- Everything is Box哲学: 外部ライブラリもBIDによりBox統一インターフェースで利用。
- 仕様の正本は `docs/nyir/spec.md` に集約（Core＋Ext）。
必要拡張（Minimal Additions）
- 例外/アンワインド（Throw/TryBegin/TryEnd）
- 軽量並行/非同期（Spawn/Join/Await）
- アトミック（AtomicRmw/CAS + ordering）
→ 詳細は `docs/nyir/spec.md` の NyIR-Ext 参照
フロントエンド指針（Language → NyIR）
- C/C++/Rust: 既存IR（LLVM IR）経由または専用パーサでサブセットから対応
- 例外→NyIR-Ext exceptions or エラー戻り値
- スレッド→Spawn/Join、atomic→CAS/RMW
- Java/Kotlin: JVM bytecode から構造復元→NyIR（例外/スレッド/同期をExtへ）
- Python/JS/TS: AST→NyIR。辞書/配列/プロトタイプは標準Boxへ写像、例外/非同期はExtへ
- Go: panic/recover→exceptions、goroutine→Spawn/Join へ写像（将来）
バックエンド指針（NyIR → Target）
- WASM: 同期・非例外・非スレッドの最小路線から段階対応（Exceptions/Threads提案に合わせ拡張）
- LLVM: 例外/スレッド/アトミックが揃っているため先行実装が容易
- VM: 仕様の正しさ検証の基準（簡易実装でも良い）
- 他言語（ソース生成）: 可読性/慣用性は課題だが、機械的変換は可能（優先度低）
検証計画（Golden/Diff）
- Cサブセット→NyIR→C/WASM（例外なし・CASあり）
- Python/JSサブセット→NyIR→WASM（辞書/例外/非同期のサブセット）
- JVM系→NyIR→JVM bytecode（例外/スレッド）
- Rustサブセット→NyIR→LLVM（所有・weakの温存）
→ Golden NyIR を用い、interp/vm/wasm/llvm で出力一致をCI検証
関連リンク
- NyIR 仕様: `spec.md`
- ABI/BID: `../予定/native-plan/box_ffi_abi.md`
- 9.10 タスク（Copilot向け）: `../予定/native-plan/issues/phase_9_10_nyir_spec.md`

306
docs/development/proposals/urgent_fix_clone_box_to_arc_references.md Normal file
View File

@ -0,0 +1,306 @@
# 🚨 緊急修正 Issue: Everything is Box設計でのclone_box()問題根本解決
## 📋 Issue概要
**優先度**: 🔴 **URGENT** - 全ステートフルBox（SocketBox, P2PBox等）に影響
**期間**: 2-3日
**担当**: Copilot様
## 🎯 問題の核心
**ユーザー指摘**: 「いや　単純に　rustの使い方　へたなだけじゃーーい！」
**Gemini先生確認**: Everything is Box設計は正しい。問題は `clone_box()` を使うべきでない場所で使っていること
### 🚨 真犯人特定済み（3箇所）
1. **`src/interpreter/core.rs:366`** - `resolve_variable()`
2. **`src/instance.rs:275`** - `get_field()`
3. **`src/interpreter/expressions.rs:779`** - `execute_field_access()`
### 💥 現在の症状
```nyash
me.server.bind("127.0.0.1", 8080) // ✅ SocketBox ID=10, is_server=true
me.server.isServer() // ❌ SocketBox ID=19, is_server=false (別インスタンス!)
```
## 🛠️ 解決策：Arc<dyn NyashBox>への段階的移行
**Gemini先生推奨**: `Box<dyn NyashBox>` → `Arc<dyn NyashBox>` で参照共有実現
---
## 📋 段階的修正手順（Copilot実装ガイド）
### **Phase 1: 型エイリアス導入**
#### 1.1 `src/box_trait.rs`に型エイリアス追加
```rust
// ファイル先頭のuse文の後に追加
use std::sync::Arc;
// 新しい型エイリアス - 将来的にBox<dyn NyashBox>を全て置き換える
pub type SharedNyashBox = Arc<dyn NyashBox>;
```
#### 1.2 NyashBoxトレイトに新メソッド追加
```rust
// src/box_trait.rs のNyashBoxトレイト内に追加
pub trait NyashBox: BoxCore + Debug {
// 既存メソッド...
/// Arc参照を返す新しいcloneメソッド（参照共有）
fn clone_arc(&self) -> SharedNyashBox {
Arc::new(self.clone())
}
/// 従来のclone_box（互換性維持のため残す）
fn clone_box(&self) -> Box<dyn NyashBox>;
}
```
### **Phase 2: データ構造変更**
#### 2.1 `src/instance.rs` - InstanceBox修正
```rust
// InstanceBox構造体のfields型変更
pub struct InstanceBox {
pub base: BoxBase,
pub class_name: String,
pub fields: Arc<Mutex<HashMap<String, SharedNyashBox>>>, // ← Box→Arc
// 他フィールドはそのまま
}
// コンストラクタ修正
impl InstanceBox {
pub fn new(class_name: String, fields: Vec<String>) -> Self {
let mut field_map: HashMap<String, SharedNyashBox> = HashMap::new();
for field in fields {
field_map.insert(field, Arc::new(VoidBox::new())); // Box::new → Arc::new
}
InstanceBox {
base: BoxBase::new(),
class_name,
fields: Arc::new(Mutex::new(field_map)),
}
}
}
```
#### 2.2 `src/interpreter/core.rs` - NyashInterpreter修正
```rust
// NyashInterpreter構造体の変数管理型変更
pub struct NyashInterpreter {
// 既存フィールド...
pub local_vars: HashMap<String, SharedNyashBox>, // ← Box→Arc
pub outbox_vars: HashMap<String, SharedNyashBox>, // ← Box→Arc
// 他フィールドはそのまま
}
```
### **Phase 3: 問題箇所修正（真犯人退治）**
#### 3.1 `src/interpreter/core.rs:366` - resolve_variable修正
```rust
// 修正前：
let cloned_value = local_value.clone_box(); // ← 新インスタンス作成（問題）
return Ok(cloned_value);
// 修正後：
pub(super) fn resolve_variable(&self, name: &str) -> Result<SharedNyashBox, RuntimeError> {
// ... 既存のログ処理
// 2. local変数をチェック
if let Some(local_value) = self.local_vars.get(name) {
eprintln!("🔍 DEBUG: Found '{}' in local_vars", name);
// 🔧 修正：clone_box() → Arc::clone() で参照共有
let shared_value = Arc::clone(local_value);
core_deep_debug_log(&format!("✅ RESOLVE_VARIABLE shared reference: {} id={}",
name, shared_value.box_id()));
return Ok(shared_value);
}
// 残りの処理も同様にSharedNyashBoxを返すよう修正
// ...
}
```
#### 3.2 `src/instance.rs:275` - get_field修正
```rust
// 修正前：
pub fn get_field(&self, field_name: &str) -> Option<Box<dyn NyashBox>> {
self.fields.lock().unwrap().get(field_name).map(|v| v.clone_box()) // ← 複製（問題）
}
// 修正後：
pub fn get_field(&self, field_name: &str) -> Option<SharedNyashBox> {
eprintln!("✅ FIX: get_field('{}') returning shared Arc reference", field_name);
// 🔧 修正：v.clone_box() → Arc::clone(v) で参照共有
self.fields.lock().unwrap().get(field_name).map(Arc::clone)
}
```
#### 3.3 `src/interpreter/expressions.rs:779` - execute_field_access修正
```rust
// 修正前：
let field_value = instance.get_field(field) // get_fieldがBoxを返していた
// 修正後：
fn execute_field_access(&mut self, object: &ASTNode, field: &str)
-> Result<SharedNyashBox, RuntimeError> { // ← 戻り値型変更
// オブジェクト評価
let obj_value = self.execute_expression(object)?;
if let Some(instance) = obj_value.as_any().downcast_ref::<InstanceBox>() {
// フィールドアクセス - get_fieldがArc参照を返すように修正済み
let field_value = instance.get_field(field)
.ok_or_else(|| RuntimeError::InvalidOperation {
message: format!("Field '{}' not found in {}", field, instance.class_name),
})?;
eprintln!("✅ FIELD ACCESS: Returning shared reference id={}", field_value.box_id());
Ok(field_value) // Arc参照を返す
} else {
// エラー処理...
}
}
```
### **Phase 4: set_field修正**
#### 4.1 `src/instance.rs` - set_field修正
```rust
// set_fieldも引数の型をSharedNyashBoxに変更
pub fn set_field(&self, field_name: &str, value: SharedNyashBox) -> Result<(), String> {
eprintln!("🔧 INSTANCE: set_field('{}') with shared Arc reference id={}",
field_name, value.box_id());
let mut fields = self.fields.lock().unwrap();
if fields.contains_key(field_name) {
if let Some(old_value) = fields.get(field_name) {
eprintln!("🔧 INSTANCE: Replacing field '{}': old_id={} -> new_id={}",
field_name, old_value.box_id(), value.box_id());
}
fields.insert(field_name.to_string(), value);
Ok(())
} else {
Err(format!("Field '{}' does not exist in {}", field_name, self.class_name))
}
}
```
---
## 🧪 テスト方法
### テストファイル作成
```bash
# テスト用Nyashコード
echo 'static box Main {
init { server }
main() {
me.server = new SocketBox()
print("=== Before bind ===")
print("isServer: " + me.server.isServer())
me.server.bind("127.0.0.1", 8080)
print("=== After bind ===")
print("isServer: " + me.server.isServer()) // これがtrueになれば修正成功！
return me.server.isServer()
}
}' > test_arc_fix.nyash
```
### 実行・検証
```bash
# ビルド・実行
cargo build --release
./target/release/nyash test_arc_fix.nyash
# 期待される結果：
# === Before bind ===
# isServer: false
# === After bind ===
# isServer: true ← これが true になれば成功！
```
---
## 📋 修正対象ファイル一覧
### 必須修正ファイル
1. **`src/box_trait.rs`** - 型エイリアス・clone_arcメソッド追加
2. **`src/instance.rs`** - InstanceBox構造体・get_field・set_field修正
3. **`src/interpreter/core.rs`** - NyashInterpreter・resolve_variable修正
4. **`src/interpreter/expressions.rs`** - execute_field_access修正
### 追加修正が必要になる可能性があるファイル
- `src/interpreter/statements.rs` - 代入処理
- `src/interpreter/objects.rs` - オブジェクト生成処理
- その他 `Box<dyn NyashBox>` を使用している箇所
## 🎯 修正完了条件
### ✅ 成功条件
1. **テスト成功**: `test_arc_fix.nyash` で `isServer: true` が表示される
2. **コンパイル成功**: `cargo build --release` でエラーなし
3. **既存テスト成功**: `cargo test` でテスト通過
4. **デバッグログ確認**: 同一SocketBox IDが維持される
### 🔍 確認ポイント
- SocketBoxログで同じIDが表示される（ID変化なし）
- 状態が正しく保持される（bind後にisServer=true）
- メモリリークが発生しない（Arc参照カウント正常）
---
## 💡 実装のコツ（Copilot向け）
### 段階的実装推奨
1. **まず型エイリアス追加** → コンパイルエラー確認
2. **データ構造を段階的に変更** → 各ファイル別に修正
3. **最後に問題の3箇所修正** → 動作テスト実行
### よくあるコンパイルエラー対処
- **型不一致**: `Box<dyn NyashBox>` と `SharedNyashBox` の混在
→ 段階的に `SharedNyashBox` に統一
- **ライフタイム問題**: Arc使用により大部分が解決
- **メソッドシグネチャ不一致**: 戻り値型を `SharedNyashBox` に変更
### デバッグのポイント
- 修正前後でSocketBox IDが同じになることを確認
- `Arc::strong_count()` で参照数確認（デバッグ用）
---
## 🚀 期待される効果
### 🎉 修正後の動作
```nyash
me.server.bind("127.0.0.1", 8080) // ✅ SocketBox ID=10, is_server=true
me.server.isServer() // ✅ SocketBox ID=10, is_server=true (同じインスタンス!)
```
### 📈 影響範囲
- **全ステートフルBox**: SocketBox, P2PBox, HTTPServerBox等が正常動作
- **全フィールドアクセス**: `obj.field` で状態保持
- **全変数アクセス**: `me`変数で状態保持
- **性能向上**: 不要なclone処理削減
### 🏆 Everything is Box設計完成
ユーザー指摘通り、設計は正しく、**Rustの所有権システムを正しく使う**ことで、真の「Everything is Box」が実現されます！
---
**実装担当**: Copilot様
**レビュー**: Claude & User
**完了目標**: 2-3日以内

62
docs/development/roadmap/README.md Normal file
View File

@ -0,0 +1,62 @@
# 🗺️ Nyash 予定（ロードマップ・タスク）
## 📋 現在進行中
### 🎯 最重要タスク
- **現在のタスク**: [docs/CURRENT_TASK.md](../CURRENT_TASK.md)
- **Phase 8.3**: Box操作WASM実装（Copilot担当）
- **Phase 8.4**: ネイティブコンパイル実装計画（AI大会議策定済み）
## 🚀 ネイティブコンパイル計画 (2025-08-14策定)
### 📊 AI大会議成果
- **[🤖 AI大会議記録](ai_conference_native_compilation_20250814.md)** - Gemini×codex×Claude技術検討
- **[🗺️ ネイティブコンパイルロードマップ](native-compilation-roadmap.md)** - 技術戦略詳細
### ⚡ 実装フェーズ
- **Phase A (2-3週間)**: AOT WASM → 500倍高速化目標
- **Phase B (2-3ヶ月)**: Cranelift Direct → 600倍高速化目標
- **Phase C (6ヶ月+)**: LLVM Ultimate → 1000倍高速化目標
## 🤖 Copilot協調管理
### 📋 Copilot作業管理
- **[copilot_issues.txt](copilot_issues.txt)** - Copilot様への依頼・課題整理
- **協調戦略**: [docs/CURRENT_TASK.md](../CURRENT_TASK.md)内に詳細記載
### 🎯 フェーズ別課題
- **Phase 8課題**: [native-plan/issues/](native-plan/issues/)
- **統合管理**: Claude×Copilot マージ競合回避戦略
## 📊 実装状況追跡
### ✅ 完了済み (Phase 8.2)
- WASM: 0.17ms (280倍高速化)
- VM: 16.97ms (2.9倍高速化)
- ベンチマークシステム完成
- 3バックエンド統合CLI
### 🚧 進行中 (Phase 8.3)
- Box操作WASM対応（Copilot実装中）
- RefNew/RefGet/RefSet命令
- メモリレイアウト最適化
### 🔜 次期予定 (Phase 8.4+)
- AOT WASMネイティブ化
- MIR最適化基盤
- エスケープ解析実装
## 📚 関連ドキュメント
### 📖 技術資料
- **[実行バックエンドガイド](../execution-backends.md)** - 3バックエンド使い分け
- **[コアコンセプト](../nyash_core_concepts.md)** - Everything is Box哲学
### 🔄 進捗管理
- **定期更新**: 毎週金曜日に進捗反映
- **AI会議**: 重要決定事項は3AI大会議で検討
- **ベンチマーク**: 性能回帰チェック自動実行
---
**最終更新**: 2025-08-14 - AI大会議によるネイティブコンパイル戦略確定

173
docs/development/roadmap/native-compilation-roadmap.md Normal file
View File

@ -0,0 +1,173 @@
# 🚀 Nyash Native Compilation Roadmap
*Generated: 2025-08-14 - AI大会議議題*
## 🎯 現在地点
**Phase 8.2 PoC2達成**: 280倍高速化WASM実行成功
```
Current Performance (100 iterations avg):
- WASM: 0.17ms (280x faster)
- VM: 16.97ms (2.9x faster)
- Interpreter: 48.59ms (baseline)
```
**技術基盤完成状況**:
- ✅ AST → MIR変換パイプライン
- ✅ MIR → WASM コード生成
- ✅ MIR → VM 実行エンジン
- ✅ 3バックエンド統合CLI
- ✅ 自動ベンチマークシステム
## 🗺️ ネイティブコンパイル戦略
### 🥇 Phase A: AOT WASM (短期 - 2-4週間)
**Goal**: 既存WASM基盤でネイティブ実行ファイル生成
**実装アプローチ**:
```bash
# 新CLI機能
nyash --compile-native program.nyash -o program.exe
nyash --aot program.nyash # 短縮形
# 内部パイプライン
Nyash → AST → MIR → WASM → wasmtime compile → Native Binary
```
**技術詳細**:
- **wasmtime compile**: WASM → ネイティブバイナリ変換
- **Cranelift使用**: wasmtimeの内部コンパイラ活用
- **クロスプラットフォーム**: Windows/Linux/macOS対応
- **既存基盤活用**: WASMバックエンド完全再利用
**期待性能**: 0.10ms (500倍高速化)
**成功基準**:
- [ ] `--compile-native` CLI実装
- [ ] 実行ファイル生成成功
- [ ] 既存ベンチマーク維持
- [ ] クロスプラットフォーム動作確認
**実装ファイル**:
- `src/backend/native_aot.rs` - AOTコンパイラ
- `src/main.rs` - CLI統合
- `benchmarks/bench_native.nyash` - ネイティブ性能測定
### 🥈 Phase B: Cranelift Direct (中期 - 2-3ヶ月)
**Goal**: MIRから直接ネイティブコード生成
**実装アプローチ**:
```rust
// src/backend/cranelift.rs
pub struct CraneliftBackend {
context: cranelift::Context,
module: cranelift::Module<ObjectModule>,
}
// パイプライン
Nyash → AST → MIR → Cranelift IR → Native Binary
```
**技術詳細**:
- **直接コンパイル**: WASM経由せずMIR→ネイティブ
- **最適化制御**: Craneliftの最適化レベル調整
- **デバッグ情報**: ネイティブデバッガ対応
- **静的リンク**: 単体実行ファイル生成
**期待性能**: 0.08ms (600倍高速化)
**技術課題**:
- [ ] MIR → Cranelift IR変換実装
- [ ] Everything is Box メモリモデル
- [ ] ガベージコレクション統合
- [ ] デバッグ情報生成
### 🥉 Phase C: LLVM Optimization (長期 - 6ヶ月+)
**Goal**: 最高性能のLLVMバックエンド
**実装アプローチ**:
```rust
// src/backend/llvm.rs - inkwell使用
use inkwell::*;
// パイプライン
Nyash → AST → MIR → LLVM IR → Native Binary (O3)
```
**技術詳細**:
- **LLVM O3最適化**: 最高レベルの最適化
- **LTO対応**: Link Time Optimization
- **プロファイル最適化**: PGO (Profile Guided Optimization)
- **ターゲット最適化**: CPU特化最適化
**期待性能**: 0.05ms (1000倍高速化)
**技術課題**:
- [ ] LLVM依存管理
- [ ] 複雑な最適化パス
- [ ] ビルド時間増大対策
- [ ] バイナリサイズ最適化
## 📊 性能予測比較
| Phase | Backend | 予想時間 | 高速化倍率 | 実装期間 | 技術的複雑度 |
|-------|---------|----------|------------|----------|-------------|
| Current | WASM | 0.17ms | 280x | ✅完了 | 中 |
| **A** | **AOT WASM** | **0.10ms** | **500x** | **2-4週間** | **低** |
| B | Cranelift | 0.08ms | 600x | 2-3ヶ月 | 中 |
| C | LLVM O3 | 0.05ms | 1000x | 6ヶ月+ | 高 |
## 🎯 推奨実装順序
### 1. **Phase A優先推奨理由**
- **低リスク**: 既存技術活用
- **高効果**: 2-3倍の追加高速化
- **即効性**: 数週間で実用可能
- **学習効果**: ネイティブコンパイル経験獲得
### 2. **段階的発展**
- Phase A → 実用レベルのネイティブ言語達成
- Phase B → 専用最適化による差別化
- Phase C → 最高性能言語の地位確立
### 3. **ベンチマーク駆動開発**
各Phaseで既存ベンチマークシステム活用:
```bash
# 性能回帰チェック
nyash --benchmark --iterations 100
# ネイティブ性能測定
nyash --benchmark --native --iterations 100
```
## 🤖 AI議論ポイント
### Gemini先生への質問
1. **Cranelift vs LLVM**: Rust言語開発の観点からの推奨は？
2. **wasmtime compile**: 実用性・性能・制約の評価
3. **Everything is Box**: ネイティブでの最適実装戦略
4. **段階的アプローチ**: 技術的妥当性の評価
### codex先生への質問
1. **実装優先度**: Phase A-C の現実的スケジュール
2. **技術的課題**: 各Phaseの隠れたリスク分析
3. **ユーザー価値**: ネイティブ化の実用的メリット
4. **競合比較**: 他言語のネイティブ戦略との差別化
## 🌟 期待される革新
### 開発体験革命
- **開発**: インタープリター（詳細デバッグ）
- **テスト**: VM（中間性能・高信頼性）
- **配布**: WASM（Web・サンドボックス）
- **本番**: Native（最高性能・単体配布）
### 言語としての完成度
- **学習容易性**: Everything is Box哲学
- **開発効率性**: 明示的デリゲーション・型安全性
- **実行性能**: ネイティブレベルの高速実行
- **配布柔軟性**: 4つの実行形態対応
---
**次のステップ**: AI大会議で実装戦略の詳細検討・優先順位決定
*Let's make Nyash the ultimate native language! 🚀*

110
docs/development/roadmap/native-plan/MIR仕様書.txt Normal file
View File

@ -0,0 +1,110 @@
やったね！この粒度なら “化け物に伸びる余白” と “実装の現実” のちょうど真ん中。
仕上げとして **25命令をキッチリ確定**＋**意味論/効果/検証ルール** を短く固めよう。
# 決定版 MIR（25命令）
## Tier-0: 普遍コア（8）
```
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```
* 効果: `Const/Phi`=pure, `BinOp/Compare`=pure, `Branch/Jump/Return`=control, `Call`は呼先の効果に従う
* 備考: 将来のJIT/AOT/WASMすべてで必須
## Tier-1: Nyashセマンティクス（12）
```
NewBox, // 強所有のBox生成（所有森のノード）
BoxFieldLoad, // Boxのフィールド読み
BoxFieldStore, // Boxのフィールド書き（= mut）
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
Safepoint, // 分割finiや割込み許可ポイント
RefGet, // 参照（強/弱を問わず）を値として取得
RefSet, // 参照の差し替え（所有規則の検証付き）
WeakNew, // `weak` ハンドル生成（非所有リンクの作成）
WeakLoad, // `weak` から生存チェック付きで強参照を得る（失効時null）
WeakCheck, // `weak` の生存確認（bool）
Send, // Bus送信（Effect=io）
Recv // Bus受信（Effect=io）
```
* 効果: `BoxFieldStore/RefSet`=mut, `Send/Recv`=io, 他は基本pure/可変
* これで **所有森＋weak/look＋Bus** が言語一次市民として表現可能
## Tier-2: 実装補助・最適化友好（5）
```
TailCall, // 末尾呼び出し（スタック節約）
Adopt, // 所有移管: this が子を強所有に取り込む
Release, // 強所有を解除（weak化 or null化）
MemCopy, // 小さなメモリ移動（構造体/配列の最適化フック）
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
```
* 位置づけ: どれも“言語仕様の裏方”。無くても表現可能だが、**性能・安全検査・移植性**が安定する
---
## 効果（Effect）既定値
* `pure`: Const, BinOp, Compare, Phi, WeakCheck, WeakLoad(成功時の取得自体はpure扱い)
* `mut`: BoxFieldStore, RefSet, Adopt, Release, MemCopy
* `io`: Send, Recv, Safepoint(割り込み/分割fini許可点としてio扱い)
* `control`: Branch, Jump, Return, TailCall
* `context依存`: Call, BoxCall（呼先の効果に従属）
> 最適化ルールは「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」。
---
## 検証（Lint/Verifier）要件（短縮版）
* **所有森**: `strong in-degree ≤ 1`（`NewBox/Adopt/Release/RefSet`で常時検査）
* **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
* **弱/強相互**: 双方向とも強 → エラー（片側は `WeakNew` 経由で弱化）
* **RefSetの安全**: 強→強の差し替え時は旧所有元からの `Release` が伴うこと
* **WeakLoad/WeakCheck**: 失効時は `null/false` を返す（例外禁止、決定的挙動）
* **TailCall**: 末尾位置のみ可（`Return` 直前）
* **Send/Recv**: バックエンドが同期/非同期いずれでも**at-least-once**契約を満たすか、契約を明示
---
## 代表的ロワリング（例）
* `look` 参照 → `WeakNew` + `WeakLoad`（読取専用型なら `RefSet` を禁止）
* `borrow{}` → ブロック先頭 `WeakNew`、末尾でハンドル破棄（MIR上はNop、型で書換禁止）
* Bus最適化（Elision）:
* `(pure|mut(local))` かつ同一スレッド/アリーナ/単一受信なら **`Send/Recv` → 直呼び/直アクセス** に縮退
* `fini` 伝播: ランタイムで **強エッジのみ** 再帰。`Safepoint` で分割解放/優先度解放に対応
---
## バックエンド指針（対応表）
* **Interpreter**: 25命令を素直に実装（正しさの基準）
* **VM**: Register-VM + direct-threading。`Send/Recv` はローカル判定時にインライン化
* **WASM**: `Send/Recv` は host import。`MemCopy` は `memory.copy` に対応
* **Cranelift/JIT**: `TailCall` 最適化、`WeakLoad` は世代タグでO(1)生存チェック
* **AOT-Rust**: `BoxCall` を trait 呼び出しへ、`Adopt/Release` は所有者IDの切替 + デバッガ用アサート
---
## 互換テスト（常設）
* **golden MIR**: 各サンプルのMIRダンプが全バックエンドで一致
* **行動一致**: `interp/vm/wasm` で**同入力→同出力**（`weak`失効時の`null/false`含む）
* **性能スモーク**: `add_loop / map_getset / alloc_free / bus_local / bus_actor` の5種で、
* VMがinterp以上、WASMがVM以上、を継続検証
---
これで **25命令フルセット**が完成。
* Nyashのコア価値（所有森＋weak＋Bus＋効果注釈）を**無理なくIR化**
* それぞれのバックエンドに**綺麗に落ちる**
* Verifier/最適化/テストも**最小で回る**
次は、このリストをそのまま `docs/mir.md` にコピペして、各命令に **1行の意味論＋効果＋等価変換の例** を添えれば、実装と論文の両方が一気に前進するにゃ。

211
docs/development/roadmap/native-plan/Phase-9.78-LLVM-PoC-Strategy.md Normal file
View File

@ -0,0 +1,211 @@
# 🚀 Phase 9.78: LLVM Proof of Concept - AI大会議戦略文書
## 🎯 **Phase 9.78の位置づけ**
```
Phase 8.6: VM最適化完了 ✅
↓
Phase 9.78: LLVM PoC (3週間集中) ← 🆕 挿入！
├─ ✅ 実現可能 → Phase 9.8(完全版) → Phase 10.2(本格LLVM)
└─ ❌ 実現困難 → Phase 9.8(3バックエンド版) → Box統合
```
**戦略的価値**: 不確定要素を3週間で解決し、後続開発の全体最適化を実現
## 🔍 **現在のMIR分析**
### **技術基盤状況** ✅
```rust
// ChatGPT5設計 20-25命令MIR
- SSA形式 ✅
- 効果追跡 (EffectMask) ✅
- Box最適化対応 ✅
- 所有権検証システム ✅
- 基本ブロック・関数構造 ✅
主要命令セット:
├─ Const, BinOp, UnaryOp, Compare
├─ BoxCall, ExternCall (プラグイン連携)
├─ RefNew, RefGet, RefSet (参照操作)
├─ Branch, Jump, Return (制御フロー)
└─ Print, FutureNew, Await (特殊操作)
```
### **LLVM変換の技術的課題** 🤔
```
1. MIR ValueId → LLVM Value* 対応
2. Box型 → LLVM struct表現
3. ExternCall → C-ABI関数呼び出し
4. 効果追跡 → LLVM属性 (readonly/noalias等)
5. 所有権 → LLVM メモリ管理
```
## 🤖 **AI大会議への相談事項**
### **Gemini先生への技術相談**
```
Nyashプログラミング言語のMIR→LLVM IR変換について技術的相談です。
【背景】
- ChatGPT5設計の20-25命令MIR (SSA形式)
- Everything is Box哲学 (全データがBoxオブジェクト)
- Arc<Mutex>統一アーキテクチャ
- BID-FFIプラグインシステム (C-ABI)
【MIR主要命令】
- Const, BinOp, UnaryOp, Compare
- BoxCall (Box.method呼び出し)
- ExternCall (プラグイン関数呼び出し)
- RefNew, RefGet, RefSet (参照操作)
- Branch, Jump, Return (制御フロー)
【質問】
1. MIR→LLVM IR変換の基本戦略は？
2. Box型の効率的なLLVM表現は？
3. C-ABIプラグイン統合の最適手法は？
4. 3週間PoC の現実的スコープは？
5. パフォーマンス向上の期待値は？
Rust実装での実践的なアドバイスをお願いします。
```
### **Codex先生への実装相談**
```
Nyashプログラミング言語のLLVM実装について実装戦略を相談したいです。
【プロジェクト概要】
- 15日間で開発されたプログラミング言語
- 4バックエンド対応 (Interpreter/VM/WASM/LLVM)
- MIR中間表現 (20-25命令、SSA形式)
- プラグインシステム完備
【実装チームの特徴】
- AI協調開発 (Claude/Gemini/ChatGPT/Copilot)
- 開発速度重視 (3週間でPoC完成目標)
- 実用性優先 (完璧より実装)
【技術的制約】
- Rust実装
- LLVM-sys crate使用想定
- 既存MIR構造活用
- プラグインC-ABI統合必須
【相談事項】
1. 3週間PoC実装の現実的な手順は？
2. MIR→LLVM変換の最小実装範囲は？
3. Box型をLLVMでどう表現すべきか？
4. エラー頻発箇所と対策は？
5. デバッグ・テスト戦略は？
実装経験に基づく現実的なアドバイスをお願いします。
```
## 🛠️ **Copilot依頼文書案**
### **Phase 9.78: LLVM Proof of Concept実装依頼**
**目標**: 3週間でNyash MIR→LLVM IR変換の実現可能性を実証
**成功基準**:
- 基本MIR命令(Const, BinOp, Compare, Branch, Return)のLLVM変換
- Box型の基本的なLLVM表現実装
- Hello World レベルの実行確認
- 理論的性能向上の算出 (10倍目標)
**技術基盤**:
```rust
// 既存のMIR構造を活用
src/mir/instruction.rs // 20-25命令定義
src/mir/function.rs // 関数・モジュール構造
src/mir/basic_block.rs // 基本ブロック管理
// 作成予定のLLVM実装
src/backend/llvm/
├─ compiler.rs // MIR→LLVM変換メイン
├─ box_types.rs // Box型のLLVM表現
├─ c_abi.rs // プラグインC-ABI統合
└─ runtime.rs // ランタイムサポート
```
**実装手順提案**:
```
Week 1: LLVM基盤構築
├─ llvm-sys crate統合
├─ 基本的な変換フレームワーク
├─ 最小MIR命令 (Const, Return) 変換
└─ Hello World レベル動作確認
Week 2: 主要機能実装
├─ 算術演算 (BinOp, UnaryOp, Compare)
├─ 制御フロー (Branch, Jump)
├─ Box型基本表現
└─ 関数呼び出し機構
Week 3: 統合・検証
├─ 既存MIRとの統合テスト
├─ 性能ベンチマーク実行
├─ 実現可能性評価レポート
└─ Phase 10本格実装計画策定
```
**重要な考慮事項**:
- 完璧を求めず、実現可能性の実証に集中
- 既存のMIR構造を最大活用
- エラーハンドリングより基本機能優先
- ベンチマークによる定量評価必須
**期待される成果**:
- LLVM実装の技術的実現可能性確認
- 性能向上ポテンシャルの定量評価
- Phase 9.8 BIDレジストリでのLLVM対応完全版実装可能性判定
- Phase 10本格実装の具体的工程表
## 📊 **成功判定基準**
### **最低限成功** (実現可能と判定)
```
✅ 基本MIR命令のLLVM変換動作
✅ Box型の基本的LLVM表現実装
✅ 簡単なプログラムの実行確認
✅ 理論的性能向上の算出
```
### **理想的成功** (本格実装確実)
```
🌟 全MIR命令対応
🌟 プラグインC-ABI統合
🌟 実際の性能測定 (2倍以上)
🌟 メモリ管理・エラーハンドリング
```
### **失敗判定** (3バックエンドに方針転換)
```
❌ 基本変換が3週間で実装困難
❌ Box型表現が非現実的に複雑
❌ 性能向上が期待値を大幅に下回る
❌ 技術的負債が実装継続を阻害
```
## 🎉 **次のステップ**
### **AI大会議実行**
1. Gemini先生に技術相談
2. Codex先生に実装戦略相談
3. 両者のアドバイスを統合
4. 最終的なCopilot依頼文書完成
### **Phase 9.78開始**
1. VM最適化完了の確認
2. AI大会議結果の反映
3. Copilotへの正式依頼
4. 3週間集中実装開始
---
**作成**: 2025年8月19日
**目的**: Phase 9.78 LLVM PoC実装のための戦略文書
**次期行動**: AI大会議でさらなる戦略精緻化
この文書をベースに、Gemini先生とCodex先生に相談し、最強のLLVM実装戦略を策定しましょう！🚀

114
docs/development/roadmap/native-plan/README.md Normal file
View File

@ -0,0 +1,114 @@
# 🚀 Nyash ネイティブビルド計画（Native Plan）
## 🎯 目的
開発者向けに「ビルド計画・段階的タスク・設計上の要点」を集約。
利用者向けの具体的なビルド手順は docs/説明書/native-build/README.md を参照。
## 📋 重要リンク
- **現在のタスク**: [docs/CURRENT_TASK.md](../../CURRENT_TASK.md)
- **コア概念（速習）**: [docs/nyash_core_concepts.md](../../nyash_core_concepts.md)
- **🤖 AI大会議記録**: [../ai_conference_native_compilation_20250814.md](../ai_conference_native_compilation_20250814.md)
- **🗺️ ネイティブコンパイル戦略**: [../native-compilation-roadmap.md](../native-compilation-roadmap.md)
- **フェーズ課題一覧**: [issues/](issues/)
- **🤖 Copilot協調**: [copilot_issues.txt](copilot_issues.txt)
## 🌟 **最新戦略 (2025-08-14 AI大会議策定)**
### ⚡ ネイティブコンパイル革命計画
**現状**: WASM 13.5倍実行高速化達成 → **目標**: 500-1000倍総合高速化
#### **Phase A: AOT WASM** (最優先 - 2-3週間)
```bash
nyash --compile-native program.nyash -o program.exe
```
- **技術**: wasmtime compile でネイティブ化
- **効果**: 13.5倍 → 100倍 (7倍追加向上)
#### **Phase B: Cranelift Direct** (中期 - 2-3ヶ月)
```
Pipeline: MIR → Cranelift IR → ネイティブバイナリ
```
- **技術**: エスケープ解析・ボックス化解除
- **効果**: 100倍 → 200倍
#### **Phase C: LLVM Ultimate** (長期 - 6ヶ月+)
```
Pipeline: MIR → LLVM IR → 最適化ネイティブ
```
- **技術**: LTO・PGO・高度最適化
- **効果**: 200倍 → 500-1000倍
### 🔑 成功の鍵 (3AI一致見解)
1. **MIR最適化**: ボックス化解除がバックエンド差より圧倒的効果
2. **エスケープ解析**: スタック割り当て・型特殊化
3. **段階的検証**: 各Phaseでベンチマーク駆動開発
要点サマリ（統合）
- ビルド方針
- デフォルトは CLI 最小構成（`cargo build --bin nyash`）。GUI/Examples は feature で任意有効化。
- Windows ネイティブ: MSVC または WSL + cargo-xwin によるクロスコンパイルを推奨。
- MIR/VM の段階的導入
- Phase 5.2: `static box Main` → MIR への lowering 経路を実装済み。
- Phase 6: 参照/弱参照の最小命令（RefNew/RefGet/RefSet, WeakNew/WeakLoad, BarrierRead/Write=no-op）。
- 例外/Async は薄く導入、先に snapshot/verify の安定化を優先。
- 弱参照の意味論（実装で壊れにくく）
- WeakLoad は Option<Ref> を返す（生存時 Some、消滅時 None）。PURE 扱い（必要に応じ READS_HEAP）。
- `fini()` 後の使用禁止・weak 自動 null・cascading 順序（weak はスキップ）を不変として扱う。
- Safepoint と Barrier
- 関数入口・ループ先頭・呼出直後に safepoint。Barrier は最初は no-op 命令として実装可。
- テスト戦略
- 黄金テスト：ソース→MIR ダンプのスナップショットで後退検出。
- VM/JIT 一致：同入力で VM と JIT の結果一致（将来の AOT でも同様）。
- 弱参照の確率テスト：alloc→weak→drop→collect→weak_load の順序/タイミングを多様化。
進行フェーズ（抜粋）
- Phase 0: CLI 最小ビルド安定化（Linux/Windows）。
- Phase 5.2: static Main lowering（実装済み）。
- Phase 6: 参照/弱参照（Barrier は no-op で開始）。
- Phase 7: nowait/await（スレッドベース、FutureBox 連携）。
Phase 8: MIR→WASM（Rustランタイムに非依存のWASM生成）
目的
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
- Rust は「コンパイラ本体」のみ。実行時は純WASM＋ホスト import（env.print など）。
範囲（最小）
- ABI/インポート・エクスポート:
- exports: `main`, `memory`
- imports: `env.print(i32)`（文字列は一旦 i32 値/デバッグ用途でOK。将来は文字列ABIを定義）
- メモリ/ヒープ:
- 線形メモリに簡易ヒープ（bump/フリーリスト）。
- Box は固定レイアウト（フィールド→オフセット表）。
- 命令カバレッジ（段階導入）:
- 算術/比較/分岐/loop/return/print
- RefNew/RefSet/RefGet（Phase 6 と整合）
- Weak/Barrier は下地のみ（WeakLoad は当面 Some 相当でOK、Barrier は no-op）
段階的マイルストーン（PoC）
1) PoC1: 算術/分岐/return のみのWASM出力（wasmtime/ブラウザで実行）
2) PoC2: オブジェクト最小実装（RefNew/RefSet/RefGet）で `print(o.x)` が動作
3) PoC3: Weak/Barrier の下地（WeakLoad は常に有効、Barrier はダミー命令）
4) PoC4: CLI 統合（`--backend wasm` で wasm 生成・実行。ブラウザ用は別JSローダ）
受け入れ基準
- wasmtime 実行で戻り値/標準出力が期待通り（PoC1–2）。
- Ref 系がメモリ上で正しく動作（PoC2）。
- Weak/Barrier のダミー実装を含むWASMが生成され、実行に支障がない（PoC3）。
- CLI オプションで wasm バックエンドが選択でき、未実装部分は明瞭にエラーメッセージで誘導（PoC4）。
テスト方針
- 生成WASMを wasmtime で実行し、戻り値/print の内容を検証。
- ブラウザ用はヘッドレス環境（node + WebAssembly API）で同等の確認ができるスクリプトを用意。
対象外（Phase 8）
- 本格的GC/Weak無効化、fini/Pin/Unpin、JIT/AOT、複雑な文字列ABI。
アーカイブ（長文メモ・相談ログ）
- docs/予定/native-plan/archive/chatgptネイティブビルド大作戦.txt
- docs/予定/native-plan/archive/追記相談.txt
- 上記2ファイルの要点は本 README に統合済み。詳細経緯はアーカイブを参照。
備考
- デバッグ補助: `--debug-fuel` でパーサーの燃料制御。`--dump-mir`/`--verify` で MIR の可視化・検証。
- 一部の開発用ログ出力（/mnt/c/...）は存在しない環境では黙って無視されます（問題なし）。

110
docs/development/roadmap/native-plan/archives/MIR仕様書_20250814.txt Normal file
View File

@ -0,0 +1,110 @@
やったね！この粒度なら “化け物に伸びる余白” と “実装の現実” のちょうど真ん中。
仕上げとして **25命令をキッチリ確定**＋**意味論/効果/検証ルール** を短く固めよう。
# 決定版 MIR（25命令）
## Tier-0: 普遍コア（8）
```
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```
* 効果: `Const/Phi`=pure, `BinOp/Compare`=pure, `Branch/Jump/Return`=control, `Call`は呼先の効果に従う
* 備考: 将来のJIT/AOT/WASMすべてで必須
## Tier-1: Nyashセマンティクス（12）
```
NewBox, // 強所有のBox生成（所有森のノード）
BoxFieldLoad, // Boxのフィールド読み
BoxFieldStore, // Boxのフィールド書き（= mut）
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
Safepoint, // 分割finiや割込み許可ポイント
RefGet, // 参照（強/弱を問わず）を値として取得
RefSet, // 参照の差し替え（所有規則の検証付き）
WeakNew, // `weak` ハンドル生成（非所有リンクの作成）
WeakLoad, // `weak` から生存チェック付きで強参照を得る（失効時null）
WeakCheck, // `weak` の生存確認（bool）
Send, // Bus送信（Effect=io）
Recv // Bus受信（Effect=io）
```
* 効果: `BoxFieldStore/RefSet`=mut, `Send/Recv`=io, 他は基本pure/可変
* これで **所有森＋weak/look＋Bus** が言語一次市民として表現可能
## Tier-2: 実装補助・最適化友好（5）
```
TailCall, // 末尾呼び出し（スタック節約）
Adopt, // 所有移管: this が子を強所有に取り込む
Release, // 強所有を解除（weak化 or null化）
MemCopy, // 小さなメモリ移動（構造体/配列の最適化フック）
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
```
* 位置づけ: どれも“言語仕様の裏方”。無くても表現可能だが、**性能・安全検査・移植性**が安定する
---
## 効果（Effect）既定値
* `pure`: Const, BinOp, Compare, Phi, WeakCheck, WeakLoad(成功時の取得自体はpure扱い)
* `mut`: BoxFieldStore, RefSet, Adopt, Release, MemCopy
* `io`: Send, Recv, Safepoint(割り込み/分割fini許可点としてio扱い)
* `control`: Branch, Jump, Return, TailCall
* `context依存`: Call, BoxCall（呼先の効果に従属）
> 最適化ルールは「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」。
---
## 検証（Lint/Verifier）要件（短縮版）
* **所有森**: `strong in-degree ≤ 1`（`NewBox/Adopt/Release/RefSet`で常時検査）
* **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
* **弱/強相互**: 双方向とも強 → エラー（片側は `WeakNew` 経由で弱化）
* **RefSetの安全**: 強→強の差し替え時は旧所有元からの `Release` が伴うこと
* **WeakLoad/WeakCheck**: 失効時は `null/false` を返す（例外禁止、決定的挙動）
* **TailCall**: 末尾位置のみ可（`Return` 直前）
* **Send/Recv**: バックエンドが同期/非同期いずれでも**at-least-once**契約を満たすか、契約を明示
---
## 代表的ロワリング（例）
* `look` 参照 → `WeakNew` + `WeakLoad`（読取専用型なら `RefSet` を禁止）
* `borrow{}` → ブロック先頭 `WeakNew`、末尾でハンドル破棄（MIR上はNop、型で書換禁止）
* Bus最適化（Elision）:
* `(pure|mut(local))` かつ同一スレッド/アリーナ/単一受信なら **`Send/Recv` → 直呼び/直アクセス** に縮退
* `fini` 伝播: ランタイムで **強エッジのみ** 再帰。`Safepoint` で分割解放/優先度解放に対応
---
## バックエンド指針（対応表）
* **Interpreter**: 25命令を素直に実装（正しさの基準）
* **VM**: Register-VM + direct-threading。`Send/Recv` はローカル判定時にインライン化
* **WASM**: `Send/Recv` は host import。`MemCopy` は `memory.copy` に対応
* **Cranelift/JIT**: `TailCall` 最適化、`WeakLoad` は世代タグでO(1)生存チェック
* **AOT-Rust**: `BoxCall` を trait 呼び出しへ、`Adopt/Release` は所有者IDの切替 + デバッガ用アサート
---
## 互換テスト（常設）
* **golden MIR**: 各サンプルのMIRダンプが全バックエンドで一致
* **行動一致**: `interp/vm/wasm` で**同入力→同出力**（`weak`失効時の`null/false`含む）
* **性能スモーク**: `add_loop / map_getset / alloc_free / bus_local / bus_actor` の5種で、
* VMがinterp以上、WASMがVM以上、を継続検証
---
これで **25命令フルセット**が完成。
* Nyashのコア価値（所有森＋weak＋Bus＋効果注釈）を**無理なくIR化**
* それぞれのバックエンドに**綺麗に落ちる**
* Verifier/最適化/テストも**最小で回る**
次は、このリストをそのまま `docs/mir.md` にコピペして、各命令に **1行の意味論＋効果＋等価変換の例** を添えれば、実装と論文の両方が一気に前進するにゃ。

596
docs/development/roadmap/native-plan/archives/chatgptネイティブビルド大作戦.txt Normal file
View File

@ -0,0 +1,596 @@
ぜったいアリにゃ！やるなら「多層エンジン（tiered）」で攻めるのが一番きれい。
Nyash → 共通IR → 好きなバックエンド（解釈/ネイティブ/JIT/WASM）に流す構成にゃ。
推しアーキテクチャ（現実解）
Front-end
パーサ → AST → HIR（型付け・名前解決済み）→ MIR/SSA（最適化しやすい共通IR）
Back-ends（並行に育てる）
VM（現在のインタープリター）：MIR→バイトコード→解釈実行（開発スピード最優先）
JIT（Cranelift）：MIR→Cranelift IR→ネイティブJIT（ホットパスだけコンパイル）
AOT to Rust：MIR→Rustコード生成→rustcで最適化（配布バイナリ向き、リンクも楽）
WASM：MIR→WASM（ブラウザ/wasmtime用、サンドボックス実行）
ひとつのIRから複数出力＝最適化ロジックを1か所に集中できるのが最大の利点。
【Phase 0: 最小ビルド基盤（最初のゴール）】
狙い: 「簡単なNyash言語がビルドできる」を最速・堅実に達成する。土台はシンプルだが確実に動くことを最重視。
1) スコープ（最小言語機能）
- 式: 整数/文字列リテラル、変数参照、二項演算 (+,-,*,/, 比較)
- 文: 代入、if、return
- 関数: 単純な関数定義/呼び出し（可変長やジェネリクスは対象外）
- Box/弱参照/fini 等の高機能はPhase 0では“使わない”（この計画の安定化が目的）
2) ビルドターゲット（まずはCLIのみ）
- Linux/WSL: cargo build --bin nyash -j 32（現状OK）
- Windows (MSVC): cargo build --bin nyash -j 32（CIでも検証）
- WASM: ひな型を残すがPhase 0では対象外（Phase 1で着手）
3) 実行確認（スモークテスト）
- サンプル: local_tests/ 以下に簡単な .nyash を配置（Git管理外）
例) sample_min.nyash
a = 10
b = 32
result = a + b
- 実行: cargo run -- ./local_tests/sample_min.nyash
- 期待: 実行完了・エラーなし（必要なら結果表示）
4) 再現性/安定性（基礎をしっかり）
- rust-toolchain を固定（stable明記）
- Linux/Windows 共通のビルドフラグ: release/profileの統一、features最小化
- 例やGUI/Windows依存コードはCIマトリクスから除外（CLI最小に絞る）
5) CI（Phase 0の完成条件）
- ジョブ: linux-x64, windows-x64 での “build nyash (bin)”
- コマンド: cargo build --bin nyash -j 32
- 成果物: nyash バイナリ（zip/tar）をArtifactsに保存（配布検証）
- 余裕があれば: cargo test --lib だけ実行（examplesは無効）
6) トラブル防止（Phase 0の運用）
- Linux CIでWindows専用exampleはビルド対象から除外
- examples/* はPhase 0では“参考”扱い。CLIのビルド/実行に集中。
- .nyash の共有が必要なものは tests/ 配下へ昇格（local_tests/ は各自ローカル）
7) 完了チェックリスト
- [ ] Linux/WSL で nyash バイナリがビルド・実行できる
- [ ] Windows(MSVC) で nyash バイナリがビルド・実行できる
- [ ] CI で linux/windows の “build nyash (bin)” がグリーン
- [ ] sample_min.nyash のスモークが両OSで通る
補足: Phase 0 で「ビルド/実行の骨格」を固めて、Phase 1 以降で VM/IR/JIT/AOT/WASM を段階的に拡張する。
それぞれのメリデメ
【MIR設計（早期に合意しておくと得する要点）】
- 値表現: Tagged/NaN-box/小整数直格納 か 型テーブル参照か
- アドレス空間: ヒープ/スタック/アリーナの扱い（Phase 0はヒープ優先でOK）
- 所有/別名: aliasable/unique の属性を型/値に保持（最初は型情報だけでも可）
- 効果(Effects): PURE/READS_HEAP/WRITES_HEAP/IO/FFI/PANIC のビット集合を命令・関数に付与
- 例外/パニック: Throw/Catch/Defer を命令化するか、関数境界に限定するか（当面は境界限定）
- GCモデル: Tracing/RC/混合の方針と弱参照の意味（WeakLoad→None）
- セーフポイント: 関数入口・ループ先頭・Call直後（命令としてno-op挿入で開始）
- 呼出規約: 通常Call/FFI/Box拡張を区別、可変長/キーワード引数の扱い（Phase 0は固定引数）
- メモリバリア: write/read barrier は命令/属性で表現（初期はダミー実装で可）
- デオプ(Deopt): JIT最適化時の巻き戻し情報の格納場所（関数メタ or ブロック注釈）
【Nyash向け 最小MIR命令セット（弱参照対応込み・ドラフト）】
- 制御/値: Const, BinOp, Cmp, Br, Jmp, Phi, Ret
- 呼び出し: Call, TailCall（effects必須）
- メモリ: Alloc, Load, Store, Gep(必要なら)
- 参照/GC: RefNew, RefGet, RefSet, WeakNew, WeakLoad, BarrierRead, BarrierWrite, Pin, Unpin
- 例外/拡張: Throw, Catch, FfiCall, BoxCall
- 実行点: Safepoint, Assume, Nop
- 効果: EffectMask = PURE | READS_HEAP | WRITES_HEAP | IO | FFI | PANIC
弱参照の意味論:
- WeakNew(r): r を追う弱参照を作成（PURE）
- WeakLoad(w): 生きていれば Some(Ref)、死んでいれば None（Option<Ref>を型で明示）
【壊れにくい共通ポイント（VM/JIT/AOT共通の約束）】
- Safepoint は 関数入口/ループ先頭/Call直後 に配置（no-opで開始し、後で意味付け）
- Barrier 命令は最初はダミー（最適化段で消せる）
- Null/None は Option<Ref> で明示（分岐に埋めない）
- JIT は Deopt テーブルで SSA値⇔ソース位置 の対応を保持
【弱参照の落とし穴（回避策セット）】
- クロージャ環境: 生成時 env.has_weak を立て、キャプチャ解決時に必ず WeakLoad→None分岐を強制
- 弱参照キーのハッシュ: GC後の無効化で不整合→ 標準の弱マップ（キー死亡で自動削除）を用意
- FFI渡し: 寿命不明→ Pin を要求 or WeakLoad 成功した生参照のみ渡す
【テスト戦略（壊れにくい順）】
- 黄金テスト: ソース→MIRダンプをスナップショットし、差分で後退検知
- VM/JIT一致テスト: 同一入力の VM 結果＝JIT 結果 を比較するオラクル
- 弱参照の確率テスト: alloc→weak→drop→collect→weak_load の順序/タイミングをゆらして多数回
- 効果チェック: PURE なはずの関数に WRITES_HEAP が混じったらビルド失敗（静的検証）
【軽量 “次の一手”（Phase 0と親和性が高い）】
- WeakNew/WeakLoad を MIRとVM に先に導入（JITは後回し）
- EffectMask をデータ構造として追加（評価は後回しでもOK）
- Safepoint 命令を関数入口・ループ先頭にno-opで挿入
- 黄金テストでMIRダンプをCIに可視化（Phase 0のCLIビルドと併走）
VM：実装が速い／デバッグ容易｜最高速は出ない
Cranelift JIT：実行時最適化で爆速／実装難度は中｜起動コストあり
AOT→Rust：rustc最適化の恩恵・配布しやすい｜コード生成器の保守が要る
WASM：移植性・安全｜ネイティブよりは遅め（ただしwasmtime/wasmerで結構速い）
まずやる順序（最短で“速い”を得る）
共通MIR/SSAを切る（基本ブロック・SSA・型/効果情報）
VMを MIR→バイトコード に置き換え（インタープリターの土台を共通化）
Cranelift JIT を載せる（ホット関数だけJIT）
並行で Rustコード生成 の雛形を作る（AOT配布の道を確保）
余力で WASM 出力（エディタ内実行やブラウザデモに最適）
Nyash流にハマる設計ポイント
Box拡張のABIを先に決める
呼出規約：fn nyash_box_call(ctx: &mut Ctx, args: &[Val]) -> Result<Val>
メモリ：Arc<[Val]> か Arena で一時領域を明示（GCを後回しにできる）
所有権/借用に似た効果注釈をMIRに入れる
「純粋」「可変」「外部副作用あり」をフラグ化→最適化と並列実行の判断に使える
定数畳み込み/死コード除去/インライン化はMIR段階で実施
プロファイラを最初から同梱（どの関数をJIT/AOTに送るか判定）
最小プロトタスク（1〜2週間スプリント想定）
HIR/MIRスキーマ確定（基本ブロック・命令セット・型表現）
MIR→バイトコード変換器／VMループの実装
プロファイル計測（関数実行回数・時間）
Craneliftで fn 単位JIT（整数演算と分岐から）
簡易 Rustコード生成（fn add(a:i64,b:i64)->i64 などから）
Box ABI v0（同期版）＋サンプル拡張（数値/文字列ユーティリティ）
ちょいサンプル（超概念）
enum MirInst {
Const(ValId, ConstVal),
BinOp(ValId, ValId, Op, ValId),
Call(ValId, FuncId, Vec<ValId>),
Phi(ValId, Vec<(BlockId, ValId)>),
// ...
}
struct MirFunc { blocks: Vec<MirBlock>, signature: Sig, effects: Effects }
trait Backend {
fn compile(&mut self, f: &MirFunc) -> CompiledFn;
}
VM backend: compile = バイトコード化
JIT backend: compile = Cranelift IR生成→jit_func
Rust backend: compile = fn ... { ... } のRust文字列出力→rustcでAOT
「いまのNyashソース」を見れたら、MIR命令セットの初版とJIT/AOTの足場コードをすぐ書き起こせるよ。
まずは MIRの最小命令リストを一緒に決めよっか？（算術・比較・分岐・Call・Phi・Load/Store 相当）
あなた:
くわしくききたにゃ　Front-end
パーサ → AST → HIR（型付け・名前解決済み）→ MIR/SSA（最適化しやすい共通IR）パーサーで解析してＡＳＴは木構造だよね？　そこからどういう処理にゃ？
ChatGPT:
いいね、その流れを実務目線でがっつり分解するにゃ。
キーワードは「情報を徐々に確定させつつ“最適化しやすい形”へ落としていく」。
Nyash流に当てはめて、各段階で“何を追加・削除・変換するか”を整理するよ。
Front-end 全体像
ソース → Lexer → Parser(AST) → スコープ/名前解決 → 型推論/型検査(HIR) → 糖衣剥がし(Desugar) → 制御フロー化(CFG) → SSA化/効果注釈(MIR/SSA)
1) Parser → AST（抽象構文木）
目的：構文だけを正しく捉える。意味（型/名前）はまだ未確定。
データ構造（例）
enum AstExpr {
LitInt(i64),
Var(Symbol),
Call{ callee: Box<AstExpr>, args: Vec<AstExpr> },
Lambda{ params: Vec<AstParam>, body: Box<AstExpr> },
If{ cond: Box<AstExpr>, then_e: Box<AstExpr>, else_e: Box<AstExpr> },
Let{ pat: AstPat, init: Box<AstExpr>, body: Box<AstExpr> },
// … match, while, for, block, …
}
まだやらないこと
シンボルの多義性解決（foo がローカルか、モジュールか、メソッドか）
型の決定
糖衣構文の展開
2) スコープ構築 & 名前解決（AST上の解決）
目的：識別子を定義元に結びつける。未定義やシャドーイングもここで判定。
やること
ブロックスコープ/関数スコープ/モジュールスコープの**環境（symbol table）**を構築
use/import、module、with 的な構文を解決
各 Var(Symbol) を DefId（定義へのID）にひも付け
成果物：
解決済みAST or ここで HIR に写経（次段のために構造を少し整える）
3) 型推論 & 型検査 → HIR（型情報付きIR）
目的：式ごとに型を確定し、オーバーロード/ジェネリクスを具体化できる所まで進める。
型推論（Hindley–Milner＋制約ベースなど）
let x = 1 + f(y) なら、f: T -> i64 みたいな制約を立てて解く
オーバーロード解決 / メソッド解決（a + b → 実体メソッドやトレイト関数に解決）
ジェネリクス
可能ならモノモーフィック化（型実引数が確定している呼び出しは単相化）
未確定なら型パラ付きのまま保持
データ構造（例）
struct HirExpr {
kind: HirExprKind,
ty: TyId, // ここが肝：各式に型が付く
effect: EffectMask, // 純粋/可変/外部副作用 など（後述の最適化で効く）
}
enum HirExprKind {
LitInt(i64),
Local(DefId),
Call{ fun: Box<HirExpr>, args: Vec<HirExpr>, resolved: FunId },
If{ cond: Box<HirExpr>, then_e: Box<HirExpr>, else_e: Box<HirExpr> },
// 糖衣はまだ残っていてもOK
}
エラー検出
型不一致、未初期化、到達不能、借用/所有に関する静的規則（Nyash流に簡易化しても良い）
4) 糖衣剥がし（Desugaring）
目的：意味は同じだが最適化しづらい構文を、プリミティブな形に落とす。
例
for x in iter { body } → let mut it = iter.into_iter(); while let Some(x) = it.next() { body }
a && b → if a { b } else { false }（短絡を明示化）
パターン束縛 let (a,b) = e; → 一時変数＋個別bind
クロージャ → 明示キャプチャ＋ラムダ表現を正規化
この段階で構文のバリエーションは減らして、後段のCFG/SSA化を楽にする
5) 制御フローグラフ（CFG）作成
目的：式主導（式木）を基本ブロック＋ジャンプへ落とす。
最適化やSSA化の土台になる。
ブロック（BasicBlock）単位で命令列を持つ
例：if/else は br cond thenBB elseBB に分解
while は loopBB / bodyBB / exitBB に分解
ここで**一時変数（tmp）**を導入して、「値がどのブロックから来るか」を明示できるようにする
6) SSA化（Static Single Assignment）
目的：各変数が“ちょうど一度だけ代入”される形に変換。
最適化（定数畳み込み・コピー伝播・死コード除去・ループ最適化）がやりやすくなる。
φ関数（Phi）を導入
分岐合流点で「どのブロックから来た値か」に応じて値を選ぶ
データ構造（MIR/SSA例）
enum MirInst {
Const{ dst: V, c: ConstVal },
BinOp{ dst: V, op: Op, a: V, b: V },
Call{ dst: V, fun: FnId, args: Vec<V>, effects: EffectMask },
Br{ cond: V, then_bb: Bb, else_bb: Bb },
Jmp{ bb: Bb },
Phi{ dst: V, inputs: Vec<(Bb, V)> },
Store{ ptr: V, val: V }, // メモリ命令を分離しておくと最適化が楽
Load{ dst: V, ptr: V },
Ret{ v: Option<V> },
}
struct MirFunc { blocks: Vec<MirBlock>, sig: Sig, effects: EffectMask }
ここまでで最適化の主戦場が整う
7) 効果注釈（Effects）と簡易別解（所有/借用に近いもの）
目的：最適化・並列化・Box拡張の安全性判定に使う副作用情報を付与。
例：PURE, READS_HEAP, WRITES_HEAP, IO, FFI, PANIC, THROW などのビットフラグ
呼び出し先の効果を合成して、関数単位の effects: EffectMask を確定
→ 並列実行可否、共通部分式除去可否、コードモーション許可範囲に使える
8) 代表的な変換の“実例”で見る
Nyash（仮）：
let x = 10
let y = 20
if x < y {
print(add(x, y))
} else {
print(y)
}
AST（ざっくり）
Let(x, 10)、Let(y, 20)、If( BinOp(<, Var(x), Var(y)), Call(print, …), Call(print, Var(y)) )
HIR（型付け・解決済み）
x: i64, y: i64
add: (i64,i64)->i64, print: (i64)->Unit
Desugar
ほぼそのまま（ここでは糖衣なしと仮定）
CFG→SSA（MIRの一部）
bb0:
v1 = Const 10
v2 = Const 20
v3 = BinOp Lt v1 v2
Br v3 then=bb1 else=bb2
bb1:
v4 = Call add(v1, v2) ; PURE
Call print(v4) ; IO
Jmp bb3
bb2:
Call print(v2) ; IO
Jmp bb3
bb3:
Ret ()
（print は IO 効果、add は PURE、関数全体は IO を持つ、などが付与される）
よくある疑問Q&A
Q. AST→HIRでどこまで“形を変える”？
A. 基本は意味解決のための注釈（DefId, TyId, Effect）を付けるのが主。大きな形の変換（ループ展開やパターン展開）はDesugar段でやると見通しが良い。
Q. なんでSSA？バイトコードでも良くない？
A. VM用のバイトコードは実行が簡単。でも最適化はSSAの方が圧倒的に楽。
→ 「MIR/SSAで最適化」→「VM向けバイトコードに落とす」or「JIT/AOT」がおすすめ。
Q. パターンマッチは？
A. Desugarで決定木（decision tree）に落としてからCFG化。ガード節や順序付きパターンも木→ブロック分割で表現できる。
Q. クロージャのキャプチャは？
A. 名前解決で囲い込み変数を収集→HIRに明示キャプチャとして埋める。
MIRでは環境レコードを値として扱う（{env_ptr, fn_ptr}）。
まず作ると捗る“ミニ仕様”
Symbol/DefId/Scope：解決器のAPI
Ty：原始型・関数型・代数的データ型（Sum/Product）・型変数
EffectMask：ビットフラグ設計（PURE/READ/WRITE/IO/FFI など）
MIR命令セット（最小）：Const/BinOp/Call/Br/Jmp/Phi/Ret＋Load/Store
Pass順序：
名前解決 → 2) 型推論 → 3) Desugar → 4) CFG → 5) SSA → 6) 直近の最適化（const fold / dce / copy-prop）
必要なら、いまのNyashのAST型定義をベースにHIR/MIRの骨組みを一緒に設計するよ。
“最初のMIR命令セット案”
“名前解決テーブルと参照の貼り方”
“効果注釈のフォーマット”
この3点を固めるだけで、JIT/AOT/VMバックエンドの土台が一気に整うにゃ。
あなた:
おおう　これと　さっきの　　Back-ends（並行に育てる）
VM（現在のインタープリター）：MIR→バイトコード→解釈実行（開発スピード最優先）
JIT（Cranelift）：MIR→Cranelift IR→ネイティブJIT（ホットパスだけコンパイル）
AOT to Rust：MIR→Rustコード生成→rustcで最適化（配布バイナリ向き、リンクも楽）
WASM：MIR→WASM（ブラウザ/wasmtime用、サンドボックス実行）　これの話要約してにゃ claude code君にみせてくるにゃ
ChatGPT:
了解にゃ、Claude Code君向けに要点だけギュッとまとめるよ。
Nyashコンパイルパイプライン案
Front-end（共通部分）
Parser → AST
ソースを構文木（AST）に変換。型や意味はまだ未確定。
名前解決 & スコープ構築
識別子を定義元に紐付ける（DefId付与）。
型推論 & 型検査 → HIR
各式に型情報（TyId）と効果注釈（EffectMask）を付与。
糖衣剥がし（Desugar）
forループやパターン束縛をプリミティブ構造へ展開。
制御フロー化（CFG）→ SSA化（MIR）
ASTを基本ブロックとSSA命令列（MIR）へ変換。
命令例：Const, BinOp, Call, Br, Jmp, Phi, Load, Store, Ret。
Back-end（並行開発可能）
VM（現行インタープリター）
MIR → バイトコード → 解釈実行（開発スピード優先）
JIT（Cranelift）
MIR → Cranelift IR → 実行時にネイティブコード化（ホットパスだけ）
AOT to Rust
MIR → Rustコード生成 → rustc最適化＆リンク → 配布可能なネイティブバイナリ
WASM出力
MIR → WASM（ブラウザ実行やサンドボックス用）
💡 ポイント
すべてのバックエンドは共通MIRを入力にするため、最適化は1か所で集約。
Box拡張もMIRレベルで統一呼び出し可能。
VMは開発・デバッグ用、JITは実行高速化、AOTは配布、WASMは移植性重視。
Nyashは**「最初から最後までモジュール拡張が一貫して動く多層言語」**という珍しい立ち位置になるにゃ。
希望あれば、これ一般的なコンパイラ構成との比較表にして、Claude Code君がすぐ違いを理解できる形にまとめることもできるよ。
どうする、作っちゃう？
あなた:
おねがいにゃー！
ChatGPT:
了解にゃー！Claude Code君に渡しやすいよう、「一般的な構成 vs Nyash流（＋α）」比較表にギュッとまとめたよ。
Nyash 設計：一般的な方法との比較
観点 一般的なコンパイラ設計 Nyash（＋α）
フロントエンド Parser → AST →（解決/型付け）→ IR Parser → AST → HIR（型/解決/効果）→ MIR/SSA（最適化前提）
中間表現(IR) 単一IR or バイトコード中心 HIR/MIR二段構え、MIRはSSA＋効果注釈で最適化容易
効果/副作用 多くは最適化時に暗黙扱い EffectMask（PURE/READ/WRITE/IO/FFI…）をMIRに明示し並列化・最適化の判断に使用
拡張/FFI 後付けのFFI/プラグインが多い Box拡張を一級市民化。MIRレベルで統一コール形態を定義（VM/JIT/AOT/WASMで一貫）
バックエンド VM→（後からJIT/AOT） VM/JIT（Cranelift）/AOT-to-Rust/WASMを最初から並行開発できるMIR設計
実行戦略 単層（解釈 or JIT）になりがち Tiered：VMで即起動→ホットパスJIT→配布はAOT→ブラウザはWASM
AOT配布 LLVM等のHPCルートが主 MIR→Rustコード生成→rustc最適化（ツールチェーン流用・リンク容易）
ブラウザ/サンドボックス 別途WASM対応 MIR→WASMを標準ターゲット化（wasmtime/wasmer/ブラウザ即動作）
最適化の主戦場 バイトコード最適化/バックエンド依存 MIR/SSAで集約最適化（const fold, DCE, copy-prop, inlining, loop opts）
並列化の足場 後付け解析が多い 効果注釈×データ依存で安全な並列化やコードモーションを許可
デバッグ/開発速度 VMが主、JITは後追い VMで素早く検証しつつ、同一MIRをJIT/AOTに供給（回収効率◎）
配布/運用 ネイティブ or VM同梱 用途別に最適バイナリ（AOT）とスクリプタブル運用（VM）を両取り
リスク/留意点 単純で保守容易 設計は強力だが初期定義が要（MIR命令/Effect設計、Box ABIを固める）
補足：最小ロードマップ（実装順）
HIR/MIRの骨組み確定（命令セット・EffectMask・Box ABI v0）
**VM（MIR→バイトコード）**で先に全機能を回す
プロファイラ同梱（ホット関数をJIT/AOTに回す条件づけ）
Cranelift JIT（算術＋分岐→関数呼び出し→Box呼び出し）
AOT to Rust の雛形生成（小関数から）
余力で MIR→WASM（最小機能から）
この表ごと貼れば、Claude Code君も**「王道＋Nyashの差分」**を一目で把握できるはずにゃ。必要なら、MIR命令セット 初版案も続けて出すよ！
あなた:
mirまでできればかちなのにゃね。これって定番なのあるにやゃ？　言語ごとにやっぱりちがうにゃ？
ChatGPT:
そうにゃ、MIRまで作れれば言語設計はもう“勝ち”に近いにゃ。
なぜかというと、MIRは「全バックエンドの共通土台」だから、
一度そこまで作れば VM/JIT/AOT/WASM ぜんぶに展開できるにゃ。
🔹 MIRは定番があるの？
完全な共通規格はない
→ LLVM IR や WebAssembly のような「広く使われる IR」はあるけど、
言語ごとに構文や型システムが違うから MIRはだいたい自作になる。
多くの言語は「MIR」じゃなくても似た段階を持ってるにゃ：
Rust → MIR（所有権/借用も反映されたSSA形式）
Swift → SIL
Go → SSA IR
Kotlin → Kotlin IR
Python（PyPy）→ Flow Graph → SSA IR
JavaScript（V8）→ Bytecode IR → TurboFan IR
🔹 言語ごとに違うポイント
型情報の粒度
RustのMIRは「型完全一致」必須。
Python系は動的型なので「型タグ＋ランタイム判定」入り。
命令セットの抽象度
LLVM IRはハード寄り（ポインタ/レジスタ操作あり）。
Rust MIRやKotlin IRは言語構造寄り（ループ/パターンマッチ命令など残す）。
所有権・副作用の扱い
Rust MIRは「所有権」も追跡する。
多くの言語は副作用は型ではなく命令属性で管理。
最適化の前提
一部は最適化前提で作る（SSA化必須）。
他は単にバックエンド入力の中間形式。
🔹 Nyashでのおすすめ方針
Rust MIRに近い構造を真似るのが安全
静的型の要素が入ってるので、AOTや最適化に有利
EffectMaskやBox拡張の情報も一緒に持たせられる
命令はなるべく 「言語仕様に沿った中間レベル」 にして、
バックエンド変換時に低レベル化する
SSA化は最初からやる（後から入れるのは地獄）

1193
docs/development/roadmap/native-plan/archives/copilot_issues_20250814_145100_full.md Normal file
View File

File diff suppressed because it is too large Load Diff

657
docs/development/roadmap/native-plan/archives/copilot_issues_phase0_to_94.txt Normal file
View File

@ -0,0 +1,657 @@
# 🤖 Copilot様 作業予定・課題整理 (Phase 0-9.4 アーカイブ版)
# Generated: 2025-08-14 (Git履歴から復元・更新)
# Purpose: Claude×Copilot協調開発のための情報共有
# Status: Phase 9.5より前のアーカイブ版（2025-08-15分割）
================================================================================
🎯 次期最優先タスク (Phase 8.5以降)
================================================================================
## 🚀 Phase 8.4完了報告 (2025-08-14)
Status: ✅ 完了 (Copilot PR #56マージ済み)
### ✅ AST→MIR Lowering完全実装
- User-defined Box: `box DataBox { init { value } }`
- Object creation: `new DataBox(42)`
- Field access: `obj.value`
- Method calls: `c.increment()`
- Delegation: `from Parent.greet()`
- Static Main互換性維持
### 🧪 統合テスト結果（2025-08-14）
- ✅ **AST→MIR**: 完全動作
- ✅ **インタープリター**: 完全動作（結果30）
- 🚨 **VM**: 動作するが結果が`void`（要修正）
- 🚨 **WASM**: String constant未対応（Phase 8.5で解決）
### 📋 発見された課題
- VM実行結果問題: BoxCall後の戻り値が正しく返らない
- WASM対応不足: 複雑なMIR命令（String constant, BoxCall）に未対応
- 次期Phase 8.5での25命令MIR階層化が必要
================================================================================
## 🔧 Phase 8.5: MIR 26命令階層化（最優先）
Status: ⭐ **CRITICAL**
Priority: **最重要** (Phase 8.4完了直後の次期目標)
### 🎯 実装目標
ChatGPT5 + AI大会議決定版26命令MIR実装（ExternCall追加）
- 期間: 3週間
- 効果: VM/WASM問題根本解決
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md`
### 📋 26命令セマンティック階層化
**Tier-0: 普遍コア（8命令）**
```mir
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```
**Tier-1: Nyashセマンティクス（13命令）**
```mir
NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, ExternCall, Safepoint,
RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
```
**Tier-2: 実装補助・最適化友好（5命令）**
```mir
TailCall, Adopt, Release, MemCopy, AtomicFence
```
### 🎯 期待される効果
- **VM問題解決**: BoxCallの正しい実装で戻り値問題修正
- **WASM対応**: 階層化により複雑MIR→単純WASM変換
- **Everything is Box**: BoxFieldLoad/Storeで明確なBox中心設計
- **JIT準備**: セマンティクス保持で高度最適化基盤確立
================================================================================
## 🏎️ Phase 8.6: VM性能改善（緊急）
Status: 🚨 **緊急**
Priority: **High** (Phase 8.5完了後)
### 🚨 緊急問題
**現状**: VM（119.80ms）< Interpreter（110.10ms）= 0.9倍の性能劣化
**新問題**: VM BoxCall後の戻り値が`void`（Phase 8.4テストで発見）
### 📋 技術的課題
- VM実行エンジンのプロファイリング
- 命令ディスパッチ最適化（threaded code等）
- レジスタベースVM化検討
- メモリプール最適化
- BoxCall実装修正（戻り値問題）
### 🎯 成功基準
- VM性能 > Interpreter性能（最低2倍目標）
- BoxCall戻り値の正常動作
- MIR→VM変換時間の短縮
================================================================================
## 🧪 Phase 8.7: Real-world Memory Testing
Status: 📋 **計画済み**
Priority: **High** (Phase 8.5-8.6完了後)
### 🎯 実装目標
kilo（テキストエディタ）実装によるfini/weak参照システム実証
- 期間: 2週間
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md`
### 📋 検証項目
- 1000+オブジェクト管理テスト
- 循環参照回避確認（weak参照）
- fini()伝播の正確性確認
- WASM環境での動作確認
================================================================================
🗺️ Phase 0-14 全体ロードマップ (復元完了)
================================================================================
## Phase 0: Stabilize native CLI build (Linux/Windows)
Summary:
- CLIバイナリ nyash を最小構成で安定ビルド・実行できる状態にする。
- examples/GUI をデフォルトのビルド対象から外し、開発の足場を固める。
Why:
- 以降の MIR/VM/JIT 開発を素早く検証できる基盤づくり。
Scope:
- Cargo の features で GUI/examples 等を切り分け、デフォルトは CLI 最小にする。
- CLI オプションの動作点検（--dump-mir / --verify）。
- ローカル実行導線を README に明記（docs/guides/how-to-build-native/README.md）。
Tasks:
- Cargo.toml: examples/GUI を feature でガード（default は CLI 最小）。
- ビルド検証: `cargo build --bin nyash`（Linux/Windows）。
- 実行検証: `cargo run -- ./local_tests/sample.nyash`。
- ドキュメント: 上記手順を how-to-build-native に追記/点検。
Acceptance Criteria:
- Linux/Windows で `cargo build --bin nyash` が成功する。
- `local_tests/` 配下の簡単な .nyash が実行できる。
- 他 bin/examples が壊れていても `--bin nyash` だけで通る。
Out of Scope:
- examples/GUI の修理・最適化。
- JIT/AOT/WASM。
References:
- docs/guides/how-to-build-native/README.md
- docs/nativebuild大作戦/chatgptネイティブビルド大作戦.txt（Phase 0）
- CURRENT_TASK.md
Copilot Notes:
- まずは features 分離と `--bin nyash` でビルドが通る状態を作る。README の手順確認まで含めて PR に反映。
------------------------------------------------------------
## Phase 1: Minimal MIR + VM backend (lowering + runner)
Summary:
- AST → MIR の最小 lowering と、VM バックエンドでの実行を通す。
Scope:
- MIR: Const, BinOp, Compare, Branch, Jump, Phi, Return の最小命令
- Lowering: リテラル/二項演算/if/loop/return のみ
- VM: 上記命令の最小実装
Tasks:
- instruction.rs: 最小命令の定義
- builder.rs: 上記 AST 範囲を lowering
- vm.rs: 実装 + stats（命令数）
Acceptance Criteria:
- `--dump-mir` が最小サンプルで期待通り
- `--backend vm` で実行して結果一致
Out of Scope:
- 例外/関数/Box 参照/弱参照
------------------------------------------------------------
## Phase 2: Control-flow coverage (if/else/loop/phi correctness)
Summary:
- 制御フローの網羅と Phi の整合性検証を拡充。
Scope/Tasks:
- if/else nested, loop with breaks, nested loops のスナップショット
- Phi の入力ブロック/値の対応を Verifier で強化
Acceptance Criteria:
- 代表制御フローの snapshot が安定し、verify も通る
------------------------------------------------------------
## Phase 3: Exceptions (throw/try/catch/finally) minimal lowering
Summary:
- 例外機構の最小 lowering を導入（詳細設計は簡素）。
Scope/Tasks:
- MIR: Throw, TryBegin/TryEnd, Catch, FinallyBegin/End（最小）
- builder.rs: try/catch/finally ノードの下ろし
- VM: 例外伝播を最小で（未捕捉はエラー）
Acceptance Criteria:
- 代表 try/catch/finally のスナップショットと VM 実行
Out of Scope:
- 例外の型体系、詳細な stack map
------------------------------------------------------------
## Phase 4: Functions and calls (BoxCall minimal)
Summary:
- 関数呼び出し/BoxCall を最小導入（効果注釈は保守的）。
Scope/Tasks:
- MIR: Call, BoxCall（effects = READS_HEAP など保守）
- builder.rs: FunctionCall/MethodCall の最小対応
- VM: 呼び出し/戻り値
Acceptance Criteria:
- 簡単な関数定義/呼び出しの MIR/VM が通る
Out of Scope:
- 可変長/キーワード引数、FFI
------------------------------------------------------------
## Phase 5.0: Parser/AST stabilization for lowering
Summary:
- lowering 対象 AST の表現ぶれを修正、安定化。
Scope/Tasks:
- AST: If/Loop/Return/Assignment/Local などの統一
- Parser: エラー復帰/スパン情報の見直し
Acceptance Criteria:
- builder.rs の分岐がシンプル化、テストが安定
------------------------------------------------------------
## Phase 5.1: Control-flow edge cases + verifier hardening
Summary:
- ブロック未終端/未到達/自己分岐等の検証強化でクラッシュ回避。
Scope/Tasks:
- Verifier: 未終端ブロック検出、到達不能検出
- Builder: Jump/Branch の生成前後の状態管理改善
Acceptance Criteria:
- 不正ケースを含むスナップショット/verify が緑
------------------------------------------------------------
## Phase 5.2: Lowering for static box Main (BoxDeclaration → main body)
Summary:
- static box Main { main() { ... } } を MirBuilder で受け、main() の body を Program として lowering する経路を実装。
Scope/Tasks:
- AST: BoxDeclaration(is_static=true, name=Main) を検出 → main() を抽出
- Lowering: body を Program に変換して既存経路に渡す
- Tests: local_tests/mir_loop_no_local.nyash で dump/VM が通る
Acceptance Criteria:
- `--dump-mir` が static Main サンプルで成功
- `--backend vm` で実行成功
References:
- docs/guides/how-to-build-native/issues/phase5_2_static_main_lowering.md
------------------------------------------------------------
## Phase 6: Box ops minimal (Ref/Weak + Barriers no-op)
Summary:
- 参照/弱参照/バリア（no-op）を最小導入。
Scope/Tasks:
- MIR: RefNew/RefGet/RefSet/WeakNew/WeakLoad/BarrierRead/Write
- Lowering: New/FieldAccess/MethodCall の最小対応
- VM: 参照テーブル/weak テーブルで動作（fini 不変は維持）
Acceptance Criteria:
- 代表サンプルで dump/VM/verify が通る
References:
- docs/guides/how-to-build-native/issues/phase6_box_ops_minimal.md
------------------------------------------------------------
## Phase 7: Async model (nowait/await) in MIR
Summary:
- nowait/await を MIR に導入し、現行 FutureBox と連携。
Scope/Tasks:
- MIR: FutureNew/FutureSet/Await（スレッドベース）
- Lowering: nowait→Future 作成、await→wait_and_get
- VM: FutureBox 実装を利用
Acceptance Criteria:
- 代表ケースで正しく並行実行→await 回収
References:
- docs/guides/how-to-build-native/issues/phase7_async_mir.md
------------------------------------------------------------
## Phase 8: MIR→WASM codegen (browser/wasmtime; sandboxed; Rust runtime free)
Summary:
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
- Rust はコンパイラ本体のみ。実行は純WASM＋ホストimport（env.print など）。
Scope/Tasks:
- ABI/Imports/Exports 定義（exports: main/memory、imports: env.print(i32) 等の最小）
- 線形メモリと簡易ヒープ（bump/自由リスト）
- 命令カバレッジ（段階導入）: 算術/比較/分岐/loop/return/print、RefNew/RefSet/RefGet（Phase 6 整合）、Weak/Barrier はダミー
Acceptance Criteria:
- wasmtime 実行で戻り値/print が期待通り（PoC1–2）
- Ref 系がメモリ上で正しく動作（PoC2）
- Weak/Barrier のダミー実装を含むWASMが生成・実行（PoC3）
- CLI `--backend wasm` は未実装でもよいが、実装する場合は明瞭にエラーメッセージ/誘導
References:
- docs/予定/native-plan/README.md（Phase 8 節）
- docs/説明書/wasm/*（ユーザー向けメモ）
### Phase 8.3 完了状況 (2025-08-14)
✅ Box操作WASM実装 (RefNew/RefGet/RefSet)
✅ ベンチマークシステム統合 (13.5倍実行高速化実証)
✅ CLI統合完了
------------------------------------------------------------
## 🔧 Phase 8.4: AST→MIR Lowering完全実装 (最優先)
Summary:
- ユーザー定義Box、フィールドアクセス等の未実装部分を完成
- Phase 8.3のBox操作WASMを実際にテスト可能にする
Priority: **Critical** (現在の最優先事項)
Expected Duration: 1週間
### 実装範囲
- [ ] ユーザー定義Box: `box DataBox { init { field } }`
- [ ] オブジェクト生成: `new DataBox()`
- [ ] フィールドアクセス: `obj.field`
- [ ] フィールド代入: `obj.field = value`
- [ ] from構文: `from Parent.method()`
- [ ] override構文: `override method() { ... }`
### 成功基準
- Phase 8.3のBox操作WASMが実際に動作
- test_wasm_box_ops.nyash が正常実行
- ユーザー定義Boxの完全サポート
------------------------------------------------------------
## 🧠 Phase 8.5: MIRセマンティック階層化（AI大会議決定版）
Summary:
- 方針転換: ChatGPT5の20命令intrinsic戦略 → Gemini+Codex一致推奨の26命令階層化（ExternCall追加）
- 理由: JIT/AOT最適化阻害・Everything is Box意味喪失・長期コスト増の問題判明
- 二相ロワリング: 26命令維持パス（VM/JIT/AOT）+ 21+intrinsic降格パス（WASM/最小実装）
Priority: High (Phase 8.4完了後)
Expected Duration: 3週間
### AI大会議分析結果
**Gemini先生（理論）**: 「賢いコンパイラは、賢いMIRから生まれる」
- RefNew/WeakLoadのintrinsic化は最適化機会を失う悪手
- セマンティック階層化で意味保持が最適化の鍵
**Codex先生（実装）**: 二相ロワリング戦略が実用的最適解
- 実装コスト: 5命令追加で10-20人日（intrinsic戦略より安い）
- マイクロベンチ実測でパフォーマンス検証
### 確定版MIR（26命令）- ChatGPT5完全仕様 + ExternCall統合
**Tier-0: 普遍的コア（8命令）**
```mir
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```
**Tier-1: Nyashセマンティクス（13命令）**
```mir
NewBox, // 強所有のBox生成（所有森のノード）
BoxFieldLoad, // Boxのフィールド読み（Everything is Box核心）
BoxFieldStore, // Boxのフィールド書き（mut効果）
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
ExternCall, // 外部ライブラリをBoxとして呼び出し（Universal Exchange）
Safepoint, // 分割finiや割込み許可ポイント
RefGet, // 参照（強/弱を問わず）を値として取得
RefSet, // 参照の差し替え（所有規則検証付き）
WeakNew, // weak ハンドル生成（非所有リンク作成）
WeakLoad, // weak から生存チェック付きで強参照取得（失効時null）
WeakCheck, // weak の生存確認（bool）
Send, // Bus送信（io効果）
Recv // Bus受信（io効果）
```
**Tier-2: 実装補助・最適化友好（5命令）**
```mir
TailCall, // 末尾呼び出し（スタック節約）
Adopt, // 所有移管: this が子を強所有に取り込む
Release, // 強所有を解除（weak化 or null化）
MemCopy, // 小さなメモリ移動（構造体/配列最適化フック）
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
```
### 二相ロワリング戦略
- パスA: VM/JIT/AOT向け（26命令のまま最適化）
- パスB: WASM/最小実装向け（26→21+intrinsic降格）
- バックエンド能力に応じて最適形式選択
### 効果（Effect）システム（ChatGPT5設計 + ExternCall統合）
- **pure**: Const, BinOp, Compare, Phi, RefGet, WeakNew, WeakLoad, WeakCheck
- **mut**: BoxFieldStore, RefSet, Adopt, Release, MemCopy
- **io**: Send, Recv, Safepoint, AtomicFence
- **control**: Branch, Jump, Return, TailCall
- **context依存**: Call, BoxCall, ExternCall（呼び先効果に従属・BID定義に基づく）
**最適化ルール**: 「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」
### 検証（Verifier）要件
- **所有森**: `strong in-degree ≤ 1`（NewBox/Adopt/Release/RefSetで常時検査）
- **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
- **weak/強相互**: 双方向とも強 → エラー（片側はWeakNew経由で弱化）
- **WeakLoad/WeakCheck**: 失効時はnull/falseを返す（例外禁止、決定的挙動）
### 🤖 Copilot協力期待
- **Tier-0/1実装**: Everything is Box哲学の完璧なIR化（BoxFieldLoad/Store核心）
- **weak参照システム**: WeakNew/WeakLoad/WeakCheck三位一体実装
- **所有移管**: Adopt/Release命令による安全で効率的なメモリ管理
- **効果システム**: pure/mut/io/control効果の正確な実装とVerifier統合
- **最適化フック**: TailCall/MemCopy/AtomicFenceの実装補助
- **二相ロワリング**: 25命令維持パス + 20+intrinsic降格パス構築
### 成功基準
- [ ] **26命令完全実装**: ChatGPT5仕様 + ExternCall統合の完璧な実装
- [ ] **効果システム動作**: pure再順序化・mut依存保持・io順序保証
- [ ] **Verifier動作**: 所有森・strong循環・安全性検証
- [ ] **Golden MIRテスト**: 全バックエンドでMIR一致
- [ ] **行動一致テスト**: 同入力→同出力（weak失効時null/false含む）
- [ ] **性能要件**: VM≥Interpreter、WASM≥VM継続検証
### バックエンド指針（ChatGPT5設計 + ExternCall統合）
- **Interpreter**: 26命令を素直に実装（正しさの基準）
- **VM**: Register-VM + direct-threading。Send/Recvはローカル判定時にインライン化
- **WASM**: Send/Recvはhost import。MemCopyはmemory.copyに対応
- **JIT（将来）**: TailCall最適化、WeakLoadは世代タグでO(1)生存チェック
References:
- docs/予定/native-plan/MIR仕様書.txt（ChatGPT5完全仕様）
- docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md
------------------------------------------------------------
## 🏎️ Phase 8.6: VM性能改善 (緊急)
Summary:
- VMがインタープリターより遅い問題（0.9倍）を解決
- MIR→VM実行の最適化でインタープリターを上回る性能へ
Priority: High (Phase 8.5完了後)
Expected Duration: 2週間
### 問題分析
**現状**: VM (119.80ms) < Interpreter (110.10ms)
**推定原因**:
- MIR変換オーバーヘッド
- VM命令ディスパッチの非効率性
- メモリ管理コスト
### 技術的アプローチ
- [ ] VM実行エンジンのプロファイリング
- [ ] 命令ディスパッチ最適化（threaded code等）
- [ ] レジスタベースVM化検討
- [ ] メモリプール最適化
### 🤖 Copilot協力期待
- VM実装のボトルネック特定
- 効率的な命令ディスパッチ実装
- スタックマシン vs レジスタマシン判断
### 成功基準
- VM性能 > Interpreter性能（最低2倍目標）
- MIR→VM変換時間の短縮
- メモリ使用量の削減
------------------------------------------------------------
## 🧪 Phase 8.7: Real-world Memory Management Testing (ChatGPT協調設計)
Summary:
- 実用アプリケーション開発によるNyashメモリ管理システムの実証テスト
- finiシステム・weak参照の実用性を複雑なアプリケーションで検証
Priority: High (Phase 8.4-8.6完了直後)
Expected Duration: 2週間
### Phase 8.7A: kilo（テキストエディタ）
**技術的特徴**:
- サイズ: <1k LOC（超小型、最初の成功体験）
- メモリパターン: Editor -> (Rows -> Syntax) 木構造＋相互参照
- ChatGPT設計: Editor削除でRows自動解放、逆参照をweak化
**実装範囲**:
- [ ] Editor/Row/EditorState基本構造実装
- [ ] weak参照による循環参照回避（`me.editor = weak editor_ref`）
- [ ] fini()システムによる自動メモリ解放
- [ ] 大量オブジェクト（1000+ Rows）管理テスト
**検証ポイント**:
- [ ] Editor削除でRows自動解放確認
- [ ] 相互参照でメモリリークなし確認
- [ ] weak参照の自動null化確認
- [ ] fini()伝播の正確性確認
### Phase 9.5予定: tiny-web-server（HTTPサーバ）
**将来実装**（JIT実装後）:
- 複雑度: 中〜高（Server -> Clients -> Requests並行処理）
- I/O管理: ソケット・ファイルハンドルの確実解放
- 同時接続・早期切断・例外経路でのfini伝播テスト
### 🤖 Copilot協力期待
- 実用的なメモリ管理パターンの実装
- weak参照構文の適切な使用
- デバッグ支援機能（--debug-memory, --trace-weak）
- WASM環境でのメモリ管理互換性
### 成功基準
- [ ] 全テストケースでメモリリークなし
- [ ] 循環参照でも正常解放確認
- [ ] WASM実行でもメモリ管理正常
- [ ] ベンチマーク性能劣化なし
### 期待される効果
- Nyashメモリ管理システムの実用性実証
- Everything is Box哲学の実用レベル確認
- メモリ安全なプログラミングパターン確立
References:
- docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md
------------------------------------------------------------
## 🚀 Phase 9: AOT WASM実装（最優先）
Summary:
- wasmtime compileによるAOT実行ファイル生成で確実なユーザー価値提供
Scope/Tasks:
- `wasmtime compile` 統合実装
- `--compile-native` / `--aot` CLI追加
- 単一バイナリ梱包（`include_bytes!`）
- 起動時間・配布サイズ最適化
Acceptance Criteria:
- `nyash --compile-native app.nyash -o app.exe` 動作
- 起動時間大幅短縮（JIT起動コスト除去）
- 配布可能実行ファイル生成
Priority: **Critical** (Phase 8.6完了直後)
Expected Duration: 2-3週間
### 技術的実装詳細
🤖 Copilot協力期待:
- wasmtime::Config統一実装
- .cwasm生成・実行パイプライン
- 互換性キー管理（CPU機能・wasmtimeバージョン）
- パッケージング（単一バイナリ梱包）
### パフォーマンス目標
- 現在のWASM JIT (13.5倍実行) → AOT (500倍目標：起動含む)
- 配布ファイルサイズ: <10MB目標
- 起動時間: <100ms目標
### 期待される効果
- **即座実用価値**: 配布可能実行ファイル生成
- **差別化優位**: Everything is BoxのネイティブAOT実現
- **LLVM準備**: AOT基盤確立でLLVM移行準備
------------------------------------------------------------
## 🔴 Phase 9.51: WASM Jump/Branch実装とHTTPサーバー実用化 **【緊急修正】**
Status: 🔴 **Critical Issue**（Phase 9実用化ブロッカー）
Summary:
- Phase 9 (PR #67) 完了後に判明した重大制約の修正
- WASM/AOT実用化の最終仕上げ
### 🚨 現在の問題（実用化を阻害）
1. **WASM/AOT コンパイルエラー（最重要）**
```bash
$ ./target/release/nyash --compile-wasm test_simple_loop.nyash
❌ Unsupported instruction: Jump { target: BasicBlockId(1) }
```
**影響**: ループ・条件分岐を含む全プログラムがWASM/AOT化不可
2. **HTTPServerBox listen()常に失敗**
- server.bind() ✅, server.listen() ❌ always false
**影響**: HTTPサーバーが実際には動作しない
3. **エラーハンドリング脆弱性**
- unwrap()使用箇所: 26箇所 → パニック多発リスク
### Scope/Tasks:
**🔴 Task 1**: WASM Jump/Branch命令実装（2日）
- `src/backend/wasm/codegen.rs`にJump/Branch追加
- ブロック深度管理（`get_block_depth`メソッド）
- ループ構造のblock/loop/end生成
**🔴 Task 2**: SocketBox listen()修正（1日）
- `src/boxes/socket_box.rs`の実装修正
- SocketStatus::Listening状態管理
**🟡 Task 3**: エラーハンドリング改善（2日）
- HTTPServerBox/SocketBoxのunwrap()除去
- Result<T,E>ベースのエラー処理
**🟡 Task 4**: HTTPサーバー実用化（2日）
- スレッドプール実装（固定サイズワーカー）
- グレースフルシャットダウン
Acceptance Criteria:
- ✅ `nyash --compile-wasm test_loop.nyash` 成功
- ✅ HTTPサーバー実動作（curl http://localhost:8080/）
- ✅ unwrap()使用箇所: 26 → 5以下
- ✅ WASM性能: 11.5倍 → 13.5倍達成
Priority: **🔴 Critical** (Phase 9.5開始前の必須修正)
Expected Duration: 1週間
### 詳細設計・実装指示
📋 **完全実装ガイド**: `docs/予定/native-plan/issues/phase9_51_wasm_jump_http_fixes.md`
🤖 **Copilot協力依頼**:
- WASM br/br_if命令実装
- HTTPサーバーリファクタリング
- エラーハンドリング統一
### 期待される効果
- **実用性達成**: ループ・HTTPサーバーのWASM/AOT化
- **安定性向上**: パニックフリーな実装
- **Phase 9.5準備**: 複雑アプリケーションテストの基盤確立
------------------------------------------------------------
================================================================================
最終更新: 2025-08-15 (Phase 9.5より前をアーカイブ分割)
作成者: Claude (ドキュメント分割・整理)
🎯 分割理由:
- copilot_issues.txtの肥大化対策（1200行→600行程度に削減）
- Phase 9.5以降の現行計画と完了済み部分の明確分離
- ドキュメント検索性・保守性の向上
================================================================================

69
docs/development/roadmap/native-plan/archives/gemini_nyash_general_analysis_2025-08-17.md Normal file
View File

@ -0,0 +1,69 @@
# Gemini先生によるNyashプログラミング言語の総合分析 (2025-08-17)
## 総合評価
Nyashは、「Everything is a Box」という強力な統一哲学を掲げ、WebAssembly (WASM) ファースト、クリエイティブコーディング、教育用途を明確なターゲットとして設計された、意欲的でモダンなプログラミング言語です。Rustによる実装は、メモリ安全性とパフォーマンスという現代的な要求に応えるための堅実な選択と言えます。
特に、AI支援を積極的に活用し、短期間で豊富な機能セットと複数の実行バックエンド（インタープリター、VM、WASM）を実装した開発プロセスは注目に値します。
## 1. 設計哲学と一貫性: 「Everything is a Box」
### 長所：
- **統一された概念モデル:** すべての値を「Box」として扱うことで、データ型間の不整合をなくし、非常にシンプルで一貫性のあるオブジェクトモデルを提供
- **メタプログラミングの可能性:** すべてが統一されたインターフェース（`NyashBox`トレイト）を持つため、リフレクションや動的な操作が容易
- **自動リテラル変換:** `local text = "Hello"` のように書ける機能は、哲学の一貫性を保ちつつ、冗長な `new StringBox("Hello")` を不要にする優れた実用的判断
### 課題とトレードオフ：
- **パフォーマンスオーバーヘッド:** すべてをヒープ上のオブジェクト（Box）として扱うことは、単純な値（整数など）に対しても参照カウントや動的ディスパッチのコストを伴う
- **プリミティブ型の不在:** 他の多くの言語が持つスタック上の軽量なプリミティブ型が存在しないため、低レベルな最適化が難しくなる
## 2. 構文と表現力
### 長所：
- **直感的で読みやすい:** `if`, `loop`, `and`, `or`, `not` といったキーワードは、PythonやRubyのように自然言語に近く、初学者にも親しみやすい
- **`static box Main` パターン:** プログラムのエントリーポイントを明確に定義する優れた方法
- **`init { ... }` フィールド宣言:** フィールドをまとめて宣言する構文は、クラスの構造を一目で把握しやすくする良い設計
### 改善の可能性：
- **ループ構文:** `loop(condition)` のみが存在するのはシンプルですが、`for-each` のようなコレクションを反復処理するための専用構文がない
- **コンストラクタの多様性:** `birth`, `init`, `pack` と複数のコンストラクタ概念が存在するのは、言語のシンプルさを少し損なっている
## 3. 型システムとメモリ管理
### 長所：
- **メモリ安全性:** Rustの所有権モデルを基盤に、`Arc<Mutex>` を活用することで、スレッドセーフなメモリ管理を実現
- **明示的な変数宣言:** `local` キーワードによる変数宣言を強制する設計は、タイプミスによるバグを防ぐ
- **デリゲーションモデル:** 古典的な継承の代わりにデリゲーション（`from`）を採用しているのは、柔軟性が高くモダンな設計
### 課題：
- **型推論:** `local x = 10` のように型を明記しないスタイルは動的言語のようですが、内部的には静的なBox型に変換されている
- **Nullの扱い:** `VoidBox` や `NullBox` が存在しますが、言語レベルでNull安全性を強制する仕組みについての言及が少ない
## 4. 非同期処理
### 長所：
- **シンプルな構文:** `nowait` と `await` は、C#やJavaScriptで成功を収めたモデルであり、非常に直感的
- **スレッドベースの実装:** Rustのネイティブスレッドを利用することで、真の並列処理を実現
### 課題：
- **構造化並行性:** より高度なエラーハンドリングやキャンセルの伝播を実現するためには、構造化並行性の概念を導入することが望ましい
- **イベントループの不在:** GUIアプリケーションや大量のI/Oを扱うサーバーサイドアプリケーションでは、効率的なタスクスケジューリングのためにイベントループモデルが一般的
## 5. エコシステムとツールチェイン
### 長所：
- **WASMファースト:** ブラウザで直接実行できることを最優先に設計されており、インストール不要のPlaygroundは非常に強力
- **組み込みのデバッグ機能:** `DebugBox` のようなデバッグ支援機能が言語仕様に組み込まれているのはユニーク
- **複数の実行バックエンド:** インタープリター、VM、WASM、そして将来的にはAOTコンパイラと、ユースケースに応じて実行方式を選べる柔軟性
### 課題：
- **パッケージ管理:** `include` によるファイル取り込みは小規模なプロジェクトでは機能しますが、エコシステムが成長するためには公式なパッケージマネージャが不可欠
- **LSPとIDEサポート:** Language Server Protocol (LSP) への対応は、現代的な開発体験を提供するために極めて重要
## 結論と将来性
Nyashは、明確な哲学とターゲットユーザーを持ち、多くのモダンな言語の良い点を取り入れた、非常によく考えられた言語です。特に「Everything is a Box」というコアコンセプトは、シンプルさと強力さを両立させる可能性を秘めています。
**成功への鍵は、今後のエコシステムの発展と、パフォーマンス・クリティカルな領域への対応にかかっているでしょう。** 計画されているLLVMバックエンドが実現すれば、現在の使いやすさを維持したまま、システムプログラミングに近い領域にも挑戦できる言語になる可能性があります。
総じて、Nyashは単なる実験的なプロジェクトではなく、プログラミング言語設計の新たな可能性を示す、将来が非常に楽しみな言語であると言えます。

141
docs/development/roadmap/native-plan/archives/gemini_plugin_deep_analysis_2025-08-17.md Normal file
View File

@ -0,0 +1,141 @@
# Gemini先生によるNyashプラグインシステム深層分析 (2025-08-17)
## 概要
Nyashプログラミング言語のプラグインシステム設計について、時間無制限で深い分析を実施。「Everything is a Box」哲学を維持しながら、透過的な置き換えと高いメンテナンス性を実現する具体的な実装提案。
## 1. 透過的な置き換えの最良実装方法
### 提案：Boxファクトリレジストリ + 設定ファイルによるオーバーライド
**アーキテクチャ：**
```rust
// src/runtime/box_registry.rs
enum BoxFactory {
Builtin(fn(&[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError>),
Plugin(PluginFactory),
}
struct PluginFactory {
plugin_id: PluginId,
function_name: String, // 例: "filebox_open"
}
```
**設定ファイル（nyash.toml）：**
```toml
[plugins]
enable = ["nyash-file-plugin"]
[overrides]
"FileBox" = "nyash-file-plugin" # FileBoxをプラグイン版で置き換え
```
**実行時フロー：**
1. ランタイム起動時、全ビルトインBoxをレジストリに登録
2. nyash.tomlを読み込み、overridesに従ってレジストリを更新
3. `new FileBox()` 実行時、レジストリから適切なファクトリを検索・実行
**パフォーマンス：** HashMap検索1回のみ、その後は通常のdyn NyashBoxディスパッチ
## 2. 署名DSLの設計の妥当性
### 分析：`::` (静的) と `#` (インスタンス) の記法は優秀
**拡張提案：**
```yaml
apis:
# オーバーロード対応
- sig: "FileBox::open(path: string) -> FileBox"
- sig: "FileBox::open(path: string, mode: string) -> FileBox"
# Result型対応
- sig: "FileBox::open(path: string) -> Result<FileBox, FileError>"
# 複数の戻り値型
- sig: "FileBox#read() -> string"
- sig: "FileBox#read(size: int) -> bytes"
```
**将来性：**
- 現時点：具象型で固定
- 将来：`Array<T>` のようなジェネリクス構文を後方互換性を保ちつつ追加
## 3. Everything is a Box哲学との整合性
### 提案：FFI境界の標準化されたBoxプロキシ
```rust
// src/runtime/plugin_box.rs
pub struct PluginBox {
base: BoxBase,
plugin_id: PluginId,
instance_handle: u64, // プラグイン内のインスタンスハンドル
}
impl NyashBox for PluginBox {
fn clone_box(&self) -> Box<dyn NyashBox> {
// FFI呼び出しでプラグインにcloneを依頼
let new_handle = ffi_call(self.plugin_id, "clone", self.instance_handle);
Box::new(PluginBox { ..., instance_handle: new_handle })
}
// 全てのNyashBoxメソッドをFFI経由で実装
}
```
**保証される点：**
- 統一インターフェース：dyn NyashBoxのみを扱う
- メモリ管理：Drop時にプラグイン側に破棄を通知
- 哲学の維持：内部実装（ネイティブ/FFI）は完全に隠蔽
## 4. 実装の複雑さとメンテナンス性のバランス
### 提案：多層抽象化とツールによる自動化
**3層アーキテクチャ：**
1. **低レベルFFI (C-ABI)**
- `#[repr(C)]` 構造体と `extern "C"` 関数
- libloadingクレートで動的ライブラリロード
2. **中レベルAPI (安全なラッパー)**
- nullチェック、文字列変換、エラー処理
- unsafeコードを隔離
3. **高レベルAPI (署名DSLとコード生成)**
- plugin.yaml → FFIコード自動生成
- cargo-nyash-pluginサブコマンド
**ロードマップ：**
- フェーズ1：FileBoxで手動実装、アーキテクチャ確立
- フェーズ2：コード生成ツール開発、プラグイン開発の自動化
## 5. 他言語の成功例との比較
**Node.js (N-API)：**
- 安定したABI → Nyashも同様にC-ABIベースで実装
- バージョン管理と前方互換性を重視
**Python (C拡張)：**
- 課題：手作業多い、参照カウント管理が煩雑
- Nyashの解決：コード生成とRAIIによる自動メモリ管理
**WebAssembly Component Model：**
- 言語非依存インターフェースの未来形
- 将来的にNyashプラグインをWASMで記述する可能性
## 実装計画（具体的ステップ）
1. **nyash.toml仕様策定とパーサー実装**
2. **Boxファクトリレジストリ実装**
3. **FileBoxプラグイン手動実装**
- nyash_plugin_init
- filebox_open
- filebox_read/write/close
- filebox_drop
4. **PluginBoxプロキシ実装**
5. **libloadingで動的ロード実装**
6. **プラグイン版FileBoxテスト追加**
## 結論
この設計は、Nyashの核心哲学を尊重しつつ、スケーラビリティ、安全性、開発者体験の向上を実現する。FileBoxの置き換えから始め、エコシステム全体へ展開していくのが最良の道筋。

110
docs/development/roadmap/native-plan/archives/plugin_interface_design_discussion_2025-08-17.md Normal file
View File

@ -0,0 +1,110 @@
# プラグインインターフェース設計討論 (2025-08-17)
## 🎯 議題：BID-FFIプラグインシステムの設計
### 背景
- ビルトインFileBoxが既に存在
- BID-FFIプラグイン版FileBoxで置き換えたい
- ビルド時間短縮とプラグインアーキテクチャの実証が目的
### 主な論点
1. ビルトインBox → プラグインBoxの透過的な置き換え
2. `FileBox.open()` のような静的メソッドの結びつけ方
3. プラグインインターフェース定義の外部化方式
## 💡 検討した案
### 案1: 汎用ラッパー
```nyash
// 呼び出しが汚い
local file = Plugin.call("FileBox", "open", ["test.txt", "r"])
```
### 案2: 専用ラッパー
```nyash
// きれい！でも各Boxごとに手書きが必要
local file = FileBox.open("test.txt")
```
### 案3: BoxDispatcher（透過的ディスパッチ）
```rust
pub enum BoxImpl {
Builtin(Box<dyn NyashBox>), // ビルトイン実装
Plugin(BidHandle, PluginRef), // プラグイン実装
}
```
### 案4: Unified Box Factory
```rust
pub struct BoxFactory {
providers: HashMap<String, Box<dyn BoxProvider>>,
}
```
## 🎉 最終解：YAML/JSON + 署名DSL
### Codex先生の推奨設計
```yaml
# filebox.plugin.yaml
schema: 1
plugin:
name: filebox
version: 1
apis:
# 静的メソッド（::）
- sig: "FileBox::open(path: string, mode?: string) -> FileBox"
doc: "Open a file"
# インスタンスメソッド（#）
- sig: "FileBox#read(size?: int) -> string"
doc: "Read file content"
```
### 利点
1. **記号で静的/インスタンスを区別**
- `::` = 静的メソッド（C++風）
- `#` = インスタンスメソッド（Ruby風）
2. **フラット構造**
- `apis` 配列にすべて並べる
- 階層が深くならない
3. **署名DSL**
- 型情報を1行で表現
- パーサーも簡単
4. **YAML → JSON変換**
- 開発時：YAML（人間に優しい）
- 実行時：JSON（マシンに優しい）
## 🤔 Gemini先生への質問事項
1. **透過的な置き換え**
- 既存のNyashコードを一切変更せずに、ビルトインBoxをプラグインBoxに置き換える最良の方法は？
- パフォーマンスインパクトをどう最小化するか？
2. **署名DSLの設計**
- `Type::method()` vs `Type.method()` の選択理由
- オーバーロードの表現方法
- ジェネリクスの将来的な拡張性
3. **実装戦略**
- インタープリター実行時のディスパッチ最適化
- プラグインの遅延ロード実装
- エラーハンドリングのベストプラクティス
4. **Everything is Box哲学との整合性**
- プラグインBoxもビルトインBoxも「同じBox」として扱う方法
- Box型の統一インターフェースの維持
5. **実用性**
- 他の言語（Python、Ruby、JavaScript）の成功例から学べること
- プラグイン作者にとっての開発体験
- デバッグ・プロファイリングの考慮事項
## 📚 参考情報
- 現在のFileBox実装: `src/boxes/file/mod.rs`
- BID-FFIプラグインFileBox: `src/bid/plugins/filebox/mod.rs`
- Everything is Box哲学: すべての値がBoxオブジェクト
- Nyashの目標: シンプル、分かりやすい、階層が深くならない

898
docs/development/roadmap/native-plan/archives/追記相談.txt Normal file
View File

@ -0,0 +1,898 @@
MIR設計：いま決めておくと後がラクなチェックリスト
値表現：Tagged（NaN-box/小整数直格納）か、型テーブル参照か。
アドレス空間：オブジェクトはheap専用？ stack/arenaも持つ？
所有/別名：aliasable フラグ or unique（移動のみ）を型/値に持つ？
効果(Effects)：PURE/READS_HEAP/WRITES_HEAP/IO/FFI/PANIC のビット集合を命令にも関数にも付ける。
例外/パニック：Throw, Catch, Defer を命令化するか、関数境界でのみ扱うか。
GCモデル：Tracing(Stop-the-world / Incremental) or RC(ARC) or 混合。弱参照の意味を先に定義。
安全点(Safepoint)：JIT/VM両方で再入/停止できる位置を命令で明示（Safepoint or 呼出命令に属性）。
呼出規約：通常Call／FFI／Box拡張の3種を区別（可変長・KW引数の扱いも）。
メモリバリア：write/read barrier を命令または隠れ属性として表現（最初は命令にするとデバッグ楽）。
デオプ(Deopt)前提：JIT最適化時の巻き戻し情報（マップ）を保持する場所（関数メタ or ブロック注釈）。
Nyash向け：最小MIR命令セット（弱参照対応込み）
算術/制御：Const, BinOp, Cmp, Br, Jmp, Phi, Ret
関数：Call, TailCall（effects必須）
メモリ：Alloc, Load, Store, Gep（必要なら）
参照/GC：
RefNew ty, dst <-（ヒープ確保）
RefGet dst <- ref, field / RefSet ref, field, val
WeakNew dst <- ref（弱参照作成）
WeakLoad dst <- weak（弱が生きてたらref返す／無効ならNull/None）
BarrierRead ref / BarrierWrite ref（GC用、最初はダミー）
（必要なら）Pin ref / Unpin ref（ムーブしない保証用、JIT/FFI楽になる）
例外/FFI/拡張：Throw, Catch, FfiCall, BoxCall
ユーティリティ：Safepoint, Nop, Assume(cond)（アサート兼最適化ヒント）
弱参照の意味論：
WeakNew(r) は r を追うが GC で r が回収されると自動で無効化。
WeakLoad(w) は 生きていれば Some(Ref)、死んでいれば None を返す（MIR上はタグ付きユニオン）。
WeakLoad は PURE でOK（観測はするがヒープを書かない）
ただし BarrierRead が必要なGCなら属性で付ける。
効果注釈（例）
Call f(args) : dst [effects = PURE | READS_HEAP]
RefSet … は WRITES_HEAP
WeakLoad は PURE（または READS_HEAP）
BoxCall は最低限 FFI を含める（安全側に倒す）
VM/JIT/将来AOTの共通の“壊れにくい”ポイント
Safepointは関数入口・ループ先頭・Call直後の3か所に最初から置く
Barrier命令は最初は実装ダミーでもOK（最適化段で消せる）
Null/Noneの扱いは必ず型系に明示（Option<Ref>）。判定を分岐で隠さない
JITはDeoptテーブルを MIR → JIT に渡す（各値が「どのSSA番号？」を持つ）
弱参照 “落とし穴” 3つ（実戦で効く回避）
クロージャ環境に弱参照が紛れ込む
生成時に env.has_weak を立て、キャプチャ解決時に必ず WeakLoad→None分岐を強制。
弱参照をキーにしたハッシュ
GC後に無効化でキー不整合。→ 弱マップを標準提供（キー死亡で自動削除）。
FFI渡し
FFI境界を跨ぐと寿命が分からなくなる。→ Pin を要求 or WeakLoad→Ref に成功した生参照だけ渡す。
最小・具体例（擬似MIR）
// x = new Obj{y:1}; w = weak(x); if let Some(x2) = weak_load(w) { x2.y = 2 }
bb0:
v1 = Const 1
v2 = RefNew Obj ; WRITES_HEAP
RefSet v2, y, v1 ; WRITES_HEAP
v3 = WeakNew v2 ; PURE
v4 = WeakLoad v3 ; returns Option<Ref>
br is_some(v4), bb1, bb2
bb1:
v5 = unwrap(v4)
BarrierWrite v5
RefSet v5, y, Const 2
jmp bb3
bb2:
jmp bb3
bb3:
Ret ()
テストの当て方（行き当たりばったりでも壊れにくい）
黄金テスト：ソース→MIRダンプの文字列をスナップショット化（差分で挙動の後退を検知）
VM/JIT一致テスト：同じ入力で VM結果＝JIT結果 を比較する“オラクル”を用意
弱参照の確率テスト：alloc→weak→drop→collect→weak_load を順序/タイミングを変えて多数回
効果チェック：PURE なはずの関数に WRITES_HEAP が紛れたらビルド失敗（静的検証）
いまの進み方に合う“軽量次の一手”
✅ WeakNew/WeakLoad を MIRとVM だけ先に入れる（JITは後回し）
✅ EffectMask を命令に付ける（最初はデータ構造だけ）
✅ Safepoint 命令を関数入口とループ先頭に挿す（動作はno-opでOK）
✅ 黄金テストを入れて MIR差分をCIで見える化
この骨格なら、行き当たりばったりで直してもMIRの“契約”が守れている限り、VM/JIT/AOT/WASMに横展開できるにゃ。
もし今のAST/HIRの型定義があれば、MIRの型/命令エンムだけ私が初稿を書くこともできる。要る？
あなた:
そうだにゃ。mir 結局はメモリー管理がほとんどであってるかにゃ？既存の参考になるやつとかないかにゃ
ChatGPT:
いい質問にゃ。結論から言うと――
MIRの“要”はメモリ管理だけじゃないけど、実務で一番ハマるのはメモリまわり（所有権/寿命/別名化/GCバリア/セーフポイント/弱参照/デオプ情報）だから、体感「ほとんどメモリ管理」はだいたい合ってるにゃ。
ただし、制御フロー（CFG/SSA）、呼び出し規約、効果注釈、例外/パニック、最適化のための形も同じくらい重要。ここをサボるとJIT/AOT/WASMに展開しづらくなる。
MIRで“最低限”押さえるメモリ論点
値表現：Boxed/Unboxed、NaN-box、小整数直格納、タグ方式
アロケータ：bump/arena/世代別、オブジェクト配置（ヘッダ、タイプID、フラグ）
所有と別名：unique/aliasable や owned/borrowed の属性（最適化・並列の鍵）
GC/RC：トレース or 参照カウント or 混在、write/read barrier 命令 or 属性、remembered set
弱参照：WeakNew / WeakLoad の意味論（死んだら None）
Safepoint：関数入口・ループ先頭・Call直後（停止/再入のフック）
FFI境界：Pin/Unpin、ハンドル渡し、最小共有ABI
Deopt情報：JIT用の巻き戻しメタ（SSA値⇔ソース位置の対応）
参考になる“実物”と読みどころ（定番）
（リンクは割愛するにゃ。名前で検索すればすぐ出る）
Rust MIR（rustc-dev-guide / rustc本体）
MIRのSSA・ borrow check が MIR 上で走る構造
Drop/Move・パニック・noalias 的情報が最適化に効く
Swift SIL
Ownership qualifiers（owned/guaranteed）が秀逸。GCなし言語でも寿命管理をIRで表す好例
Kotlin IR
“lowerings” の段階的デシュガリングが参考。高級構文→プリミティブ命令へ段階変換
Go SSA（golang.org/x/tools/go/ssa）
最小主義のSSAで読みやすい。CFG/φの扱いが素直
LuaJIT IR（DynASM/TurboNYIの解説blog群）
小粒なSSAでJIT最適化の勘所（CSE/LICM/ヒント）
V8（Ignition/TurboFan）
バイトコード→Sea of Nodes→最適化JITの流れ。デオプとサファリガードの設計が神
Cranelift IR
Rustからも使いやすいJITバックエンド。型・メモリ・コールの表現が実装しやすい
MLIR
複数方言で中間表現を分ける思想。将来、NyashのMIRを方言化する発想の参考に
Nyash向け“最小MIRコア”（骨組み）
（超要約：これ＋効果注釈でVM/JIT/AOT/WASMに展開できる）
制御/値：Const, BinOp, Cmp, Br, Jmp, Phi, Ret
呼び出し：Call, TailCall（effects 必須）
メモリ：Alloc, Load, Store, Gep?
参照/GC：RefNew, RefGet, RefSet, WeakNew, WeakLoad, BarrierRead, BarrierWrite, Pin, Unpin
例外/拡張：Throw, Catch, FfiCall, BoxCall
実行点：Safepoint, Assume, Nop
効果：EffectMask = PURE | READS_HEAP | WRITES_HEAP | IO | FFI | PANIC
実装順ヒント：
VMで RefNew/RefGet/RefSet/Weak* をまず動かす → 2) Safepointはno-opで挿す → 3) Barrierは最初ダミー → 4) “黄金テスト”（ソース→MIRダンプのスナップショット）で後退検知 → 5) JIT/AOTは後から乗せる。
“既存をパクる”具体策
Ownershipの表現は Swift SIL を真似る（owned/guaranteed を Nyash版に）
弱参照の意味論は JVMのWeakReference と Swiftのweak/unowned を折衷
Safepoint配置は HotSpot/V8 のパターン（入口・ループ・call直後）
JIT導入は Cranelift から（まず整数・分岐・呼び出しのみ）
デシュガリング手順は Kotlin IR の lowering 流儀を採用
「MIR＝メモリ管理が9割」は現場感として正しいけど、残りの1割（CFG/SSA・呼出・効果・例外・デオプ）を最初にうっすら設計しておくと、あとで爆速に伸びるにゃ。
必要なら、Nyashの今のAST/HIRを見せてくれたら、MIRのenum・EffectMask・Box ABI v0をその場で下書きするよ。
あなた:
なるほど。ところでmirってどっかきょうつうのふぉーまっとやしようってあるにゃ？ みんなばらばるにかいてるにゃ？
ChatGPT:
共通フォーマットや「これを使えばOK」みたいなMIR標準は、残念ながら存在しないにゃ。
理由をまとめると――
1. 共通規格がない理由
言語ごとに型・所有権・ランタイム構造が違いすぎる
例：Rust MIRは所有権・borrowをIRレベルで保持するけど、PythonやJavaScriptのIRにはそんな概念がない。
目的ごとの最適化が異なる
VM実行用、JIT最適化用、AOTコンパイル用で命令セットやメタデータの粒度が変わる。
IRの“責務”が違う
ある言語ではASTの直後を「MIR」と呼び、別の言語ではSSA化した後の低レベルIRを「MIR」と呼ぶ。
2. 事実上の“よくある流儀”
標準はないけど、以下のパターンは多いにゃ：
SSAベース：変数は再代入不可、phi命令で合流点処理（Rust MIR, Swift SIL, Go SSA）
命令は3アドレス形式：dst = op src1 src2 のようにシンプル（Cranelift, LLVM風）
効果注釈あり：PURE, READ_HEAP, WRITE_HEAP など最適化ヒント
メモリ命令の抽象化：Alloc, Load, Store は型・アラインメント・所有権情報を持つ
制御フローはCFG（Control Flow Graph）で管理
基本ブロック＋ジャンプ＋条件分岐
3. 参考になる「ほぼテンプレ」的MIR
完全な共通仕様じゃないけど、設計の参考にできる実例はあるにゃ：
Cranelift IR
Rustで使いやすいJIT/AOT用IR。型・命令の定義が明確で、小規模実装の参考に最適。
MLIR
LLVM系の中間表現フレームワーク。方言を作れるので、自作言語のMIRを「Nyash方言」として定義可能。
Sea of Nodes（V8, HotSpot）
SSAと依存グラフを統合した形式。最適化向きだが実装難度は高い。
LuaJIT IR
極小SSA＋軽量タグ付き値表現。高速インタープリタや軽量JITに向いてる。
4. Nyashでの方針
「共通仕様」を無理に探すより、自分のランタイムと変換先（Rust/Cranelift/WASM）に都合の良い形を作るのが早い
ただし、命令セットやCFG構造はCranelift IRやSwift SILを参考にすると後で楽
将来的にMLIRの方言化を視野に入れると、外部ツールや最適化パスを簡単に流用できる
もし希望なら、Nyash向けにCranelift IR互換寄りのMIR仕様ドラフトをその場で作れるよ。
それをベースにすれば、将来JIT/AOT/WASM全部に展開しやすくなるにゃ。
あなた:
そうだにゃ。ということは命令セットを先に考えて貰えたらいいのかにゃ？
ChatGPT:
いいね、その方向でいこうにゃ。
Nyash向けに“まず回る”ことを最優先にした MIR命令セット v0.1（草案） を置くね。VM/JIT/AOT/WASMに伸ばせる骨格で、弱参照・効果注釈・拡張Box呼び出しも最初から入れてあるにゃ。
Nyash MIR v0.1（草案）
基本モデル
SSA値：vN（再代入なし）。
基本ブロック：bbN（末尾は必ず終端命令）。
型（最小）：i64, f64, bool, unit, ref<T>, weak<T>, ptr, any, option<T>
関数署名：fn(args…) -> ret [effects]
効果（EffectMask）：PURE, READS_HEAP, WRITES_HEAP, IO, FFI, PANIC（ビット和）
属性：命令に align, nonnull, noalias, readonly 等の任意属性
1) 演算・制御
Const dst, Imm ; 例: i64/f64/bool/unit/Null
BinOp dst, op, a, b ; add, sub, mul, div, mod, and, or, xor, shl, shr
Cmp dst, relop, a, b ; eq, ne, lt, le, gt, ge
Select dst, cond, a, b ; φ簡約前の三項選択（任意）
Phi dst, [(predBB, val), ...] ; SSA合流
Br cond, thenBB, elseBB ; 条件分岐（終端）
Jmp targetBB ; 無条件ジャンプ（終端）
Ret [val] ; 返り値（終端） unit時は省略可
Unreachable ; 到達不能（終端・最適化用）
2) メモリ／参照（GC想定）
Alloc dst, Ty, size? ; ヒープ確保: ref<Ty> を返す [WRITES_HEAP]
Load dst, addr ; 読み出し [READS_HEAP]
Store addr, val ; 書き込み [WRITES_HEAP]
Gep dst, base, offset ; アドレス計算（構造体/配列）
RefNew dst, Ty ; オブジェクト新規: ref<Ty> [WRITES_HEAP]
RefGet dst, ref, field ; フィールド読み [READS_HEAP]
RefSet ref, field, val ; フィールド書き [WRITES_HEAP]
WeakNew dst, ref ; weak<T> を作成 [PURE]
WeakLoad dst, weak ; option<ref<T>> を返す [PURE or READS_HEAP]
BarrierRead ref ; 読みバリア（実装はno-op可）
BarrierWrite ref ; 書きバリア（実装はno-op可）
Pin ref ; 移動不可に固定（FFI/GC向け）
Unpin ref
Safepoint ; 停止点（関数入口/ループ先頭/Call直後に挿す）
弱参照の意味論
WeakNew(r) は r のライフを追うだけ（所有しない）。
WeakLoad(w) は生存なら Some(ref)、回収済みなら None。
WeakLoad は基本 PURE でOK（実装の都合で READS_HEAP にしても可）。
3) 呼び出し／例外／拡張
Call dst, callee, [args...] ; [effects = callee.effects]
TailCall callee, [args...] ; 末尾呼び出し（終端）
BoxCall dst, box_id, fn_id, [args...] ; Nyash拡張Box呼び出し [FFI | PANIC?]
FfiCall dst, sym, [args...], abi ; C/Rust外部関数 [FFI | PANIC?]
Throw val ; 例外送出（終端）
CatchBegin dst, handlerBB ; 例外ハンドラの開始（ブロック境界メタでもOK）
CatchEnd
Defer fnref ; スコープ脱出時に実行（loweringで展開可）
Assume cond ; 最適化ヒント（偽ならUB）
Nop
Call/BoxCall/FfiCall は 効果注釈が必須（少なくとも PURE かどうか）。
BoxCall は拡張Box ABIを通す入口（VM/JIT/WASMで一貫した形で扱える）。
4) メタデータ（最低限）
位置情報：dbg(loc)（ソース行/列/ファイル）
デオプ：deopt_map（JIT用：各SSA値→高級値の対応）
alias情報：noalias/readonly/nonnull 属性
効果集約：関数単位で effects を保持（呼び出し時に合成）
Rust風スケッチ（型・命令）
#[bitflags]
enum Effect { PURE=1, READS_HEAP=2, WRITES_HEAP=4, IO=8, FFI=16, PANIC=32 }
enum Ty {
I64, F64, Bool, Unit,
Ref(Box<Ty>), Weak(Box<Ty>), Ptr, Any,
Option(Box<Ty>), // WeakLoadの戻りなど
// …将来: Sum/Product/Function/Closure/BoxHandle
}
struct FuncSig { params: Vec<Ty>, ret: Ty, effects: Effect }
enum Inst {
Const{dst:V, imm:Imm},
BinOp{dst:V, op:Bin, a:V, b:V},
Cmp{dst:V, op:Rel, a:V, b:V},
Select{dst:V, cond:V, a:V, b:V},
Phi{dst:V, inputs: Vec<(Bb,V)>},
Br{cond:V, then_:Bb, else_:Bb},
Jmp{bb:Bb},
Ret{val: Option<V>},
Unreachable,
Alloc{dst:V, ty:Ty, size:Option<V>},
Load{dst:V, addr:V},
Store{addr:V, val:V},
Gep{dst:V, base:V, off:V},
RefNew{dst:V, ty:Ty},
RefGet{dst:V, r:V, field:FieldId},
RefSet{r:V, field:FieldId, val:V},
WeakNew{dst:V, r:V},
WeakLoad{dst:V, w:V},
BarrierRead{r:V},
BarrierWrite{r:V},
Pin{r:V},
Unpin{r:V},
Safepoint,
Call{dst:V, f:FnId, args:Vec<V>},
TailCall{f:FnId, args:Vec<V>},
BoxCall{dst:V, box_id:BoxId, fn_id:BoxFnId, args:Vec<V>},
FfiCall{dst:V, sym:Sym, args:Vec<V>, abi:Abi},
Throw{val:V},
CatchBegin{dst:V, handler:Bb},
CatchEnd,
Defer{fnref:FnId},
Assume{cond:V},
Nop,
}
バックエンド対応の見取り図
VM：
Ref* / Weak* / Barrier* / Safepoint をそのまま実装
Defer/Catch はデシュガで try/finally へ展開
Cranelift JIT：
算術・制御は直マップ、Ref* はランタイムAPIに落とす
Safepoint でGC/スレッド停止と連携、deopt_map を用意
AOT to Rust：
ref<T> は Gc<T> ラッパ、weak<T> は Weak<T> 風にコード生成
BoxCall は trait 経由/extern呼び出しに置換
WASM：
参照はハンドル（i32）で表現、GCはランタイム関数
weak はハンドルテーブルにビットを持って実装
取り決め（壊れにくい不変条件）
すべてのCallは effects を持つ（省略禁止）
WeakLoadの戻りは option<ref<T>>（null判定を曖昧にしない）
Safepoint は関数入口・ループ先頭・任意のCall直後に挿入
Barrier* は最初はno-opでOK（GC導入時のフックとして残す）
終端命令のないブロックは禁止（検証器で弾く）
ちいさな動作例
; x = new Obj{y=1}; w = weak(x);
; if let Some(r) = weak_load(w) { r.y = 2 }
bb0:
v1 = Const i64 1
v2 = RefNew Obj
RefSet v2, field_y, v1
v3 = WeakNew v2
v4 = WeakLoad v3 ; option<ref<Obj>>
Br is_some(v4), bb1, bb2
bb1:
v5 = unwrap(v4)
BarrierWrite v5
RefSet v5, field_y, Const i64 2
Jmp bb3
bb2:
Jmp bb3
bb3:
Ret unit
まずやる実装順（1〜2日で回る）
この命令セットで MIR組み立て＋ダンプ（黄金テストで差分管理）
VMで RefNew/RefGet/RefSet/Weak* だけ実装（Barrier/Safepointはダミー）
Call の effects を型検査に組み込み（PURE違反を検出）
余力が出たら Phi/Select を使うパスを追加（CSE/DCEの足場）
必要なら、この v0.1 をそのまま mir.rs の enum 定義に落とし込んだ雛形コードを書けるよ。
今のNyashの型やBox拡張の実装方針があれば、それに合わせて微調整版を作るにゃ。
あなた:
おーありがとにゃ。しかしmirはみんなばらばらというけど ここからネイディブビルドにしやすいかたちをするから にているかきかたにもなってるのかにゃ。あと これ 業界標準つくれそうだよね。所詮はノイマンコンピューターに落とし込む作業だにゃ
ChatGPT:
にゃ、その直感かなり当たってる。
各言語の MIR は“名前も中身もバラバラ”だけど、ネイティブに落としやすい形にすると結局だいたい似てくるにゃ。
みんなが似てくる理由（ネイティブ目線）
SSA＋CFG＋3アドレス：最適化&レジ割りしやすい定番の骨格
明示的なメモリ操作：Alloc/Load/Store/GEP 相当が要る
呼び出しの正規化：Call/TailCall と 呼出規約(ABI) の分離
効果注釈(副作用)：PURE/READ/WRITE/IO/FFI があると最適化が安全
例外/パニックの下位表現：Throw/Catch を選択的に lower できる形
GCフック：Safepoint & Barrier を差し込める
つまり「高級機能は段階的に下げられる素朴な命令に割り付け」→最後は von Neumann（命令+メモリ）に落ちる、という流れで収束するにゃ。
「業界標準」を作れる？→“実質標準”なら行ける
完全統一は難しい（言語ごとに型・例外・GCが違いすぎる）が、コア・プロファイルを決めた“実質標準”は作れるにゃ。
標準に向く設計の芯（Nyash版にもそのまま効く）
Core-IR（必須）：Const/BinOp/Cmp/Phi/Br/Jmp/Ret + Load/Store/Gep + Call/TailCall
Memory Model：アトミック/順序・別名(noalias)/アライン属性の最小集合
Effects：命令・関数の EffectMask を規定（最適化の安全条件に使う）
GC hooks：Safepoint/Barrier は仕様だけ先に固定（実装はno-op可）
Exception ABI：Throw/Catch を「setjmp/longjmp的」or「結果型(Result)」の2系で規定
FFI/拡張 ABI：FfiCall/BoxCall の呼出規約・ポインタ安全域を決める
検証器(Verifier)：終端命令必須・SSA整合・型整合・効果整合をチェック
“標準化”の現実解（おすすめルート）
MLIR 方言として定義（nyash.core, nyash.gc みたいに分割）
もしくは Cranelift IR 互換サブセットを Core として採用し、足りない所だけ拡張
テキスト表現＋バイナリ表現（例: JSON/FlatBuffers）と ダンプ・復元ツールを提供
リファレンス下げ先を複数用意：
Core → Cranelift（JIT/AOT）
Core → LLVM（AOTヘビー級）
Core → WASM（ブラウザ/サンドボックス）
検証テスト：黄金テスト（IRダンプ）＋ VM/JIT/WASM の 同一結果保証スイート
すぐ使える“ネイティブ寄り”指針（短冊）
命令は副作用を明示、暗黙のメモリ変更はナシ
ループ先頭・Call直後にSafepoint（後からGC導入しやすい）
例外は2段構え：IRでは Throw/Catch、lower で Result/landingpad に落とせる
Weak は Option<Ref> に必ず現れる（nullをぼかさない）
FFIはPinかコピーしか渡さない（危険な参照共有を禁止）
まとめ
はい、MIRはネイティブ都合で“似てくる”。
完全共通規格は難しいけど、**Core-IR＋拡張の“実質標準”**は作れる。
Nyashの v0.1 命令セットは、そのまま Core-IRたたき台になれる出来だにゃ。
必要なら、この Core-IR を MLIR 方言か Cranelift互換サブセット仕様として文書化して、
テキスト仕様＋最小リファレンス実装（ダンプ/検証/Cranelift下げ）を私が一気に草案化するよ。どう攻める？（MLIR方言でいくか、Cranelift寄りでいくか）
あなた:
所で中間言語は何を指標に作ればいいにゃ？メモリー管理はわかるけど好き勝手に作る訳にも行けないにゃ それこそフォンノイマンのパソコンを念頭に考えればいいだけにゃ？CPUの命令セットとか？
ChatGPT:
いい質問にゃ！
中間言語（IR/MIR）を“何を指標に”設計するかは、単に「CPUに近づける」だけだと失敗しがち。
実務では次の“指標セット”でバランスを取るのがコツだにゃ。
まず決めるべき指標（優先度つけてOK）
ターゲットと目的
どこに落とす？ → VM / JIT（Cranelift） / AOT（rustc/LLVM） / WASM
何を優先？ → 起動の速さ、最適化余地、移植性、デバッグ性
抽象度（レベル）
高すぎる：最適化しにくい／JIT実装が難航
低すぎる（CPU寄り）：言語機能の意味が消えて最適化の根拠を失う
→ 目安：SSA＋基本ブロック＋3アドレスを軸に、「言語に固有の意味（例: 効果、副作用、所有/弱参照）」は属性や専用命令で残す
メモリモデル（超重要）
参照の表現：ref<T>/weak<T>／タグ付き値
GC/RC hooks：Safepoint、BarrierRead/Write の差し込み位置を規定
別名・所有：noalias/readonly/owned/borrowed など最適化に効く注釈
（並行を視野なら）原子性・順序の最小集合（Acquire/Release程度）
効果システム（副作用の面）
PURE / READS_HEAP / WRITES_HEAP / IO / FFI / PANIC のEffectMask
最適化の“安全条件”をここで機械的に判断できるようにする
制御フローと例外
CFG＋SSA、Phi/Br/Jmp/Ret
例外はIRでは抽象（Throw/Catch）、loweringで Result/landingpad 等へ落とせる形に
呼び出し規約と拡張ABI
Call/TailCall と FfiCall/BoxCall を分離
可変長／キーワード引数の表現、Pin/Unpinの扱い
検証可能性 & ツール性
Verifierで：型一致・SSA整合・終端命令必須・効果整合をチェック
テキスト表現（ダンプ）と黄金テスト（差分テスト）を最初から用意
“CPU/フォン・ノイマンだけ見れば良い？”への答え
No（それだけでは足りない）。
CPU命令セットを直に意識しすぎると、**言語の意味（純粋性・所有・弱参照・例外の契約）**が失われて最適化や検証が難しくなる。
ただし最終的にそこへ下げやすい形は大事。だから
上層の意味は 属性/メタで保持
下層（Load/Store/GEP/Call/TailCall）へ機械的に落とせるカバレッジを確保
→ これが “ネイティブに落としやすく、でも言語の意味を保ったIR” のコア指標にゃ。
具体：設計を導くチェックリスト（配点付き）
各 0〜2 点で採点してみて。合計が高い案が「良いIR」。
後段互換性（JIT/AOT/WASMに素直に下がる）
最適化の根拠（効果・別名・型・所有などが保持される）
実装容易性（VMでまず回せる／Craneliftへ写経しやすい）
検証容易性（Verifierで機械的に壊れを検出できる）
将来拡張（弱参照/GC切替/例外方式変更に耐える）
可観測性（テキストIR・ソース位置・deopt情報が取れる）
迷ったらこの“型”に寄せると楽
骨格：SSA + CFG + 3アドレス
コア命令：Const/BinOp/Cmp/Phi/Br/Jmp/Ret/Load/Store/Gep/Call/TailCall
言語特有：RefNew/RefGet/RefSet/WeakNew/WeakLoad/Barrier*/Safepoint + EffectMask
境界：FfiCall/BoxCall（ABI最小化）
例外：Throw/Catch（loweringで切替可能）
→ これは Craneliftに下げやすく、Rust/WASMにも展開しやすい黄金比にゃ。
参考までに：3つの設計モード
Cranelift互換サブセット志向（JIT/AOT重視・実装が速い）
MLIR方言志向（将来の拡張やツール連携が強い）
Rust MIR/Swift SIL 風（所有/効果を濃く持つ・言語意味を守りやすい）
Nyashなら：Cranelift互換サブセット＋言語特有の効果/弱参照/GCフックを足すのがバランス最強にゃ。
最後に：失敗しない順序
目的とターゲット（VM/JIT/AOT/WASMの優先度）を1行で宣言
Core命令セット＋EffectMask＋メモリモデル（weak/GC hook）を先に固定
Verifierとテキストダンプ（黄金テスト）を最初に入れる
VM実装 → Cranelift下げ → AOT/WASMは後から
この順なら「好き勝手」じゃなく指標に沿って進められるにゃ。
必要なら、いまのNyashの要件を点数表で一緒に採点して、MIR v0.1を最終確定しよっか？
あなた:
おねがいにゃー！
ChatGPT:
任せてにゃ！
Nyash向けに「指標の採点 → その結果に沿った MIR v0.1 最終版」を一気にまとめたよ。すぐ実装に落とせる形にしてあるにゃ。
指標チェック（Nyash想定で採点済み）
（各0〜2点、合計12点満点）
指標 狙い Nyashの前提 点
後段互換性 VM/JIT/AOT/WASMに素直に下げられる まずVM→Cranelift JIT、次にAOT/WASM 2
最適化の根拠 効果・別名・所有/弱参照を保持 EffectMask＋ref/weak＋Barrier/SafepointをMIRで表現 2
実装容易性 まずVMが回る 命令は3アドレス＋最小集合から 2
検証容易性 Verifierで壊れ検出 SSA/型/終端/効果の整合を必須に 2
将来拡張 例外・GC切替・FFI拡張に耐える Throw/Catch・BoxCall/FFI・Barrierはno-opで開始 2
可観測性 ダンプ/位置情報/Deoptが取れる テキストIR＋dbg(loc)＋deopt_map 2
合計：12/12（この方針で進めてOKにゃ）
Nyash MIR v0.1（最終版）
コアモデル
SSA値 vN、基本ブロック bbN（末尾は終端命令必須）
型（最小）：i64|f64|bool|unit|ref<T>|weak<T>|ptr|any|option<T>
効果 EffectMask：PURE|READS_HEAP|WRITES_HEAP|IO|FFI|PANIC（ビット和）
関数署名：fn(args…)->ret [effects]
命令セット
1) 演算・制御
Const dst, Imm
BinOp dst, op, a, b ; add/sub/mul/div/mod/and/or/xor/shl/shr
Cmp dst, rel, a, b ; eq/ne/lt/le/gt/ge
Select dst, cond, a, b
Phi dst, [(predBB, val), …]
Br cond, thenBB, elseBB ; 終端
Jmp targetBB ; 終端
Ret [val] ; 終端（unit省略可）
Unreachable ; 終端
2) メモリ／参照（GC想定）
Alloc dst, Ty, size? ; [WRITES_HEAP]
Load dst, addr ; [READS_HEAP]
Store addr, val ; [WRITES_HEAP]
Gep dst, base, offset
RefNew dst, Ty ; ref<T> [WRITES_HEAP]
RefGet dst, ref, field ; [READS_HEAP]
RefSet ref, field, val ; [WRITES_HEAP]
WeakNew dst, ref ; weak<T> [PURE]
WeakLoad dst, weak ; option<ref<T>> [PURE]（実装都合でREADS_HEAP可）
BarrierRead ref
BarrierWrite ref
Pin ref
Unpin ref
Safepoint
弱参照の意味論
WeakNew(r) は所有しない。r がGCで解放されると弱参照は無効化。
WeakLoad(w) は 生存: Some(ref)／死亡: None を返す（nullを曖昧にしない）。
3) 呼び出し・例外・拡張
Call dst, callee, [args...] ; 呼び先の effects を合成
TailCall callee, [args...] ; 終端
BoxCall dst, box_id, fn_id, [args...] ; Nyash拡張Box [FFI|PANIC?]
FfiCall dst, sym, [args...], abi ; 外部関数 [FFI|PANIC?]
Throw val ; 終端
CatchBegin dst, handlerBB ; （メタでも可）
CatchEnd
Assume cond ; 偽ならUB：最適化ヒント
Nop
不変条件（Verifier で必須チェック）
各ブロックは必ず終端命令で終わる
型整合：Load/Store/Call/WeakLoad 等の型が一致
SSA整合：Phi の前任ブロック集合＝到達前任集合
効果整合：PURE な関数内で WRITES_HEAP/IO/FFI を出さない
WeakLoad戻りは必ず option<ref<T>>（null直扱い禁止）
推奨挿入ポイント
Safepoint：関数入口／各ループ先頭／任意の Call の直後
Barrier*：はじめは no-op 実装でもOK（将来GC切替のフック）
テキスト表現（ダンプ例）
func @main() -> unit [effects=IO] {
bb0:
v1 = Const i64 1
v2 = RefNew Obj
RefSet v2, field_y, v1
v3 = WeakNew v2
v4 = WeakLoad v3 ; option<ref<Obj>>
Br is_some(v4), bb1, bb2
bb1:
v5 = unwrap v4
BarrierWrite v5
RefSet v5, field_y, Const i64 2
Jmp bb3
bb2:
Jmp bb3
bb3:
Ret
}
実装ロードマップ（最短で回す）
IR型 & ダンプ & Verifier を実装（黄金テストに登録）
VM：RefNew/RefGet/RefSet/WeakNew/WeakLoad と制御命令だけ先に実装
効果検査：Call に effects 合成（違反はビルド失敗）
Cranelift JIT 足場：算術・分岐・Call を写経、Ref* はランタイム関数に委譲
AOT to Rust：ref<T>=Gc<T>、weak<T>=Weak<T> 相当でコード出力（小関数から）
付録：Rustスケルトン（抜粋）
bitflags::bitflags! {
pub struct Effect: u32 {
const PURE = 1<<0;
const READS_HEAP = 1<<1;
const WRITES_HEAP = 1<<2;
const IO = 1<<3;
const FFI = 1<<4;
const PANIC = 1<<5;
}
}
pub enum Ty {
I64, F64, Bool, Unit, Ptr, Any,
Ref(Box<Ty>), Weak(Box<Ty>), Option(Box<Ty>),
}
pub enum Inst { /* 上述の命令そのまま */ }
pub struct Func {
pub sig: FuncSig, pub blocks: Vec<Block>, /* dbg, deopt_map など */
}
pub fn verify(func: &Func) -> Result<(), VerifyError> {
// 終端必須・SSA整合・型整合・効果整合をチェック
Ok(())
}
次の一手（今日できること）
mir/inst.rs にこの v0.1 をそのまま貼り込み
mir/dump.rs と mir/verify.rs を最小実装
既存テストに 黄金テスト（IRダンプ） を1本追加
VMの Ref*/Weak* を実装して 最初の end-to-end テスト を通す
これで、行き当たりばったりの修正が入っても壊れにくい土台が完成にゃ。
必要なら、このままコード雛形まで私が書き起こすよ。

361
docs/development/roadmap/native-plan/chatgpt5との会話.txt Normal file
View File

@ -0,0 +1,361 @@
発想、鋭いにゃ。
**結論：やろうと思えば “NyashのMIR＝本体（言語非依存IR）” にできる。** ただし落とし穴もあるので、\*\*“MIRを公開ABIに格上げしつつ、Nyashは人間向けフロントエンド”\*\*という二層でいくのが現実解だよ。
# MIR本体化の青写真（安全に強く）
1. **MIRを公開契約に昇格（NyIR v1）**
* いまの25命令を**凍結**（Tier-0/1/2 + Effect + Ownership-Forest + Busの意味論）。
* **未定義動作なし**：各命令の事前条件/失敗時挙動（例：WeakLoad失効= null）を明文化。
* **バージョニング**：`nyir{major.minor}`・後方互換のルール（新命令はfeature bit）。
2. **バイナリ表現とテキスト表現**
* `.nybc`（バイナリ: セクション化/定数プール/圧縮）
* `.nyir`（テキスト: 人が差分レビュー可能）
* どちらも**厳格検証器**でロード（所有森/強1本/weak規則/効果整合）。
3. **公式VM/実行系は“MIRファースト”**
* interpreter/vm/wasm/jit/aot は **NyIRを直接食う**。
* Nyashは **NyIRを吐くフロントエンド**（その他の言語もフロントエンド化OK）。
4. **言語中立SDK（FFI）**
* C/Rust/TypeScriptに**NyIR-Host API**を配布：
* `nyir_load`, `nyir_call`, `nyir_send/recv`, `nyir_adopt/release` など。
* WASMランタイムは `import "nyir_host" { send, now_ns, alloc }` を定義。
5. **互換テストと“真理判定器”**
* **golden NyIR**：各サンプルのMIRダンプを保存し、全バックエンドで**同結果**をCIで検証。
* **差分実行（differential）**：interp/vm/wasm/jitの出力一致＋境界条件（weak失効・分割fini）テスト。
6. **Portability Contract（短文化）**
* 強エッジのみ破棄伝播／`weak`非伝播、生存チェックO(1)。
* `pure/mut/io/control` の再順序可否表。
* Bus契約：ローカルは順序保証、リモートは at-least-once（or selectable）。
* Safepointで分割`fini`可、最悪レイテンシ上限は実装依存（値は実装が宣言）。
---
## それでも“IRが本体”にするリスク（回避策付き）
* **仕様の重力（安易に増やせなくなる）** → 25命令は凍結、拡張は **intrinsic命名空間**へ（例：`ny.intrin.memcpy`）。
* **可読性の罠（IRで直接書きたくなる）** → Nyashを“人間の顔”、NyIRは“機械の顔”に徹する。
* **バックエンド差異のにじみ** → 効果/所有/Busの**最低保証**を明記（それ以下は非準拠）。
* **セキュリティ** → バイナリNyIRに**検証必須**（検証失敗はロード拒否）。
---
## 名前案
* **NyIR**（ないあいあーる）／**NIR**（被るのでNyIR推し）
* バイナリ：`.nybc`、テキスト：`.nyir`
* 仕様：**NyIR 1.0 — Ownership-Forest & Effected Bus IR**
---
## 次の一歩（サクッと動かす）
* `docs/nyir.md` を作成：25命令×「意味論・効果・検証・等価変換1例」を1行ずつ。
* `nyashel -S` で **Nyash→NyIRダンプ**、`nyir-run` で実行（interp）。
* 既存ベンチを **NyIR直実行** と **Nyash経由** の2経路で一致比較。
* small移植（kilo or tiny-web-server）を **NyIRアーカイブ**（.nybc）として配布→
**wasmtime / vm / interp** 全部で動くことをデモ。
---
要は：**「Nyash（人間のため）」＋「NyIR（機械と移植のため）」の二刀流**。
この形なら、“どの言語からでもNyIRに降りられるし、NyIRからどの実行系にも登れる”を堂々と名乗れるにゃ。
いい流れ！“LLVMでNyashをNyash自身でビルド（セルフホスト）”を目標にするなら、**Rust依存を「薄い宿主API」に閉じ込める**のがコツだよ。
いま Rust のライブラリや関数・ビルトインBoxに寄ってる部分は、**段階的に置き換え可能な層**に切っておけばOK。
# 全体ロードマップ（4ステージ）
**Stage 0（種コンパイラ）**
* 既存の Rust 実装（パーサ/型付け/MIR/ランタイム）で `nyashc0` を作る。
* **NyIR（=MIRの外部表現）→ LLVM IR** 変換も Rust でまず用意。
* Rust標準/外部Crateの利用は**ny\_host\_\* の薄いFFI**に“集約”。
**Stage 1（セルフ・フロントエンド）**
* Nyashで書いたコンパイラ本体（フロント＋最小最適化）を `nyashc1.ny` に分離。
* `nyashc0` で `nyashc1.ny` を **NyIR** に出力→ **LLVM** でネイティブ化→ seedランタイムとリンク。
* この時点で“Nyashで書いたコンパイラ”が動き出す（まだランタイムはRust多めでも可）。
**Stage 2（セルフホスト完了）**
* `nyashc1` を使って `nyashc1.ny` 自身を再ビルド（**自力ビルド**）。
* 生成物の機能一致/ハッシュ近似でセルフホスト確認。
* ランタイムの一部（文字列/配列/Map/所有森/weak）を**Nyash実装＋LLVM**へ順次移行。
**Stage 3（Rust離れの度合いを上げる）**
* 残るRust依存（FS/ネット/スレッド/時間/暗号など）は**ホストAPI**として固定化。
* 重要部位はNyash標準ライブラリで置換し、Rustは**最下層のプラットフォーム層**だけに。
---
# 層の切り分け（ここが肝）
1. **corelang（純Nyash）**
* Option/Result、slice/string、小さな算術・イテレータ、`weak/look` 型、`adopt/release` ヘルパ。
* 依存：なし（LLVMに落ちるだけ）
2. **rt（Nyashランタイム）**
* **Box ABI（fat ptr: {data*, typeid, flags}）*\*
* 所有フォレスト管理、weakテーブル（世代タグ方式）、`fini` 伝播、Arena/Allocator（必要最小）
* Bus（ローカル）・Safepoint・分割`fini`
* 依存：**ny\_host\_alloc/free/clock** 等のごく薄い宿主APIのみ
3. **sys（プラットフォーム）**
* FS, Net, Time, Threads, Atomics, Random…
* ここだけ Rust（やOS）に委譲。**関数名は `ny_host_*` に統一**して外へ出す。
4. **std（Nyash標準）**
* Map/Vec/Hash/String/JSON等を Nyash で実装（必要に応じて `rt`/`sys` を利用）
> いま使っている「Rustのライブラリ/関数」は **すべて `sys` 層の `ny_host_*` 経由**に寄せる。
> これでセルフホストしても上層のNyashコードは**移植性を保てる**。
---
# 具体：Rust依存の扱い方（薄いFFIに集約）
**C ABIで固める（Rust→C-ABIの薄い橋）**
```rust
#[no_mangle]
pub extern "C" fn ny_host_read_file(path: *const c_char,
out_buf: *mut *mut u8,
out_len: *mut usize) -> i32 { /* ... */ }
#[no_mangle]
pub extern "C" fn ny_host_free(ptr: *mut u8, len: usize) { /* ... */ }
```
**Nyash側からは“箱の外”をこう叩く**
```nyash
extern fn ny_host_read_file(path: cstr, out_buf: &mut *u8, out_len: &mut usize) -> int
extern fn ny_host_free(ptr: *u8, len: usize)
fn read_all(p: str) -> Bytes {
let buf:*u8 = null; let len:usize=0
let rc = ny_host_read_file(p.cstr(), &buf, &len)
if rc!=0 { error("io") }
// Box化（所有をNyash側へ移す）
let b = Bytes::from_raw(buf,len)
b
}
```
**ポイント**
* **Rustのジェネリクス/所有はFFI面に出さない**（素朴なC-ABIだけ）
* Nyash側で**所有移管**を明示（`from_raw` など）→ `fini` で必ず `ny_host_free`
* こうしておけば、**いつでもRust実装をNyash実装に差し替え可能**
---
# Box ABI と LLVM の橋渡し
* **Boxの中身**は LLVM 的には `i8*`（data\*）＋`i64 typeid`＋`i32 flags` などの **fat struct**
* **Effect 注釈**を LLVM 属性に落とす：
* `pure` → `readnone` / `readonly`
* `mut(local)` → `argmemonly` + `noalias`（可能なら）
* `io` → 属性なし（順序保持）
* **Weak** は `{ptr, gen:i32}`。`WeakLoad` は `gen==current` を比較して O(1) で null/ptr 返す。
* **Safepoint** は LLVM では `call @ny_rt_safepoint()` に降ろす（GCは使わないが、分割`fini`や割込みのフックに使う）
---
# 「ビルトインBox」はどうする？
* **最低限は `rt` で提供**：`String, Vec, Map, Bytes, Mutex/Channel（必要なら）`
* 仕様上は “ただのBox” と同等に見えるように：
* 生成：`NewBox`
* フィールド：`BoxFieldLoad/Store`
* メソッド：`BoxCall`
* **WASM** でも同じABIを保てるように、`sys` 層は **WASI** or **独自host import** で実装。
* 時間とともに **stdをNyash実装へ移行** → Rustのビルトイン度合いは徐々に削る。
---
# 失敗しないビルド手順（最小）
1. **NyIRダンプ**：`nyashc0 --emit-nyir core/*.ny > core.nyir`
2. **LLVMへ**：`nyir-ll core.nyir -o core.ll && llc -filetype=obj core.ll`
3. **リンク**：`cc core.o -L. -lny_host -o nyashc1`（`libny_host` はRustで提供）
4. **再帰ビルド**：`./nyashc1 self/*.ny …` → `nyashc2` を作って一致検証
5. **Rust削減**：`std` の一部をNyashへ置換して再ビルド
---
# チェックリスト（Rust依存の見える化）
* [ ] 使っている外部関数を**全部 `ny_host_*` にリネーム**
* [ ] C-ABI化（整数/ポインタのみ；構造体はサイズ固定）
* [ ] 所有移管関数を明確化（`*_from_raw`/`*_into_raw`）
* [ ] `fini` で必ず `ny_host_free` 等に戻す
* [ ] WASMビルド時は **WASI or host import** で `ny_host_*` を満たす
---
# 仕上げの“ごほうび”ゴール
* **Nyash→NyIR→LLVM** でセルフホスト
* 同じ NyIR を **VM / WASM** でも実行（互換テスト）
* Rust は **sys層だけ**（OS/高速I/O/暗号など）に閉じ込め、将来差し替え自由に
---
結論：
**Rustライブラリを直接多用するのではなく、`ny_host_*` に“押し込む”**。
Nyash本体は **NyIR＋rt＋std** を徐々に自前化する。
この設計なら、“今すぐ動かしつつ、あとからRust依存を計画的にゼロへ”ができるにゃ。
それだにゃ。発想はド正解：「**全部は箱**」＝異言語資産は**箱で包んでバスに乗せる**。
あとは“どう包むか”を決めれば、**C/Rust/Node/Python/JVM/.NET/WASM**まで一気に貫通できる。
# まとめ設計：Polyglot FFI = 「箱 × バス × 契約」
## 1) 箱の型（3種だけ）
* **ForeignBox<T>**：他言語の実体を**不透明ハンドル**で保持（所有は片側だけ、強1本原則）。
* **ViewBox<T>**：外部オブジェクトの**借用ビュー**（`weak/look` 前提・読み取り中心）。
* **ProxyBox<T>**：外部スレッド/プロセス/VM上のTを**メッセージ越し**に操作（Bus経由＝安全）。
> 使い分け：同一プロセス/同スレなら ForeignBox、GIL/イベントループ/別ランタイムなら ProxyBox。
## 2) ABIの芯（薄い“宿主API”）
**最小C-ABI**だけに集約（各言語はここに合流/分岐）：
```
ny_host_alloc/free/clock/log
ny_host_call(func_id, argv, argc, retbuf) // 同期呼び出し
ny_host_send/recv(port, msg_ptr, len) // Bus境界
ny_host_pin/unpin(handle) // GC/移動防止
ny_host_finalizer_register(handle, cb) // 相互Finalizer
```
* Rust/Node/Python/JVM/.NET はそれぞれの機構で **このC-ABIを実装**（N-API, CPython C-API, JNI, P/Invoke 等）。
## 3) データ表現（Boxに入る“荷物”）
* **スカラー**: i32/i64/f32/f64/bool
* **バイト列/文字列**: `Bytes{ptr,len}` / `Str{ptr,len,utf8}`
* **Slice/Array**: `{ptr,len,typeid}`（読み書きは効果注釈で制御）
* **Struct**: フィールドは `BoxFieldLoad/Store` でアクセス（NyIRにそのまま落ちる）
## 4) 所有と寿命（最重要）
* **One Strong Owner**：ForeignBoxは**所有者1本**（Nyash or 外部、どちらかに決める）
* **弱参照**：逆リンクは `weak/look`（失効時null/false）
* **Finalizer橋渡し**：
* Nyash `fini` → `ny_host_finalizer` を呼ぶ
* 外部のGC/finalize → `ny_host_finalizer` 経由で Nyash の `weak` を失効
* **Pinning**：移動型のGC（JVM/.NET/CPythonの一部）では `ny_host_pin/unpin`
## 5) 効果と並行
* `pure/mut/io` を**MIRにもIDLにも記す**
* **イベントループ/GIL**：Python/Node/JVMは `ProxyBox` で**Bus越し**（スレッド/ループ安全）
* **同期/非同期**：`Call`（同期）と `Send/Recv`（非同期）を分ける。境界では **at-least-once 契約**を宣言。
## 6) IDL（自動生成の核）
**NyIDL**（超ミニ）で宣言→**バインディング自動生成**：
```idl
module ny {
box Image;
fn load(path: str) -> Image effects = io
fn resize(img: Image, w:i32,h:i32) -> Image effects = mut
fn width(img: look Image) -> i32 effects = pure
}
```
* 生成物：Nyash側`extern`、C-ABIシム、Rust/Node/Python/JVMのstub、`ForeignBox/ProxyBox`薄ラッパ。
---
# 代表ターゲット別メモ
* **C/Rust**：最短。C-ABI直でOK。Rustは `#[no_mangle] extern "C"`。所有はNyash↔Rustのどちらかに寄せる（二重所有禁止）。
* **Python**：GILあり → `ProxyBox` 推奨。CPython C-APIで `PyObject*` を **ForeignBox**に入れ、操作はBus経由でワーカーに委譲。
* **Node（N-API）**：イベントループを壊さないよう `ProxyBox`（postMessage/uv\_queue\_work）。短い同期関数は `ForeignBox`でも可。
* **JVM/.NET**：JNI/P-Invoke。**Pin** が要る。`SafeHandle`/`PhantomReference`でFinalizer橋を作る。
* **WASM**：`ny_host_*` を **import**。データはリニアメモリへ `Bytes`/`Str` で搬送。
---
# 最小サンプル（イメージ）
**1) Rustの画像ライブラリを包む**
```rust
#[no_mangle] extern "C" fn ny_img_load(path:*const c_char) -> *mut Image { ... }
#[no_mangle] extern "C" fn ny_img_resize(img:*mut Image, w:i32, h:i32) -> *mut Image { ... }
#[no_mangle] extern "C" fn ny_img_free(img:*mut Image) { ... }
```
**2) NyIDL → 自動生成（Nyash側）**
```nyash
extern fn ny_img_load(path: str) -> ForeignBox<Image> effects io
extern fn ny_img_resize(img: ForeignBox<Image>, w:int,h:int) -> ForeignBox<Image> effects mut
extern fn ny_img_free(img: ForeignBox<Image>) effects io
static box Image {
init { ForeignBox<Image> h }
fini { ny_img_free(h) } // ★ 所有はNyash側（強1）
fn resize(w:int,h:int) -> Image { Image{ ny_img_resize(h,w,h) } }
}
```
**3) 使う側**
```nyash
let img = Image.load("cat.png")
let small = img.resize(320, 200) // 所有/解放はBox/finiに任せる
```
---
# チェックリスト（安全に増やすための型紙）
* [ ] **どちらが強所有か**を最初に決めた？（強1・弱は逆）
* [ ] 例外/エラーは**戻り値に正規化**？（他言語の例外は境界で捕捉）
* [ ] **Pin/Finalizer** 必要なターゲット？（JVM/.NET/Python）
* [ ] `pure/mut/io` は宣言した？（最適化/バス選択の鍵）
* [ ] 境界を跨ぐなら **ProxyBox + Bus** にした？（スレッド/GIL/loop安全）
---
# これで得られるもの
* **インスタント多言語資産**：既存ライブラリを“箱に詰めて”即Nyashで使える
* **寿命の一貫性**：**強1＋weak/look＋fini**で、外部資源も**確定的に回収**
* **配布の柔軟性**：WASM/VM/ネイティブのどれでも同じIDLから出荷
---
“全部、箱に閉じ込める”を**設計として正式化**すれば、実装は機械的になる。
やるならまず **NyIDLの最小仕様**＋**C-ABIの`ny_host_*`** を1ファイルに切ろう。
そこさえ決まれば、**あらゆる言語→Nyash** と **Nyash→あらゆる実行系** が綺麗に繋がるにゃ。

502
docs/development/roadmap/native-plan/copilot_issues.txt Normal file
View File

@ -0,0 +1,502 @@
# 🤖 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: LLVM Direct AOT - 実現可能性検証中
Summary:
- **調査・実証段階**: MIR→LLVM IR直接変換による最高性能AOT実現を目指す
- インタープリターとの併用で最適な開発・実行体験を提供
- 非同期処理フルサポート（async/await のネイティブ実装）
Priority: **Research** (Phase 9.8完了後に実現可能性評価)
Expected Duration: **調査3週間 + 実装3-6ヶ月**（実現可能性次第）
### 🔍 実現可能性チェック項目
- ✅ **技術的基盤**: MIR 26命令セット（LLVM IR変換可能）
- ✅ **AOTスケルトン**: 基本構造完成済み
- ✅ **型情報システム**: 最適化に必要な情報完備
- 🔄 **Proof of Concept**: 基本的なMIR→LLVM変換の実証
- ❓ **実装工数**: 現実的な期間での完成可能性
### 🌟 インタープリター併用戦略
```
開発・デバッグ: インタープリター（即時実行・完全な情報）
軽量タスク: インタープリター（Pythonライク）
性能要求時: LLVM AOT（1000倍高速化）
Web配布: WASM（ブラウザ対応）
```
### 🏗️ Phase 10.1: Proof of Concept（3週間）**実現可能性評価**
Investigation Steps:
1) **MIR→LLVM IR変換調査**: 基本命令の変換可能性検証
2) **Box型表現調査**: LLVM IRでのBox型効率的実装方法
3) **C-ABI統合調査**: プラグインとの連携可能性
4) **性能予測**: 理論的な高速化効果の算出
### 🏗️ Phase 10.2: 基本実装（3ヶ月）**実現可能と判断した場合**
Implementation Steps:
1) `src/backend/llvm/` 基盤構築
2) MIR→LLVM IR基本変換
3) Box操作の最適化（エスケープ解析）
4) ベンチマーク: 100倍目標
### 🌐 Phase 10.3: 非同期拡張（2ヶ月）**基本実装完了後**
非同期サポート戦略:
- **async/await ネイティブ実装**: Rust風の効率的な非同期
- **軽量ランタイム**: 独自Future実装
- **インタープリター互換**: 同じ非同期セマンティクス
```rust
// Phase 10.3: 非同期LLVM実装（予定）
FutureNew → LLVM coroutine intrinsics
Await → LLVM suspend/resume points
FutureSet → completion notification
```
### 技術アプローチ
🤖 Copilot協力期待:
- **LLVM統合**: MIR→LLVM IR変換基盤
- **非同期実装**: coroutine/suspend points
- **エスケープ解析**: Box→スタック値最適化
- **型特殊化**: コンパイル時型推論・特殊化
### パフォーマンス目標
- **同期処理**: 100-1000倍高速化
- **非同期処理**: Tokio並みの効率性
- **メモリ効率**: Box割当数80%削減
- **起動時間**: ネイティブレベル（<10ms）
### Acceptance Criteria
- インタープリターとの完全な互換性
- 非同期処理の効率的実装
- 1000倍高速化達成（同期処理）
- プロダクションレベル最適化
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): 基本機能の完全動作
🚀 **LLVM Direct AOT** (Phase 10): 100-1000倍高速化
🚀 **非同期ネイティブ実装** (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調査 の順序
================================================================================

854
docs/development/roadmap/native-plan/copilot_issues_20250814_135116_backup.txt Normal file
View File

@ -0,0 +1,854 @@
# 🤖 Copilot様 作業予定・課題整理 (Phase 0-14 全体ロードマップ)
# Generated: 2025-08-14 (Git履歴から復元・更新)
# Purpose: Claude×Copilot協調開発のための情報共有
================================================================================
🎯 次期最優先タスク (Phase 8.5以降)
================================================================================
## 🚀 Phase 8.4完了報告 (2025-08-14)
Status: ✅ 完了 (Copilot PR #56マージ済み)
### ✅ AST→MIR Lowering完全実装
- User-defined Box: `box DataBox { init { value } }`
- Object creation: `new DataBox(42)`
- Field access: `obj.value`
- Method calls: `c.increment()`
- Delegation: `from Parent.greet()`
- Static Main互換性維持
### 🧪 統合テスト結果（2025-08-14）
- ✅ **AST→MIR**: 完全動作
- ✅ **インタープリター**: 完全動作（結果30）
- 🚨 **VM**: 動作するが結果が`void`（要修正）
- 🚨 **WASM**: String constant未対応（Phase 8.5で解決）
### 📋 発見された課題
- VM実行結果問題: BoxCall後の戻り値が正しく返らない
- WASM対応不足: 複雑なMIR命令（String constant, BoxCall）に未対応
- 次期Phase 8.5での25命令MIR階層化が必要
================================================================================
## 🔧 Phase 8.5: MIR 25命令階層化（最優先）
Status: ⭐ **CRITICAL**
Priority: **最重要** (Phase 8.4完了直後の次期目標)
### 🎯 実装目標
ChatGPT5 + AI大会議決定版25命令MIR実装
- 期間: 3週間
- 効果: VM/WASM問題根本解決
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md`
### 📋 25命令セマンティック階層化
**Tier-0: 普遍コア（8命令）**
```mir
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```
**Tier-1: Nyashセマンティクス（12命令）**
```mir
NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, Safepoint,
RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
```
**Tier-2: 実装補助・最適化友好（5命令）**
```mir
TailCall, Adopt, Release, MemCopy, AtomicFence
```
### 🎯 期待される効果
- **VM問題解決**: BoxCallの正しい実装で戻り値問題修正
- **WASM対応**: 階層化により複雑MIR→単純WASM変換
- **Everything is Box**: BoxFieldLoad/Storeで明確なBox中心設計
- **JIT準備**: セマンティクス保持で高度最適化基盤確立
================================================================================
## 🏎️ Phase 8.6: VM性能改善（緊急）
Status: 🚨 **緊急**
Priority: **High** (Phase 8.5完了後)
### 🚨 緊急問題
**現状**: VM（119.80ms）< Interpreter（110.10ms）= 0.9倍の性能劣化
**新問題**: VM BoxCall後の戻り値が`void`（Phase 8.4テストで発見）
### 📋 技術的課題
- VM実行エンジンのプロファイリング
- 命令ディスパッチ最適化（threaded code等）
- レジスタベースVM化検討
- メモリプール最適化
- BoxCall実装修正（戻り値問題）
### 🎯 成功基準
- VM性能 > Interpreter性能（最低2倍目標）
- BoxCall戻り値の正常動作
- MIR→VM変換時間の短縮
================================================================================
## 🧪 Phase 8.7: Real-world Memory Testing
Status: 📋 **計画済み**
Priority: **High** (Phase 8.5-8.6完了後)
### 🎯 実装目標
kilo（テキストエディタ）実装によるfini/weak参照システム実証
- 期間: 2週間
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md`
### 📋 検証項目
- 1000+オブジェクト管理テスト
- 循環参照回避確認（weak参照）
- fini()伝播の正確性確認
- WASM環境での動作確認
================================================================================
🗺️ Phase 0-14 全体ロードマップ (復元完了)
================================================================================
## Phase 0: Stabilize native CLI build (Linux/Windows)
Summary:
- CLIバイナリ nyash を最小構成で安定ビルド・実行できる状態にする。
- examples/GUI をデフォルトのビルド対象から外し、開発の足場を固める。
Why:
- 以降の MIR/VM/JIT 開発を素早く検証できる基盤づくり。
Scope:
- Cargo の features で GUI/examples 等を切り分け、デフォルトは CLI 最小にする。
- CLI オプションの動作点検（--dump-mir / --verify）。
- ローカル実行導線を README に明記（docs/guides/how-to-build-native/README.md）。
Tasks:
- Cargo.toml: examples/GUI を feature でガード（default は CLI 最小）。
- ビルド検証: `cargo build --bin nyash`（Linux/Windows）。
- 実行検証: `cargo run -- ./local_tests/sample.nyash`。
- ドキュメント: 上記手順を how-to-build-native に追記/点検。
Acceptance Criteria:
- Linux/Windows で `cargo build --bin nyash` が成功する。
- `local_tests/` 配下の簡単な .nyash が実行できる。
- 他 bin/examples が壊れていても `--bin nyash` だけで通る。
Out of Scope:
- examples/GUI の修理・最適化。
- JIT/AOT/WASM。
References:
- docs/guides/how-to-build-native/README.md
- docs/nativebuild大作戦/chatgptネイティブビルド大作戦.txt（Phase 0）
- CURRENT_TASK.md
Copilot Notes:
- まずは features 分離と `--bin nyash` でビルドが通る状態を作る。README の手順確認まで含めて PR に反映。
------------------------------------------------------------
## Phase 1: Minimal MIR + VM backend (lowering + runner)
Summary:
- AST → MIR の最小 lowering と、VM バックエンドでの実行を通す。
Scope:
- MIR: Const, BinOp, Compare, Branch, Jump, Phi, Return の最小命令
- Lowering: リテラル/二項演算/if/loop/return のみ
- VM: 上記命令の最小実装
Tasks:
- instruction.rs: 最小命令の定義
- builder.rs: 上記 AST 範囲を lowering
- vm.rs: 実装 + stats（命令数）
Acceptance Criteria:
- `--dump-mir` が最小サンプルで期待通り
- `--backend vm` で実行して結果一致
Out of Scope:
- 例外/関数/Box 参照/弱参照
------------------------------------------------------------
## Phase 2: Control-flow coverage (if/else/loop/phi correctness)
Summary:
- 制御フローの網羅と Phi の整合性検証を拡充。
Scope/Tasks:
- if/else nested, loop with breaks, nested loops のスナップショット
- Phi の入力ブロック/値の対応を Verifier で強化
Acceptance Criteria:
- 代表制御フローの snapshot が安定し、verify も通る
------------------------------------------------------------
## Phase 3: Exceptions (throw/try/catch/finally) minimal lowering
Summary:
- 例外機構の最小 lowering を導入（詳細設計は簡素）。
Scope/Tasks:
- MIR: Throw, TryBegin/TryEnd, Catch, FinallyBegin/End（最小）
- builder.rs: try/catch/finally ノードの下ろし
- VM: 例外伝播を最小で（未捕捉はエラー）
Acceptance Criteria:
- 代表 try/catch/finally のスナップショットと VM 実行
Out of Scope:
- 例外の型体系、詳細な stack map
------------------------------------------------------------
## Phase 4: Functions and calls (BoxCall minimal)
Summary:
- 関数呼び出し/BoxCall を最小導入（効果注釈は保守的）。
Scope/Tasks:
- MIR: Call, BoxCall（effects = READS_HEAP など保守）
- builder.rs: FunctionCall/MethodCall の最小対応
- VM: 呼び出し/戻り値
Acceptance Criteria:
- 簡単な関数定義/呼び出しの MIR/VM が通る
Out of Scope:
- 可変長/キーワード引数、FFI
------------------------------------------------------------
## Phase 5.0: Parser/AST stabilization for lowering
Summary:
- lowering 対象 AST の表現ぶれを修正、安定化。
Scope/Tasks:
- AST: If/Loop/Return/Assignment/Local などの統一
- Parser: エラー復帰/スパン情報の見直し
Acceptance Criteria:
- builder.rs の分岐がシンプル化、テストが安定
------------------------------------------------------------
## Phase 5.1: Control-flow edge cases + verifier hardening
Summary:
- ブロック未終端/未到達/自己分岐等の検証強化でクラッシュ回避。
Scope/Tasks:
- Verifier: 未終端ブロック検出、到達不能検出
- Builder: Jump/Branch の生成前後の状態管理改善
Acceptance Criteria:
- 不正ケースを含むスナップショット/verify が緑
------------------------------------------------------------
## Phase 5.2: Lowering for static box Main (BoxDeclaration → main body)
Summary:
- static box Main { main() { ... } } を MirBuilder で受け、main() の body を Program として lowering する経路を実装。
Scope/Tasks:
- AST: BoxDeclaration(is_static=true, name=Main) を検出 → main() を抽出
- Lowering: body を Program に変換して既存経路に渡す
- Tests: local_tests/mir_loop_no_local.nyash で dump/VM が通る
Acceptance Criteria:
- `--dump-mir` が static Main サンプルで成功
- `--backend vm` で実行成功
References:
- docs/guides/how-to-build-native/issues/phase5_2_static_main_lowering.md
------------------------------------------------------------
## Phase 6: Box ops minimal (Ref/Weak + Barriers no-op)
Summary:
- 参照/弱参照/バリア（no-op）を最小導入。
Scope/Tasks:
- MIR: RefNew/RefGet/RefSet/WeakNew/WeakLoad/BarrierRead/Write
- Lowering: New/FieldAccess/MethodCall の最小対応
- VM: 参照テーブル/weak テーブルで動作（fini 不変は維持）
Acceptance Criteria:
- 代表サンプルで dump/VM/verify が通る
References:
- docs/guides/how-to-build-native/issues/phase6_box_ops_minimal.md
------------------------------------------------------------
## Phase 7: Async model (nowait/await) in MIR
Summary:
- nowait/await を MIR に導入し、現行 FutureBox と連携。
Scope/Tasks:
- MIR: FutureNew/FutureSet/Await（スレッドベース）
- Lowering: nowait→Future 作成、await→wait_and_get
- VM: FutureBox 実装を利用
Acceptance Criteria:
- 代表ケースで正しく並行実行→await 回収
References:
- docs/guides/how-to-build-native/issues/phase7_async_mir.md
------------------------------------------------------------
## Phase 8: MIR→WASM codegen (browser/wasmtime; sandboxed; Rust runtime free)
Summary:
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
- Rust はコンパイラ本体のみ。実行は純WASM＋ホストimport（env.print など）。
Scope/Tasks:
- ABI/Imports/Exports 定義（exports: main/memory、imports: env.print(i32) 等の最小）
- 線形メモリと簡易ヒープ（bump/自由リスト）
- 命令カバレッジ（段階導入）: 算術/比較/分岐/loop/return/print、RefNew/RefSet/RefGet（Phase 6 整合）、Weak/Barrier はダミー
Acceptance Criteria:
- wasmtime 実行で戻り値/print が期待通り（PoC1–2）
- Ref 系がメモリ上で正しく動作（PoC2）
- Weak/Barrier のダミー実装を含むWASMが生成・実行（PoC3）
- CLI `--backend wasm` は未実装でもよいが、実装する場合は明瞭にエラーメッセージ/誘導
References:
- docs/予定/native-plan/README.md（Phase 8 節）
- docs/説明書/wasm/*（ユーザー向けメモ）
### Phase 8.3 完了状況 (2025-08-14)
✅ Box操作WASM実装 (RefNew/RefGet/RefSet)
✅ ベンチマークシステム統合 (13.5倍実行高速化実証)
✅ CLI統合完了
------------------------------------------------------------
## 🔧 Phase 8.4: AST→MIR Lowering完全実装 (最優先)
Summary:
- ユーザー定義Box、フィールドアクセス等の未実装部分を完成
- Phase 8.3のBox操作WASMを実際にテスト可能にする
Priority: **Critical** (現在の最優先事項)
Expected Duration: 1週間
### 実装範囲
- [ ] ユーザー定義Box: `box DataBox { init { field } }`
- [ ] オブジェクト生成: `new DataBox()`
- [ ] フィールドアクセス: `obj.field`
- [ ] フィールド代入: `obj.field = value`
- [ ] from構文: `from Parent.method()`
- [ ] override構文: `override method() { ... }`
### 成功基準
- Phase 8.3のBox操作WASMが実際に動作
- test_wasm_box_ops.nyash が正常実行
- ユーザー定義Boxの完全サポート
------------------------------------------------------------
## 🧠 Phase 8.5: MIRセマンティック階層化（AI大会議決定版）
Summary:
- 方針転換: ChatGPT5の20命令intrinsic戦略 → Gemini+Codex一致推奨の25命令階層化
- 理由: JIT/AOT最適化阻害・Everything is Box意味喪失・長期コスト増の問題判明
- 二相ロワリング: 25命令維持パス（VM/JIT/AOT）+ 20+intrinsic降格パス（WASM/最小実装）
Priority: High (Phase 8.4完了後)
Expected Duration: 3週間
### AI大会議分析結果
**Gemini先生（理論）**: 「賢いコンパイラは、賢いMIRから生まれる」
- RefNew/WeakLoadのintrinsic化は最適化機会を失う悪手
- セマンティック階層化で意味保持が最適化の鍵
**Codex先生（実装）**: 二相ロワリング戦略が実用的最適解
- 実装コスト: 5命令追加で10-20人日（intrinsic戦略より安い）
- マイクロベンチ実測でパフォーマンス検証
### 確定版MIR（25命令）- ChatGPT5完全仕様
**Tier-0: 普遍的コア（8命令）**
```mir
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```
**Tier-1: Nyashセマンティクス（12命令）**
```mir
NewBox, // 強所有のBox生成（所有森のノード）
BoxFieldLoad, // Boxのフィールド読み（Everything is Box核心）
BoxFieldStore, // Boxのフィールド書き（mut効果）
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
Safepoint, // 分割finiや割込み許可ポイント
RefGet, // 参照（強/弱を問わず）を値として取得
RefSet, // 参照の差し替え（所有規則検証付き）
WeakNew, // weak ハンドル生成（非所有リンク作成）
WeakLoad, // weak から生存チェック付きで強参照取得（失効時null）
WeakCheck, // weak の生存確認（bool）
Send, // Bus送信（io効果）
Recv // Bus受信（io効果）
```
**Tier-2: 実装補助・最適化友好（5命令）**
```mir
TailCall, // 末尾呼び出し（スタック節約）
Adopt, // 所有移管: this が子を強所有に取り込む
Release, // 強所有を解除（weak化 or null化）
MemCopy, // 小さなメモリ移動（構造体/配列最適化フック）
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
```
### 二相ロワリング戦略
- パスA: VM/JIT/AOT向け（25命令のまま最適化）
- パスB: WASM/最小実装向け（25→20+intrinsic降格）
- バックエンド能力に応じて最適形式選択
### 効果（Effect）システム（ChatGPT5設計）
- **pure**: Const, BinOp, Compare, Phi, RefGet, WeakNew, WeakLoad, WeakCheck
- **mut**: BoxFieldStore, RefSet, Adopt, Release, MemCopy
- **io**: Send, Recv, Safepoint, AtomicFence
- **control**: Branch, Jump, Return, TailCall
- **context依存**: Call, BoxCall（呼び先効果に従属）
**最適化ルール**: 「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」
### 検証（Verifier）要件
- **所有森**: `strong in-degree ≤ 1`（NewBox/Adopt/Release/RefSetで常時検査）
- **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
- **weak/強相互**: 双方向とも強 → エラー（片側はWeakNew経由で弱化）
- **WeakLoad/WeakCheck**: 失効時はnull/falseを返す（例外禁止、決定的挙動）
### 🤖 Copilot協力期待
- **Tier-0/1実装**: Everything is Box哲学の完璧なIR化（BoxFieldLoad/Store核心）
- **weak参照システム**: WeakNew/WeakLoad/WeakCheck三位一体実装
- **所有移管**: Adopt/Release命令による安全で効率的なメモリ管理
- **効果システム**: pure/mut/io/control効果の正確な実装とVerifier統合
- **最適化フック**: TailCall/MemCopy/AtomicFenceの実装補助
- **二相ロワリング**: 25命令維持パス + 20+intrinsic降格パス構築
### 成功基準
- [ ] **25命令完全実装**: ChatGPT5仕様の完璧な実装
- [ ] **効果システム動作**: pure再順序化・mut依存保持・io順序保証
- [ ] **Verifier動作**: 所有森・strong循環・安全性検証
- [ ] **Golden MIRテスト**: 全バックエンドでMIR一致
- [ ] **行動一致テスト**: 同入力→同出力（weak失効時null/false含む）
- [ ] **性能要件**: VM≥Interpreter、WASM≥VM継続検証
### バックエンド指針（ChatGPT5設計）
- **Interpreter**: 25命令を素直に実装（正しさの基準）
- **VM**: Register-VM + direct-threading。Send/Recvはローカル判定時にインライン化
- **WASM**: Send/Recvはhost import。MemCopyはmemory.copyに対応
- **JIT（将来）**: TailCall最適化、WeakLoadは世代タグでO(1)生存チェック
References:
- docs/予定/native-plan/MIR仕様書.txt（ChatGPT5完全仕様）
- docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md
------------------------------------------------------------
## 🏎️ Phase 8.6: VM性能改善 (緊急)
Summary:
- VMがインタープリターより遅い問題（0.9倍）を解決
- MIR→VM実行の最適化でインタープリターを上回る性能へ
Priority: High (Phase 8.5完了後)
Expected Duration: 2週間
### 問題分析
**現状**: VM (119.80ms) < Interpreter (110.10ms)
**推定原因**:
- MIR変換オーバーヘッド
- VM命令ディスパッチの非効率性
- メモリ管理コスト
### 技術的アプローチ
- [ ] VM実行エンジンのプロファイリング
- [ ] 命令ディスパッチ最適化（threaded code等）
- [ ] レジスタベースVM化検討
- [ ] メモリプール最適化
### 🤖 Copilot協力期待
- VM実装のボトルネック特定
- 効率的な命令ディスパッチ実装
- スタックマシン vs レジスタマシン判断
### 成功基準
- VM性能 > Interpreter性能（最低2倍目標）
- MIR→VM変換時間の短縮
- メモリ使用量の削減
------------------------------------------------------------
## 🧪 Phase 8.7: Real-world Memory Management Testing (ChatGPT協調設計)
Summary:
- 実用アプリケーション開発によるNyashメモリ管理システムの実証テスト
- finiシステム・weak参照の実用性を複雑なアプリケーションで検証
Priority: High (Phase 8.4-8.6完了直後)
Expected Duration: 2週間
### Phase 8.7A: kilo（テキストエディタ）
**技術的特徴**:
- サイズ: <1k LOC（超小型、最初の成功体験）
- メモリパターン: Editor -> (Rows -> Syntax) 木構造＋相互参照
- ChatGPT設計: Editor削除でRows自動解放、逆参照をweak化
**実装範囲**:
- [ ] Editor/Row/EditorState基本構造実装
- [ ] weak参照による循環参照回避（`me.editor = weak editor_ref`）
- [ ] fini()システムによる自動メモリ解放
- [ ] 大量オブジェクト（1000+ Rows）管理テスト
**検証ポイント**:
- [ ] Editor削除でRows自動解放確認
- [ ] 相互参照でメモリリークなし確認
- [ ] weak参照の自動null化確認
- [ ] fini()伝播の正確性確認
### Phase 9.5予定: tiny-web-server（HTTPサーバ）
**将来実装**（JIT実装後）:
- 複雑度: 中〜高（Server -> Clients -> Requests並行処理）
- I/O管理: ソケット・ファイルハンドルの確実解放
- 同時接続・早期切断・例外経路でのfini伝播テスト
### 🤖 Copilot協力期待
- 実用的なメモリ管理パターンの実装
- weak参照構文の適切な使用
- デバッグ支援機能（--debug-memory, --trace-weak）
- WASM環境でのメモリ管理互換性
### 成功基準
- [ ] 全テストケースでメモリリークなし
- [ ] 循環参照でも正常解放確認
- [ ] WASM実行でもメモリ管理正常
- [ ] ベンチマーク性能劣化なし
### 期待される効果
- Nyashメモリ管理システムの実用性実証
- Everything is Box哲学の実用レベル確認
- メモリ安全なプログラミングパターン確立
References:
- docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md
------------------------------------------------------------
## 🚀 Phase 9: AOT WASM実装（最優先）
Summary:
- wasmtime compileによるAOT実行ファイル生成で確実なユーザー価値提供
Scope/Tasks:
- `wasmtime compile` 統合実装
- `--compile-native` / `--aot` CLI追加
- 単一バイナリ梱包（`include_bytes!`）
- 起動時間・配布サイズ最適化
Acceptance Criteria:
- `nyash --compile-native app.nyash -o app.exe` 動作
- 起動時間大幅短縮（JIT起動コスト除去）
- 配布可能実行ファイル生成
Priority: **Critical** (Phase 8.6完了直後)
Expected Duration: 2-3週間
### 技術的実装詳細
🤖 Copilot協力期待:
- wasmtime::Config統一実装
- .cwasm生成・実行パイプライン
- 互換性キー管理（CPU機能・wasmtimeバージョン）
- パッケージング（単一バイナリ梱包）
### パフォーマンス目標
- 現在のWASM JIT (13.5倍実行) → AOT (500倍目標：起動含む)
- 配布ファイルサイズ: <10MB目標
- 起動時間: <100ms目標
### 期待される効果
- **即座実用価値**: 配布可能実行ファイル生成
- **差別化優位**: Everything is BoxのネイティブAOT実現
- **LLVM準備**: AOT基盤確立でLLVM移行準備
------------------------------------------------------------
## 🌐 Phase 9.5: HTTPサーバー実用テスト（AOT検証）
Summary:
- AOT実装完了後の複雑アプリケーション検証（並行処理・メモリ管理・実用性能）
Scope/Tasks:
- tiny-web-server実装（HTTP/1.1対応）
- 同時接続・早期切断・例外経路テスト
- AOT環境での真の性能測定
- 配布可能HTTPサーバーデモ
Acceptance Criteria:
- `http_server.exe`として配布可能
- 同時100接続でメモリリークなし
- fini()システム確実動作（I/Oハンドル解放）
- AOT性能でベンチマーク測定
Priority: High (Phase 9完了直後)
Expected Duration: 2週間
### 技術的複雑度
```nyash
box HTTPServer {
init { clients, requests, handlers }
acceptConnections() {
loop(me.running) {
local client = me.socket.accept()
nowait me.handleClient(client) // 非同期並行処理
}
}
handleClient(client) {
local request = client.readRequest()
local response = me.processRequest(request)
client.sendResponse(response)
client.fini() // 重要: 確実なリソース解放
}
}
```
### 検証ポイント
- **並行処理**: nowait/awaitのAOT実行性能
- **メモリ管理**: Server→Clients→Requests木構造+weak参照
- **I/Oリソース**: ソケット・ファイルハンドルの確実解放
- **実用性能**: リアルHTTP負荷でのAOT効果測定
### 🤖 Copilot協力期待
- Socket・HTTP実装の効率化
- 複雑なメモリ管理パターン検証
- 負荷テスト・ベンチマーク整備
- AOT最適化効果の定量測定
------------------------------------------------------------
## 🏆 Phase 10: LLVM Direct AOT（最高性能実現）
Summary:
- MIR→LLVM IR直接変換による最高性能AOT実現（Cranelift JITスキップ）
Scope/Tasks:
- MIR→LLVM IR lowering実装
- エスケープ解析・ボックス化解除
- LTO・PGO・高度最適化統合
- Everything is Box最適化
Acceptance Criteria:
- 1000倍高速化達成
- プロダクションレベル最適化
- 他言語との競争力確立
Priority: Medium (Phase 9.5完了後)
Expected Duration: 4-6ヶ月
### 技術アプローチ
🤖 Copilot協力期待:
- **LLVM統合**: MIR→LLVM IR変換基盤
- **エスケープ解析**: Box→スタック値最適化
- **型特殊化**: コンパイル時型推論・特殊化
- **LTO統合**: Link-time optimization
- **PGO対応**: Profile-guided optimization
### Everything is Box最適化戦略
- **Box回避**: スタック割り当て・直接レジスタ配置
- **NaN Boxing**: 効率的な値表現
- **型推論**: コンパイル時型特定・最適化
- **メモリレイアウト**: 連続配置・キャッシュ効率
### パフォーマンス目標
- **実行性能**: 1000倍高速化（現在13.5倍 → 目標13500倍相当）
- **メモリ効率**: Box割当数80%削減
- **起動時間**: ネイティブレベル（<10ms）
- **競合比較**: C/C++/Rust並みの性能
### Cranelift JIT位置づけ変更
**Phase 12以降の将来オプション**:
- JIT開発体験向上（nyashプログラマー向け）
- REPL・インタラクティブ実行
- プロファイル駆動最適化
- 言語完成後の付加価値機能
------------------------------------------------------------
## 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.3完了・次期フェーズ準備
### MIRダイエット準備
❓ 現在35命令→20命令削減のintrinsic戦略実装は？
❓ ChatGPT5推奨の3-point setアプローチ最適化は？
❓ Portability Contract v0での互換性確保方法は？
### Phase 9 AOT WASM実装（最優先）
❓ wasmtime compileの実用配備方法は？
❓ .cwasm生成・単一バイナリ梱包戦略は？
❓ 互換性キー管理（CPU機能・wasmtimeバージョン）は？
❓ 起動時間最適化の実装アプローチは？
### Phase 9.5 HTTPサーバー検証
❓ Socket・HTTP実装の効率的な設計は？
❓ 並行処理でのメモリ管理パターンは？
❓ AOT環境でのI/Oリソース管理は？
❓ 負荷テスト・ベンチマーク設計は？
### Phase 10 LLVM Direct AOT
❓ MIR→LLVM IR変換の効率実装は？
❓ エスケープ解析・ボックス化解除の実装戦略は？
❓ LTO・PGO統合の技術的ハードルは？
## 🚀 長期戦略相談
### Everything is Box最適化
❓ Box操作の根本的高速化戦略は？
❓ エスケープ解析によるスタック化判定は？
❓ 型特殊化・ボックス化解除の実装戦略は？
### ベンチマーク拡張
❓ AOT性能測定の追加指標は？
❓ 1000倍高速化実現のマイルストーン設計は？
❓ 他言語(JavaScript V8, Rust, C++)との競争力分析は？
❓ HTTPサーバー負荷テストの効率設計は？
================================================================================
📊 進捗管理・コミュニケーション
================================================================================
## 🤝 協調開発ルール
### コミット・マージ戦略
✅ 大きな変更前にはdocs/CURRENT_TASK.mdで情報共有
✅ ベンチマーク機能は最優先で維持
✅ CLI統合は両機能を統合的に対応
✅ 競合発生時は機能優先度で解決
### 進捗報告
📅 週次: 進捗状況をCURRENT_TASK.mdに反映
📅 完了時: 新機能のベンチマーク結果を共有
📅 問題発生: AI大会議で技術的相談
### 品質保証
✅ cargo check でビルドエラーなし
✅ 既存ベンチマークが regression なし
✅ 新機能のドキュメント整備
✅ テストケース追加・CI通過
================================================================================
🎯 期待される成果・インパクト
================================================================================
## Phase 8完了時の成果 (達成済み)
🏆 RefNew/RefGet/RefSet WASM完全動作
🏆 Box操作ベンチマーク追加
🏆 メモリレイアウト最適化効果測定
🏆 オブジェクト指向プログラミングWASM対応
🏆 25命令MIR階層化完了（Phase 8.5）
🏆 VM性能改善完了（Phase 8.6）
## Phase 9-10実用優先展望
🚀 **AOT WASM実装** (Phase 9 - 2-3週間): 配布可能実行ファイル
🚀 **HTTPサーバー検証** (Phase 9.5 - 2週間): 実用アプリデモ
🚀 **LLVM Direct AOT** (Phase 10 - 4-6ヶ月): 1000倍高速化
🚀 **実用競争力確立**: 他言語との差別化完成
## 言語としての完成度向上
💎 Everything is Box哲学のネイティブ実現
💎 開発効率性と実行性能の両立
💎 4つの実行形態対応（Interpreter/VM/WASM/AOT）+ 将来JIT
💎 現代的言語としての地位確立
================================================================================
📞 連絡・相談方法
================================================================================
技術的相談や進捗報告は、以下の方法でお気軽にどうぞ：
1. 📝 GitHub Issues・Pull Request
2. 📋 docs/CURRENT_TASK.md コメント
3. 🤖 AI大会議 (重要な技術決定)
4. 💬 コミットメッセージでの進捗共有
どんな小さなことでも相談大歓迎です！
一緒にNyashを最高の言語にしていきましょう🚀
================================================================================
最終更新: 2025-08-14 (実用優先戦略・Phase 9-10再設計完了)
作成者: Claude (AI大会議結果 + 実用優先戦略統合)
🎯 重要な変更点:
- Phase 9: JIT planning → AOT WASM実装（最優先）
- Phase 9.5: HTTPサーバー実用テスト追加（AOT検証）
- Phase 10: AOT exploration → LLVM Direct AOT（最高性能）
- Cranelift JIT: Phase 12以降の将来オプションに変更
- HTTPサーバー: kilo後のタイミングで実用性能検証に特化
================================================================================

657
docs/development/roadmap/native-plan/copilot_issues_phase0_to_94.txt Normal file
View File

@ -0,0 +1,657 @@
# 🤖 Copilot様 作業予定・課題整理 (Phase 0-9.4 アーカイブ版)
# Generated: 2025-08-14 (Git履歴から復元・更新)
# Purpose: Claude×Copilot協調開発のための情報共有
# Status: Phase 9.5より前のアーカイブ版（2025-08-15分割）
================================================================================
🎯 次期最優先タスク (Phase 8.5以降)
================================================================================
## 🚀 Phase 8.4完了報告 (2025-08-14)
Status: ✅ 完了 (Copilot PR #56マージ済み)
### ✅ AST→MIR Lowering完全実装
- User-defined Box: `box DataBox { init { value } }`
- Object creation: `new DataBox(42)`
- Field access: `obj.value`
- Method calls: `c.increment()`
- Delegation: `from Parent.greet()`
- Static Main互換性維持
### 🧪 統合テスト結果（2025-08-14）
- ✅ **AST→MIR**: 完全動作
- ✅ **インタープリター**: 完全動作（結果30）
- 🚨 **VM**: 動作するが結果が`void`（要修正）
- 🚨 **WASM**: String constant未対応（Phase 8.5で解決）
### 📋 発見された課題
- VM実行結果問題: BoxCall後の戻り値が正しく返らない
- WASM対応不足: 複雑なMIR命令（String constant, BoxCall）に未対応
- 次期Phase 8.5での25命令MIR階層化が必要
================================================================================
## 🔧 Phase 8.5: MIR 26命令階層化（最優先）
Status: ⭐ **CRITICAL**
Priority: **最重要** (Phase 8.4完了直後の次期目標)
### 🎯 実装目標
ChatGPT5 + AI大会議決定版26命令MIR実装（ExternCall追加）
- 期間: 3週間
- 効果: VM/WASM問題根本解決
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md`
### 📋 26命令セマンティック階層化
**Tier-0: 普遍コア（8命令）**
```mir
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```
**Tier-1: Nyashセマンティクス（13命令）**
```mir
NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, ExternCall, Safepoint,
RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
```
**Tier-2: 実装補助・最適化友好（5命令）**
```mir
TailCall, Adopt, Release, MemCopy, AtomicFence
```
### 🎯 期待される効果
- **VM問題解決**: BoxCallの正しい実装で戻り値問題修正
- **WASM対応**: 階層化により複雑MIR→単純WASM変換
- **Everything is Box**: BoxFieldLoad/Storeで明確なBox中心設計
- **JIT準備**: セマンティクス保持で高度最適化基盤確立
================================================================================
## 🏎️ Phase 8.6: VM性能改善（緊急）
Status: 🚨 **緊急**
Priority: **High** (Phase 8.5完了後)
### 🚨 緊急問題
**現状**: VM（119.80ms）< Interpreter（110.10ms）= 0.9倍の性能劣化
**新問題**: VM BoxCall後の戻り値が`void`（Phase 8.4テストで発見）
### 📋 技術的課題
- VM実行エンジンのプロファイリング
- 命令ディスパッチ最適化（threaded code等）
- レジスタベースVM化検討
- メモリプール最適化
- BoxCall実装修正（戻り値問題）
### 🎯 成功基準
- VM性能 > Interpreter性能（最低2倍目標）
- BoxCall戻り値の正常動作
- MIR→VM変換時間の短縮
================================================================================
## 🧪 Phase 8.7: Real-world Memory Testing
Status: 📋 **計画済み**
Priority: **High** (Phase 8.5-8.6完了後)
### 🎯 実装目標
kilo（テキストエディタ）実装によるfini/weak参照システム実証
- 期間: 2週間
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md`
### 📋 検証項目
- 1000+オブジェクト管理テスト
- 循環参照回避確認（weak参照）
- fini()伝播の正確性確認
- WASM環境での動作確認
================================================================================
🗺️ Phase 0-14 全体ロードマップ (復元完了)
================================================================================
## Phase 0: Stabilize native CLI build (Linux/Windows)
Summary:
- CLIバイナリ nyash を最小構成で安定ビルド・実行できる状態にする。
- examples/GUI をデフォルトのビルド対象から外し、開発の足場を固める。
Why:
- 以降の MIR/VM/JIT 開発を素早く検証できる基盤づくり。
Scope:
- Cargo の features で GUI/examples 等を切り分け、デフォルトは CLI 最小にする。
- CLI オプションの動作点検（--dump-mir / --verify）。
- ローカル実行導線を README に明記（docs/guides/how-to-build-native/README.md）。
Tasks:
- Cargo.toml: examples/GUI を feature でガード（default は CLI 最小）。
- ビルド検証: `cargo build --bin nyash`（Linux/Windows）。
- 実行検証: `cargo run -- ./local_tests/sample.nyash`。
- ドキュメント: 上記手順を how-to-build-native に追記/点検。
Acceptance Criteria:
- Linux/Windows で `cargo build --bin nyash` が成功する。
- `local_tests/` 配下の簡単な .nyash が実行できる。
- 他 bin/examples が壊れていても `--bin nyash` だけで通る。
Out of Scope:
- examples/GUI の修理・最適化。
- JIT/AOT/WASM。
References:
- docs/guides/how-to-build-native/README.md
- docs/nativebuild大作戦/chatgptネイティブビルド大作戦.txt（Phase 0）
- CURRENT_TASK.md
Copilot Notes:
- まずは features 分離と `--bin nyash` でビルドが通る状態を作る。README の手順確認まで含めて PR に反映。
------------------------------------------------------------
## Phase 1: Minimal MIR + VM backend (lowering + runner)
Summary:
- AST → MIR の最小 lowering と、VM バックエンドでの実行を通す。
Scope:
- MIR: Const, BinOp, Compare, Branch, Jump, Phi, Return の最小命令
- Lowering: リテラル/二項演算/if/loop/return のみ
- VM: 上記命令の最小実装
Tasks:
- instruction.rs: 最小命令の定義
- builder.rs: 上記 AST 範囲を lowering
- vm.rs: 実装 + stats（命令数）
Acceptance Criteria:
- `--dump-mir` が最小サンプルで期待通り
- `--backend vm` で実行して結果一致
Out of Scope:
- 例外/関数/Box 参照/弱参照
------------------------------------------------------------
## Phase 2: Control-flow coverage (if/else/loop/phi correctness)
Summary:
- 制御フローの網羅と Phi の整合性検証を拡充。
Scope/Tasks:
- if/else nested, loop with breaks, nested loops のスナップショット
- Phi の入力ブロック/値の対応を Verifier で強化
Acceptance Criteria:
- 代表制御フローの snapshot が安定し、verify も通る
------------------------------------------------------------
## Phase 3: Exceptions (throw/try/catch/finally) minimal lowering
Summary:
- 例外機構の最小 lowering を導入（詳細設計は簡素）。
Scope/Tasks:
- MIR: Throw, TryBegin/TryEnd, Catch, FinallyBegin/End（最小）
- builder.rs: try/catch/finally ノードの下ろし
- VM: 例外伝播を最小で（未捕捉はエラー）
Acceptance Criteria:
- 代表 try/catch/finally のスナップショットと VM 実行
Out of Scope:
- 例外の型体系、詳細な stack map
------------------------------------------------------------
## Phase 4: Functions and calls (BoxCall minimal)
Summary:
- 関数呼び出し/BoxCall を最小導入（効果注釈は保守的）。
Scope/Tasks:
- MIR: Call, BoxCall（effects = READS_HEAP など保守）
- builder.rs: FunctionCall/MethodCall の最小対応
- VM: 呼び出し/戻り値
Acceptance Criteria:
- 簡単な関数定義/呼び出しの MIR/VM が通る
Out of Scope:
- 可変長/キーワード引数、FFI
------------------------------------------------------------
## Phase 5.0: Parser/AST stabilization for lowering
Summary:
- lowering 対象 AST の表現ぶれを修正、安定化。
Scope/Tasks:
- AST: If/Loop/Return/Assignment/Local などの統一
- Parser: エラー復帰/スパン情報の見直し
Acceptance Criteria:
- builder.rs の分岐がシンプル化、テストが安定
------------------------------------------------------------
## Phase 5.1: Control-flow edge cases + verifier hardening
Summary:
- ブロック未終端/未到達/自己分岐等の検証強化でクラッシュ回避。
Scope/Tasks:
- Verifier: 未終端ブロック検出、到達不能検出
- Builder: Jump/Branch の生成前後の状態管理改善
Acceptance Criteria:
- 不正ケースを含むスナップショット/verify が緑
------------------------------------------------------------
## Phase 5.2: Lowering for static box Main (BoxDeclaration → main body)
Summary:
- static box Main { main() { ... } } を MirBuilder で受け、main() の body を Program として lowering する経路を実装。
Scope/Tasks:
- AST: BoxDeclaration(is_static=true, name=Main) を検出 → main() を抽出
- Lowering: body を Program に変換して既存経路に渡す
- Tests: local_tests/mir_loop_no_local.nyash で dump/VM が通る
Acceptance Criteria:
- `--dump-mir` が static Main サンプルで成功
- `--backend vm` で実行成功
References:
- docs/guides/how-to-build-native/issues/phase5_2_static_main_lowering.md
------------------------------------------------------------
## Phase 6: Box ops minimal (Ref/Weak + Barriers no-op)
Summary:
- 参照/弱参照/バリア（no-op）を最小導入。
Scope/Tasks:
- MIR: RefNew/RefGet/RefSet/WeakNew/WeakLoad/BarrierRead/Write
- Lowering: New/FieldAccess/MethodCall の最小対応
- VM: 参照テーブル/weak テーブルで動作（fini 不変は維持）
Acceptance Criteria:
- 代表サンプルで dump/VM/verify が通る
References:
- docs/guides/how-to-build-native/issues/phase6_box_ops_minimal.md
------------------------------------------------------------
## Phase 7: Async model (nowait/await) in MIR
Summary:
- nowait/await を MIR に導入し、現行 FutureBox と連携。
Scope/Tasks:
- MIR: FutureNew/FutureSet/Await（スレッドベース）
- Lowering: nowait→Future 作成、await→wait_and_get
- VM: FutureBox 実装を利用
Acceptance Criteria:
- 代表ケースで正しく並行実行→await 回収
References:
- docs/guides/how-to-build-native/issues/phase7_async_mir.md
------------------------------------------------------------
## Phase 8: MIR→WASM codegen (browser/wasmtime; sandboxed; Rust runtime free)
Summary:
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
- Rust はコンパイラ本体のみ。実行は純WASM＋ホストimport（env.print など）。
Scope/Tasks:
- ABI/Imports/Exports 定義（exports: main/memory、imports: env.print(i32) 等の最小）
- 線形メモリと簡易ヒープ（bump/自由リスト）
- 命令カバレッジ（段階導入）: 算術/比較/分岐/loop/return/print、RefNew/RefSet/RefGet（Phase 6 整合）、Weak/Barrier はダミー
Acceptance Criteria:
- wasmtime 実行で戻り値/print が期待通り（PoC1–2）
- Ref 系がメモリ上で正しく動作（PoC2）
- Weak/Barrier のダミー実装を含むWASMが生成・実行（PoC3）
- CLI `--backend wasm` は未実装でもよいが、実装する場合は明瞭にエラーメッセージ/誘導
References:
- docs/予定/native-plan/README.md（Phase 8 節）
- docs/説明書/wasm/*（ユーザー向けメモ）
### Phase 8.3 完了状況 (2025-08-14)
✅ Box操作WASM実装 (RefNew/RefGet/RefSet)
✅ ベンチマークシステム統合 (13.5倍実行高速化実証)
✅ CLI統合完了
------------------------------------------------------------
## 🔧 Phase 8.4: AST→MIR Lowering完全実装 (最優先)
Summary:
- ユーザー定義Box、フィールドアクセス等の未実装部分を完成
- Phase 8.3のBox操作WASMを実際にテスト可能にする
Priority: **Critical** (現在の最優先事項)
Expected Duration: 1週間
### 実装範囲
- [ ] ユーザー定義Box: `box DataBox { init { field } }`
- [ ] オブジェクト生成: `new DataBox()`
- [ ] フィールドアクセス: `obj.field`
- [ ] フィールド代入: `obj.field = value`
- [ ] from構文: `from Parent.method()`
- [ ] override構文: `override method() { ... }`
### 成功基準
- Phase 8.3のBox操作WASMが実際に動作
- test_wasm_box_ops.nyash が正常実行
- ユーザー定義Boxの完全サポート
------------------------------------------------------------
## 🧠 Phase 8.5: MIRセマンティック階層化（AI大会議決定版）
Summary:
- 方針転換: ChatGPT5の20命令intrinsic戦略 → Gemini+Codex一致推奨の26命令階層化（ExternCall追加）
- 理由: JIT/AOT最適化阻害・Everything is Box意味喪失・長期コスト増の問題判明
- 二相ロワリング: 26命令維持パス（VM/JIT/AOT）+ 21+intrinsic降格パス（WASM/最小実装）
Priority: High (Phase 8.4完了後)
Expected Duration: 3週間
### AI大会議分析結果
**Gemini先生（理論）**: 「賢いコンパイラは、賢いMIRから生まれる」
- RefNew/WeakLoadのintrinsic化は最適化機会を失う悪手
- セマンティック階層化で意味保持が最適化の鍵
**Codex先生（実装）**: 二相ロワリング戦略が実用的最適解
- 実装コスト: 5命令追加で10-20人日（intrinsic戦略より安い）
- マイクロベンチ実測でパフォーマンス検証
### 確定版MIR（26命令）- ChatGPT5完全仕様 + ExternCall統合
**Tier-0: 普遍的コア（8命令）**
```mir
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```
**Tier-1: Nyashセマンティクス（13命令）**
```mir
NewBox, // 強所有のBox生成（所有森のノード）
BoxFieldLoad, // Boxのフィールド読み（Everything is Box核心）
BoxFieldStore, // Boxのフィールド書き（mut効果）
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
ExternCall, // 外部ライブラリをBoxとして呼び出し（Universal Exchange）
Safepoint, // 分割finiや割込み許可ポイント
RefGet, // 参照（強/弱を問わず）を値として取得
RefSet, // 参照の差し替え（所有規則検証付き）
WeakNew, // weak ハンドル生成（非所有リンク作成）
WeakLoad, // weak から生存チェック付きで強参照取得（失効時null）
WeakCheck, // weak の生存確認（bool）
Send, // Bus送信（io効果）
Recv // Bus受信（io効果）
```
**Tier-2: 実装補助・最適化友好（5命令）**
```mir
TailCall, // 末尾呼び出し（スタック節約）
Adopt, // 所有移管: this が子を強所有に取り込む
Release, // 強所有を解除（weak化 or null化）
MemCopy, // 小さなメモリ移動（構造体/配列最適化フック）
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
```
### 二相ロワリング戦略
- パスA: VM/JIT/AOT向け（26命令のまま最適化）
- パスB: WASM/最小実装向け（26→21+intrinsic降格）
- バックエンド能力に応じて最適形式選択
### 効果（Effect）システム（ChatGPT5設計 + ExternCall統合）
- **pure**: Const, BinOp, Compare, Phi, RefGet, WeakNew, WeakLoad, WeakCheck
- **mut**: BoxFieldStore, RefSet, Adopt, Release, MemCopy
- **io**: Send, Recv, Safepoint, AtomicFence
- **control**: Branch, Jump, Return, TailCall
- **context依存**: Call, BoxCall, ExternCall（呼び先効果に従属・BID定義に基づく）
**最適化ルール**: 「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」
### 検証（Verifier）要件
- **所有森**: `strong in-degree ≤ 1`（NewBox/Adopt/Release/RefSetで常時検査）
- **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
- **weak/強相互**: 双方向とも強 → エラー（片側はWeakNew経由で弱化）
- **WeakLoad/WeakCheck**: 失効時はnull/falseを返す（例外禁止、決定的挙動）
### 🤖 Copilot協力期待
- **Tier-0/1実装**: Everything is Box哲学の完璧なIR化（BoxFieldLoad/Store核心）
- **weak参照システム**: WeakNew/WeakLoad/WeakCheck三位一体実装
- **所有移管**: Adopt/Release命令による安全で効率的なメモリ管理
- **効果システム**: pure/mut/io/control効果の正確な実装とVerifier統合
- **最適化フック**: TailCall/MemCopy/AtomicFenceの実装補助
- **二相ロワリング**: 25命令維持パス + 20+intrinsic降格パス構築
### 成功基準
- [ ] **26命令完全実装**: ChatGPT5仕様 + ExternCall統合の完璧な実装
- [ ] **効果システム動作**: pure再順序化・mut依存保持・io順序保証
- [ ] **Verifier動作**: 所有森・strong循環・安全性検証
- [ ] **Golden MIRテスト**: 全バックエンドでMIR一致
- [ ] **行動一致テスト**: 同入力→同出力（weak失効時null/false含む）
- [ ] **性能要件**: VM≥Interpreter、WASM≥VM継続検証
### バックエンド指針（ChatGPT5設計 + ExternCall統合）
- **Interpreter**: 26命令を素直に実装（正しさの基準）
- **VM**: Register-VM + direct-threading。Send/Recvはローカル判定時にインライン化
- **WASM**: Send/Recvはhost import。MemCopyはmemory.copyに対応
- **JIT（将来）**: TailCall最適化、WeakLoadは世代タグでO(1)生存チェック
References:
- docs/予定/native-plan/MIR仕様書.txt（ChatGPT5完全仕様）
- docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md
------------------------------------------------------------
## 🏎️ Phase 8.6: VM性能改善 (緊急)
Summary:
- VMがインタープリターより遅い問題（0.9倍）を解決
- MIR→VM実行の最適化でインタープリターを上回る性能へ
Priority: High (Phase 8.5完了後)
Expected Duration: 2週間
### 問題分析
**現状**: VM (119.80ms) < Interpreter (110.10ms)
**推定原因**:
- MIR変換オーバーヘッド
- VM命令ディスパッチの非効率性
- メモリ管理コスト
### 技術的アプローチ
- [ ] VM実行エンジンのプロファイリング
- [ ] 命令ディスパッチ最適化（threaded code等）
- [ ] レジスタベースVM化検討
- [ ] メモリプール最適化
### 🤖 Copilot協力期待
- VM実装のボトルネック特定
- 効率的な命令ディスパッチ実装
- スタックマシン vs レジスタマシン判断
### 成功基準
- VM性能 > Interpreter性能（最低2倍目標）
- MIR→VM変換時間の短縮
- メモリ使用量の削減
------------------------------------------------------------
## 🧪 Phase 8.7: Real-world Memory Management Testing (ChatGPT協調設計)
Summary:
- 実用アプリケーション開発によるNyashメモリ管理システムの実証テスト
- finiシステム・weak参照の実用性を複雑なアプリケーションで検証
Priority: High (Phase 8.4-8.6完了直後)
Expected Duration: 2週間
### Phase 8.7A: kilo（テキストエディタ）
**技術的特徴**:
- サイズ: <1k LOC（超小型、最初の成功体験）
- メモリパターン: Editor -> (Rows -> Syntax) 木構造＋相互参照
- ChatGPT設計: Editor削除でRows自動解放、逆参照をweak化
**実装範囲**:
- [ ] Editor/Row/EditorState基本構造実装
- [ ] weak参照による循環参照回避（`me.editor = weak editor_ref`）
- [ ] fini()システムによる自動メモリ解放
- [ ] 大量オブジェクト（1000+ Rows）管理テスト
**検証ポイント**:
- [ ] Editor削除でRows自動解放確認
- [ ] 相互参照でメモリリークなし確認
- [ ] weak参照の自動null化確認
- [ ] fini()伝播の正確性確認
### Phase 9.5予定: tiny-web-server（HTTPサーバ）
**将来実装**（JIT実装後）:
- 複雑度: 中〜高（Server -> Clients -> Requests並行処理）
- I/O管理: ソケット・ファイルハンドルの確実解放
- 同時接続・早期切断・例外経路でのfini伝播テスト
### 🤖 Copilot協力期待
- 実用的なメモリ管理パターンの実装
- weak参照構文の適切な使用
- デバッグ支援機能（--debug-memory, --trace-weak）
- WASM環境でのメモリ管理互換性
### 成功基準
- [ ] 全テストケースでメモリリークなし
- [ ] 循環参照でも正常解放確認
- [ ] WASM実行でもメモリ管理正常
- [ ] ベンチマーク性能劣化なし
### 期待される効果
- Nyashメモリ管理システムの実用性実証
- Everything is Box哲学の実用レベル確認
- メモリ安全なプログラミングパターン確立
References:
- docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md
------------------------------------------------------------
## 🚀 Phase 9: AOT WASM実装（最優先）
Summary:
- wasmtime compileによるAOT実行ファイル生成で確実なユーザー価値提供
Scope/Tasks:
- `wasmtime compile` 統合実装
- `--compile-native` / `--aot` CLI追加
- 単一バイナリ梱包（`include_bytes!`）
- 起動時間・配布サイズ最適化
Acceptance Criteria:
- `nyash --compile-native app.nyash -o app.exe` 動作
- 起動時間大幅短縮（JIT起動コスト除去）
- 配布可能実行ファイル生成
Priority: **Critical** (Phase 8.6完了直後)
Expected Duration: 2-3週間
### 技術的実装詳細
🤖 Copilot協力期待:
- wasmtime::Config統一実装
- .cwasm生成・実行パイプライン
- 互換性キー管理（CPU機能・wasmtimeバージョン）
- パッケージング（単一バイナリ梱包）
### パフォーマンス目標
- 現在のWASM JIT (13.5倍実行) → AOT (500倍目標：起動含む)
- 配布ファイルサイズ: <10MB目標
- 起動時間: <100ms目標
### 期待される効果
- **即座実用価値**: 配布可能実行ファイル生成
- **差別化優位**: Everything is BoxのネイティブAOT実現
- **LLVM準備**: AOT基盤確立でLLVM移行準備
------------------------------------------------------------
## 🔴 Phase 9.51: WASM Jump/Branch実装とHTTPサーバー実用化 **【緊急修正】**
Status: 🔴 **Critical Issue**（Phase 9実用化ブロッカー）
Summary:
- Phase 9 (PR #67) 完了後に判明した重大制約の修正
- WASM/AOT実用化の最終仕上げ
### 🚨 現在の問題（実用化を阻害）
1. **WASM/AOT コンパイルエラー（最重要）**
```bash
$ ./target/release/nyash --compile-wasm test_simple_loop.nyash
❌ Unsupported instruction: Jump { target: BasicBlockId(1) }
```
**影響**: ループ・条件分岐を含む全プログラムがWASM/AOT化不可
2. **HTTPServerBox listen()常に失敗**
- server.bind() ✅, server.listen() ❌ always false
**影響**: HTTPサーバーが実際には動作しない
3. **エラーハンドリング脆弱性**
- unwrap()使用箇所: 26箇所 → パニック多発リスク
### Scope/Tasks:
**🔴 Task 1**: WASM Jump/Branch命令実装（2日）
- `src/backend/wasm/codegen.rs`にJump/Branch追加
- ブロック深度管理（`get_block_depth`メソッド）
- ループ構造のblock/loop/end生成
**🔴 Task 2**: SocketBox listen()修正（1日）
- `src/boxes/socket_box.rs`の実装修正
- SocketStatus::Listening状態管理
**🟡 Task 3**: エラーハンドリング改善（2日）
- HTTPServerBox/SocketBoxのunwrap()除去
- Result<T,E>ベースのエラー処理
**🟡 Task 4**: HTTPサーバー実用化（2日）
- スレッドプール実装（固定サイズワーカー）
- グレースフルシャットダウン
Acceptance Criteria:
- ✅ `nyash --compile-wasm test_loop.nyash` 成功
- ✅ HTTPサーバー実動作（curl http://localhost:8080/）
- ✅ unwrap()使用箇所: 26 → 5以下
- ✅ WASM性能: 11.5倍 → 13.5倍達成
Priority: **🔴 Critical** (Phase 9.5開始前の必須修正)
Expected Duration: 1週間
### 詳細設計・実装指示
📋 **完全実装ガイド**: `docs/予定/native-plan/issues/phase9_51_wasm_jump_http_fixes.md`
🤖 **Copilot協力依頼**:
- WASM br/br_if命令実装
- HTTPサーバーリファクタリング
- エラーハンドリング統一
### 期待される効果
- **実用性達成**: ループ・HTTPサーバーのWASM/AOT化
- **安定性向上**: パニックフリーな実装
- **Phase 9.5準備**: 複雑アプリケーションテストの基盤確立
------------------------------------------------------------
================================================================================
最終更新: 2025-08-15 (Phase 9.5より前をアーカイブ分割)
作成者: Claude (ドキュメント分割・整理)
🎯 分割理由:
- copilot_issues.txtの肥大化対策（1200行→600行程度に削減）
- Phase 9.5以降の現行計画と完了済み部分の明確分離
- ドキュメント検索性・保守性の向上
================================================================================

156
docs/development/roadmap/native-plan/llvm/AI-Conference-LLVM-Results.md Normal file
View File

@ -0,0 +1,156 @@
# 🤖 AI大会議結果: LLVM PoC実装戦略統合文書
**作成日**: 2025年8月20日
**参加AI**: Gemini先生、Codex先生、Claude
**目的**: Phase 9.78 LLVM PoC実装の統合戦略策定
## 📋 **エグゼクティブサマリー**
AI大会議の結果、以下の統合戦略が決定されました：
1. **技術基盤**: `inkwell`クレート + 既存ランタイム活用のハイブリッド戦略
2. **Box型表現**: LLVM `ptr`型 + ランタイム関数によるメモリ管理
3. **実装期間**: 3週間で基本動作確認（Hello World〜算術演算）
4. **性能目標**: 計算集約処理で数十倍の高速化実証
## 🎯 **統合実装戦略**
### **Week 1: 基盤構築とHello World**
**Gemini先生推奨アプローチ**:
```rust
// inkwellクレートで型安全なLLVM操作
use inkwell::context::Context;
use inkwell::module::Module;
use inkwell::builder::Builder;
struct CodegenContext<'ctx> {
context: &'ctx Context,
module: Module<'ctx>,
builder: Builder<'ctx>,
type_cache: HashMap<MirType, BasicTypeEnum<'ctx>>,
}
```
**Codex先生の具体的タスク**:
- ✅ `inkwell`セットアップ
- ✅ MIR `Const`, `Return`命令の変換
- ✅ ランタイム関数宣言 (`nyash_alloc`, `nyash_free`)
- ✅ `.o`ファイル生成とCランタイムリンク
**統合成果物**: `return 42`が動作するLLVM実装
### **Week 2: 制御フローとBox MVP**
**Gemini先生のBox型戦略**:
```rust
// Box型 = LLVM ptr型として表現
fn box_to_llvm_type<'ctx>(ctx: &CodegenContext<'ctx>) -> PointerType<'ctx> {
ctx.context.i8_type().ptr_type(AddressSpace::Generic)
}
// ランタイム関数経由でBox操作
extern "C" {
fn nyash_runtime_box_new(size: u64, align: u64) -> *mut c_void;
fn nyash_runtime_box_free(ptr: *mut c_void, size: u64, align: u64);
}
```
**Codex先生の実装順序**:
1. SSA/PHI命令の実装
2. `Branch`, `Jump`による制御フロー
3. Box基本操作（new/free/deref）
4. `LLVMVerifyModule`による検証
**統合成果物**: 条件分岐とBox操作を含むプログラムの動作
### **Week 3: 統合とベンチマーク**
**性能検証（Gemini先生）**:
- 計算集約的ベンチマーク実装
- インタープリター/VM/LLVMの性能比較
- 期待値: 数十倍の高速化実証
**堅牢性確保（Codex先生）**:
- 差分テスト（Interpreter vs LLVM）
- 最小最適化パス（`mem2reg`, `instcombine`）
- クラッシュ時の`.ll`ファイル保存
## 🔧 **技術的詳細**
### **MIR→LLVM命令マッピング**
| MIR命令 | LLVM IR | 実装方法 |
|---------|---------|----------|
| Const | ConstantInt/Float | inkwell定数生成 |
| BinOp(Add) | add/fadd | builder.build_add() |
| Compare | icmp/fcmp | builder.build_int_compare() |
| BoxCall | call @nyash_runtime_box_call | ランタイム委譲 |
| Branch | br | builder.build_conditional_branch() |
| Return | ret | builder.build_return() |
### **エラー頻発箇所と対策**
**Gemini先生の警告**:
- ❌ `Arc<Mutex>`をLLVMで再実装しない
- ✅ 既存ランタイムの`#[no_mangle] extern "C"`関数を呼ぶ
**Codex先生の実装Tips**:
- `alloca`は関数エントリーブロックのみ
- GEPインデックスは`i32`型で統一
- DataLayoutは必ずTargetMachineから取得
### **プラグイン統合（BID-FFI）**
**Gemini先生**: C-ABIは既にLLVMと相性が良い
```llvm
declare i32 @nyash_plugin_invoke(i8*, i64, i8*, i64*)
```
**Codex先生**: リンク時に`.so`/`.a`を含める
```bash
cc -o output main.o nyash_runtime.o -lplugin
```
## 📊 **成功判定基準（統合版）**
### **最小成功ライン（PoC達成）**
- ✅ 基本算術演算のLLVM実行
- ✅ Box型の基本操作動作
- ✅ Hello Worldレベルの出力
- ✅ 10倍以上の性能向上実証
### **理想的成功（Phase 10への道筋）**
- 🌟 20個以上のMIR命令対応
- 🌟 プラグイン呼び出し成功
- 🌟 50倍以上の性能向上
- 🌟 安定したエラーハンドリング
## 🚀 **Copilotへの最終依頼文書**
```markdown
## Phase 9.78: LLVM PoC実装依頼
**目標**: 3週間でNyash MIR→LLVM変換の基本実装
**技術スタック**:
- inkwellクレート（Gemini推奨）
- 既存ランタイム活用（Arc<Mutex>回避）
- C-ABIプラグイン統合
**実装優先順位**:
1. Week 1: Const/Return/基本setup → "return 42"
2. Week 2: 制御フロー/Box MVP → 条件分岐
3. Week 3: 最適化/ベンチマーク → 性能実証
**成果物**:
- src/backend/llvm/compiler.rs
- ベンチマーク結果（10倍以上高速化）
- Phase 10実装計画
```
## 🎉 **結論**
AI大会議により、技術的に実現可能で、3週間で達成可能な明確な実装戦略が確立されました。inkwellによる型安全な実装と、既存ランタイム活用により、リスクを最小化しながら高速なLLVMバックエンドの実現が期待できます。
**次のアクション**: Copilotへの正式依頼とPhase 9.78開始！🚀

122
docs/development/roadmap/native-plan/llvm/APE-Magic-Explained.md Normal file
View File

@ -0,0 +1,122 @@
# 🪄 APE (Actually Portable Executable) の魔法を解説！
**「えっ、1つのファイルが3つのOSで動くの！？」**
はい、本当です！これは**実在する技術**です！
## 🎩 **APEの魔法の仕組み**
### **実例を見てみよう**
```bash
# これが実際のAPEバイナリ
$ ls -la hello.com
-rwxr-xr-x 1 user user 65536 Aug 20 hello.com
# Linuxで実行
$ ./hello.com
Hello from Linux!
# 同じファイルをWindowsにコピー
> hello.com
Hello from Windows!
# 同じファイルをmacOSで実行
$ ./hello.com
Hello from macOS!
```
**たった1つのファイル `hello.com` が全部で動く！**
## 🔮 **どうやって実現してるの？**
### **秘密：ファイルヘッダーの魔法**
APEファイルの先頭部分：
```
00000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000 MZ.............. # Windows PE
00000010: b800 0000 0000 0000 4000 0000 0000 0000 ........@.......
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0080 0000 0000 ................
00000040: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............ # Linux ELF
```
**同じファイルに複数のOSのヘッダーが共存！**
### **OSごとの読み方**
1. **Windows**: 「MZ」で始まる → PEファイルとして実行
2. **Linux**: ELFマジックナンバーを探す → ELFとして実行
3. **macOS**: Mach-Oヘッダーを探す → Mach-Oとして実行
## 🛠️ **Cosmopolitan Libc - 実在するプロジェクト**
**GitHubで公開されています！**
- https://github.com/jart/cosmopolitan
- 開発者: Justine Tunney (元Google)
- スター数: 17,000+ ⭐
### **実際のビルド方法**
```bash
# Cosmopolitanを使ったビルド
gcc -g -O -static \
-fno-pie -no-pie \
-nostdlib -nostdinc \
-o hello.com \
hello.c \
cosmopolitan.a \
-Wl,--gc-sections \
-Wl,-T,ape.lds
```
## 📊 **APEの利点と制限**
### **利点** ✅
- **配布が超簡単**: 1ファイルで全OS対応
- **依存関係なし**: 完全に自己完結
- **小さいサイズ**: 静的リンクでも小さい
### **制限** ⚠️
- **x86_64のみ**: ARM版はまだ実験的
- **GUI制限**: 基本的にCLIアプリ向け
- **OS固有機能**: 一部制限あり
## 🎯 **NyashでのAPE活用案**
### **段階的アプローチ**
**Phase 1: 通常のマルチターゲット**（現実的）
```bash
nyashc --targets linux,windows,macos
# → 3つの別々のファイル生成
```
**Phase 2: APE実験**（6ヶ月後）
```bash
nyashc --target ape
# → nyash.com (全OS対応の1ファイル！)
```
### **実装イメージ**
```rust
// NyashのLLVM IR → Cコード生成
let c_code = transpile_to_c(&llvm_ir);
// Cosmopolitanでコンパイル
compile_with_cosmopolitan(&c_code, "nyash.com");
```
## 🤔 **本当に必要？**
**正直な評価**：
- **配布簡単さ**: ⭐⭐⭐⭐⭐ 最高！
- **実装難易度**: ⭐⭐ 意外と簡単（Cosmopolitan使えば）
- **実用性**: ⭐⭐⭐ CLIツールなら十分実用的
- **かっこよさ**: ⭐⭐⭐⭐⭐ 最高にクール！
## 💡 **結論**
APEは**「欲張り」じゃなくて「賢い」**アプローチ！
でも、まずは普通のマルチターゲット対応から始めて、APEは「究極の目標」として楽しみに取っておくのが現実的かも？
**にゃーも「Everything is Box」なら、APEは「Everything is ONE Binary」！**🎩✨

117
docs/development/roadmap/native-plan/llvm/Copilot-Request-LLVM-PoC.md Normal file
View File

@ -0,0 +1,117 @@
# 🤖 Copilot様への依頼: Phase 9.78 LLVM PoC実装
**依頼日**: 2025年8月20日
**期限**: 3週間（2025年9月10日）
**優先度**: 最高
## 📋 **依頼概要**
Phase 8.6のVM性能改善で素晴らしい成果（50.94倍高速化）を達成していただきありがとうございました！
次は、Nyash言語の更なる性能向上を目指し、**LLVMバックエンドのProof of Concept実装**をお願いします。
## 🎯 **依頼内容**
### **目標**
3週間でMIR→LLVM IR変換の基本実装を完成させ、実現可能性を実証する
### **成功基準**
1. 基本的なNyashプログラム（算術演算、条件分岐）がLLVM経由で実行可能
2. インタープリター比10倍以上の性能向上を実証
3. Phase 10本格実装への明確な道筋を確立
## 🛠️ **技術仕様**
### **使用技術スタック**
```toml
[dependencies]
inkwell = { version = "0.5", features = ["llvm17-0"] }
```
### **実装アプローチ**
AI大会議（Gemini先生、Codex先生）の推奨に基づく：
- **inkwellクレート**による型安全なLLVM操作
- **Box型はptr型**として表現、操作は既存ランタイムに委譲
- **C-ABI経由**でプラグインとランタイム関数を呼び出し
### **実装対象MIR命令（優先順）**
1. **Week 1**: Const, Return（最小限）
2. **Week 2**: BinOp, Compare, Branch, Jump, BoxNew/Free
3. **Week 3**: 最適化パス、ベンチマーク
## 📁 **作成ファイル構成**
```
src/backend/llvm/
├── mod.rs // エントリポイント
├── context.rs // LLVMコンテキスト管理
├── types.rs // MIR→LLVM型変換
├── builder.rs // IR生成ロジック
├── runtime.rs // ランタイム関数宣言
└── optimizer.rs // 最適化パス
src/backend/llvm_runtime/
└── runtime.c // 最小ランタイム（nyash_alloc等）
```
## 📊 **週次マイルストーン**
### **Week 1: Hello World動作**
- [ ] inkwellセットアップ完了
- [ ] `return 42`がLLVM経由で動作
- [ ] .oファイル生成成功
### **Week 2: 基本機能動作**
- [ ] 四則演算の実装
- [ ] if文の動作確認
- [ ] Box型の基本操作
### **Week 3: 性能実証**
- [ ] ベンチマーク実装
- [ ] 10倍以上の高速化確認
- [ ] 技術レポート作成
## 💡 **実装のヒント**
### **Gemini先生のアドバイス**
- `Arc<Mutex>`の複雑なセマンティクスをLLVMで再実装しないこと
- Box操作は`nyash_runtime_box_*`関数経由で行う
- 計算集約的な処理に注力すれば数十倍の高速化が可能
### **Codex先生の実装Tips**
- allocaは関数エントリブロックのみに配置
- GEPインデックスはi32型で統一
- エラー時は.llファイルをダンプして原因調査
## 🚨 **重要な注意事項**
1. **完璧を求めない** - 3週間でのPoC完成が最優先
2. **既存資産の活用** - MIR構造、ランタイム関数を最大限再利用
3. **段階的実装** - 最小限から始めて徐々に機能追加
## 📚 **参考資料**
- [AI大会議結果](./AI-Conference-LLVM-Results.md) - 技術戦略の詳細
- [実装計画書](./Phase-9.78-Implementation-Plan.md) - 週次スケジュール
- [MIR仕様](../../説明書/reference/execution-backend/mir-26-specification.md) - 命令セット詳細
## 🎉 **期待される成果**
1. **技術的実証**: LLVMバックエンドの実現可能性確認
2. **性能向上**: 10倍以上（理想的には50倍）の高速化
3. **将来への道筋**: Phase 10での本格実装計画
## 🤝 **サポート体制**
- **技術相談**: Claude、Gemini、Codexが随時サポート
- **進捗確認**: 週次でGitHub Issueにて状況共有
- **問題解決**: ブロッカーがあれば即座にAIチームで対応
Copilot様の素晴らしい実装力に期待しています！
Phase 8.6のような劇的な成果を、LLVMでも実現しましょう！🚀
---
**依頼者**: moe-charm + AIチーム
**GitHub Issue**: #（作成予定）
**開始可能日**: 即時

151
docs/development/roadmap/native-plan/llvm/Hybrid-Future-Vision.md Normal file
View File

@ -0,0 +1,151 @@
# 🌈 理想的なハイブリッド実行環境への願望
**「AOT WASMが非同期対応してたら...」**
## 😿 **現在の苦労ポイント**
### **各バックエンドの制限**
| バックエンド | 利点 | 欠点 |
|------------|------|------|
| **WASM** | どこでも動く | 非同期が弱い、遅い |
| **LLVM** | 超高速 | OS別ビルド必要 |
| **VM** | 柔軟 | ネイティブより遅い |
| **AOT** | 高速起動 | プラットフォーム依存 |
### **理想と現実のギャップ**
```rust
// 理想
async fn perfect_world() {
let result = await some_io(); // WASMでも高速非同期
return result;
}
// 現実
fn reality() {
// WASMは同期的、非同期は複雑
// LLVMは速いけどOS別ビルド
// 完璧な解決策がない...
}
```
## 🚀 **夢のハイブリッド環境**
### **1. WASM Component Model + AOT**
```yaml
理想:
- WASMの可搬性
- AOTの実行速度
- ネイティブ非同期サポート
- 単一バイナリで全OS対応
現実:
- Component Model仕様策定中
- AOT最適化はまだ発展途上
- 非同期は部分的サポート
```
### **2. Deno/Bun的アプローチ**
```javascript
// JavaScriptランタイムの良いとこ取り
- V8/JavaScriptCore の JIT性能
- ネイティブバインディング
- 非同期完全サポート
- でもJavaScript...
```
### **3. 究極の理想：Universal Runtime**
```rust
// もしこんなランタイムがあったら...
universal_runtime {
// WASMレベルの可搬性
portability: "write once, run anywhere",
// LLVMレベルの性能
performance: "near native",
// 完全な非同期サポート
async: "first class",
// 単一配布物
distribution: "single file"
}
```
## 💭 **現実的な妥協案**
### **短期的ハイブリッド戦略**
```yaml
開発時:
- インタープリター（即時実行、デバッグ容易）
テスト時:
- VM（高速、クロスプラットフォーム）
配布時:
選択式:
- WASM版: ブラウザ/サーバー両対応
- ネイティブ版: 最高性能
- ハイブリッド版: WASMランタイム埋め込み
```
### **中期的技術統合**
```rust
// Nyashハイブリッドランタイム
pub enum ExecutionMode {
// 高速パス: ネイティブコード
Native(LLVMCompiledCode),
// 互換パス: WASM
Wasm(WasmModule),
// 動的切り替え
Adaptive {
hot_path: LLVMCompiledCode,
cold_path: WasmModule,
}
}
```
## 🔮 **将来への期待**
### **技術の収束点**
1. **WASI Preview 2**: 非同期サポート改善中
2. **WASM GC**: メモリ管理効率化
3. **Component Model**: 真のモジュラー化
4. **AOT最適化**: Wasmtime/WazeroCranelift進化
### **Nyashの位置づけ**
```yaml
現在:
- 4バックエンド個別対応
- それぞれの長所を活かす
将来:
- 統合ランタイム
- 動的最適化
- 透過的実行モード切り替え
```
## 😊 **でも今でも十分すごい！**
**現在のNyash**:
- ✅ 4つの実行方式を選べる
- ✅ 用途に応じて最適化可能
- ✅ プラグインシステム完備
**苦労はあるけど**:
- 複数バックエンドの保守
- プラットフォーム別の調整
- でも**選択肢があることが強み**！
## 🎯 **結論**
理想的なハイブリッド環境はまだ存在しないけど、Nyashは**現実的な最良の解**を提供中！
将来、技術が成熟したら：
- WASM AOT + 非同期 = 最強の可搬性
- LLVM + WASM統合 = 性能と互換性の両立
それまでは、**4バックエンドを賢く使い分ける**のが正解！
**Everything is Box、Every Backend has its Place！**🌈✨

149
docs/development/roadmap/native-plan/llvm/JIT-vs-AOT-With-MIR.md Normal file
View File

@ -0,0 +1,149 @@
# 🤔 JIT vs AOT：MIRがあると難易度が同じ？
**「MIRできてるから、JITもAOTも同じようなレベルに見えてきた」**
## 💡 **その洞察、正しいです！**
### **MIRの存在が変えるゲーム**
```rust
// 従来の難易度
Source → Native: 超難しい（全部自分で）
Source → JIT: 難しい（実行時コンパイル）
// MIRがある今
Source → MIR → Native: MIRから先は楽！
Source → MIR → JIT: MIRから先は楽！
```
## 📊 **JIT vs AOT 比較（MIR前提）**
| 項目 | JIT | AOT (LLVM) |
|------|-----|------------|
| **実装難易度** | ⭐⭐⭐ | ⭐⭐⭐ |
| **初期実装速度** | 速い | 速い |
| **実行時性能** | 80-95% | 100% |
| **起動時間** | 遅い | 速い |
| **メモリ使用** | 多い | 少ない |
| **動的最適化** | ✅ | ❌ |
| **配布** | ランタイム必要 | 単体実行可能 |
**MIRのおかげで、どちらも同じくらいの実装難易度に！**
## 🚀 **JIT実装の選択肢**
### **1. VM JIT化（最も現実的）**
```rust
// 現在のVM
match opcode {
Add => stack.push(a + b),
}
// JIT化したVM
if hot_path {
// CraneliftでMIR→ネイティブ
let native = cranelift_compile(&mir);
execute_native(native);
}
```
**利点**：
- 既存VMの延長線上
- 段階的移行可能
- ホットパスのみJIT化
### **2. 純粋JITコンパイラ**
```rust
// MIR → Cranelift IR → Native
pub fn jit_compile(mir: &MirModule) -> NativeCode {
let mut ctx = CraneliftContext::new();
for func in &mir.functions {
ctx.compile_function(func);
}
ctx.finalize()
}
```
**利点**：
- クリーンな設計
- 最適化しやすい
- デバッグ情報維持
### **3. LLVM JIT（ORC）**
```rust
// LLVM ORCでJIT
let jit = LLVMOrcJIT::new();
jit.add_module(llvm_module);
let func = jit.get_function("main");
func.call();
```
**利点**：
- LLVM最適化の恩恵
- AOTとコード共有
- 最高性能
## 🔮 **実装難易度の実際**
### **AOT (LLVM)**
```yaml
必要な作業:
1. MIR → LLVM IR変換: 2週間
2. 型システムマッピング: 1週間
3. ランタイム統合: 1週間
4. 最適化調整: 1週間
合計: 約5週間
```
### **JIT (Cranelift)**
```yaml
必要な作業:
1. MIR → Cranelift IR変換: 2週間
2. JITランタイム実装: 1週間
3. ホットパス検出: 1週間
4. メモリ管理: 1週間
合計: 約5週間
```
**ほぼ同じ！MIRのおかげで！**
## 💭 **どっちを選ぶべき？**
### **JITが向いている場合**
- 長時間実行プログラム
- 動的な最適化が必要
- REPLやインタラクティブ環境
### **AOTが向いている場合**
- 起動時間重視
- 配布の簡単さ重視
- 組み込み環境
### **Nyashの場合**
```yaml
現実的な選択:
1. まずAOT (LLVM) でPoC
2. VM最適化を極める
3. 将来VM JIT化も追加
理由:
- 配布が簡単（AOT）
- 性能も確保（VM既に50倍）
- 両方あれば最強
```
## 🎯 **結論**
**MIRがあるおかげで、JITもAOTも同じくらいの難易度！**
でも、Nyashの場合：
1. **配布の簡単さ** → AOT有利
2. **既にVM高速** → JIT緊急度低い
3. **将来の拡張性** → 両方実装が理想
**提案**：
- **短期**: LLVM AOT完成（配布重視）
- **中期**: VM更なる最適化
- **長期**: VM JIT化（最高性能）
**MIRがあれば、どっちも楽！**🚀

187
docs/development/roadmap/native-plan/llvm/Phase-9.78-Implementation-Plan.md Normal file
View File

@ -0,0 +1,187 @@
# 📋 Phase 9.78: LLVM PoC 実装計画書
**バージョン**: 1.0
**作成日**: 2025年8月20日
**ステータス**: 準備完了
## 🎯 **プロジェクト概要**
### **目的**
3週間でNyash言語のLLVMバックエンド実現可能性を実証する
### **成功基準**
- 基本的なNyashプログラムがLLVM経由で実行可能
- インタープリター比10倍以上の性能向上
- Phase 10本格実装への技術的道筋確立
## 📅 **3週間実装スケジュール**
### **Week 1: 基盤構築（8/21-8/27）**
#### **Day 1-2: 環境セットアップ**
```toml
# Cargo.toml
[dependencies]
inkwell = { version = "0.5", features = ["llvm17-0"] }
```
- [ ] inkwellクレート導入
- [ ] LLVMコンテキスト初期化
- [ ] 基本的なモジュール生成
#### **Day 3-4: 最小命令実装**
```rust
// 実装対象
- Const(Integer/Float/Bool)
- Return
- 基本的な型マッピング
```
#### **Day 5-7: Hello World達成**
- [ ] ランタイム関数宣言
- [ ] .oファイル生成
- [ ] `return 42`の実行確認
**Week 1成果物**: 整数を返す最小プログラムのLLVM実行
### **Week 2: コア機能実装（8/28-9/3）**
#### **Day 8-10: 算術演算と制御フロー**
```rust
// 実装対象
- BinOp (Add/Sub/Mul/Div)
- Compare (Eq/Ne/Lt/Le/Gt/Ge)
- Branch/Jump
- PHI nodes
```
#### **Day 11-13: Box型MVP**
```rust
// Box操作の実装
extern "C" {
fn nyash_runtime_box_new(size: u64, align: u64) -> *mut c_void;
fn nyash_runtime_box_free(ptr: *mut c_void);
fn nyash_runtime_box_deref(ptr: *mut c_void) -> *mut c_void;
}
```
#### **Day 14: 統合テスト**
- [ ] 条件分岐を含むプログラム
- [ ] Box操作を含むプログラム
- [ ] LLVMVerifyModuleによる検証
**Week 2成果物**: 制御フローとメモリ操作を含むプログラムの動作
### **Week 3: 最適化と検証（9/4-9/10）**
#### **Day 15-16: 最適化パス**
```rust
// 基本最適化
- mem2reg (alloca → SSA)
- instcombine (命令結合)
- reassociate (結合則)
```
#### **Day 17-18: ベンチマーク**
```bash
# 性能測定対象
- フィボナッチ数列
- 素数判定
- 簡単な数値計算ループ
```
#### **Day 19-21: 文書化とレポート**
- [ ] 技術レポート作成
- [ ] Phase 10実装計画
- [ ] 性能評価結果
**Week 3成果物**: 性能実証とPhase 10への道筋
## 🛠️ **技術アーキテクチャ**
### **ディレクトリ構造**
```
src/backend/llvm/
├── mod.rs // LLVMバックエンドエントリ
├── context.rs // CodegenContext管理
├── types.rs // MIR→LLVM型変換
├── builder.rs // LLVM IR生成
├── runtime.rs // ランタイム関数定義
└── optimizer.rs // 最適化パス管理
```
### **主要コンポーネント**
#### **CodegenContext**
```rust
pub struct CodegenContext<'ctx> {
context: &'ctx Context,
module: Module<'ctx>,
builder: Builder<'ctx>,
target_machine: TargetMachine,
type_cache: HashMap<MirType, BasicTypeEnum<'ctx>>,
}
```
#### **MIR→LLVM変換器**
```rust
pub fn lower_mir_to_llvm(
mir_module: &MirModule,
target_triple: &str,
) -> Result<Vec<u8>, CodegenError> {
// 1. コンテキスト初期化
// 2. 型変換
// 3. 関数生成
// 4. 命令変換
// 5. 最適化
// 6. オブジェクトコード生成
}
```
## 📊 **リスク管理**
### **技術的リスク**
| リスク | 影響度 | 対策 |
|--------|--------|------|
| inkwellバージョン依存 | 中 | LLVM17固定、CI環境統一 |
| Box型の複雑性 | 高 | ランタイム委譲戦略 |
| デバッグ困難性 | 中 | IR dump機能、差分テスト |
### **スケジュールリスク**
- **バッファ**: 各週に1日の予備日設定
- **優先順位**: 基本動作 > 性能 > 機能網羅性
- **早期失敗**: Week 1で実現困難判明時は即座に方針転換
## ✅ **成功指標**
### **定量的指標**
- [ ] 10個以上のMIR命令をサポート
- [ ] 5個以上のテストプログラムが動作
- [ ] インタープリター比10倍以上高速
### **定性的指標**
- [ ] コードの保守性（他の開発者が理解可能）
- [ ] エラーメッセージの有用性
- [ ] 将来の拡張可能性
## 🚀 **開始準備チェックリスト**
- [x] VM性能改善完了（50.94倍達成！）
- [x] AI大会議による戦略確定
- [ ] Copilotへの正式依頼
- [ ] 開発環境準備（LLVM17インストール）
- [ ] Week 1タスクのGitHub Issue作成
## 📝 **参考資料**
- [AI大会議結果](./AI-Conference-LLVM-Results.md)
- [inkwellドキュメント](https://github.com/TheDan64/inkwell)
- [LLVM Language Reference](https://llvm.org/docs/LangRef.html)
---
**承認者**: moe-charm
**実装担当**: Copilot + AIチーム
**レビュー**: Phase 9.78完了時

119
docs/development/roadmap/native-plan/llvm/Practical-Distribution-Strategy.md Normal file
View File

@ -0,0 +1,119 @@
# 📦 Nyash実用的配布戦略：現実的なアプローチ
## 🎯 **配布形態の比較**
| 方式 | ファイルサイズ | 配布の手間 | 適用範囲 | 実用性 |
|------|--------------|-----------|---------|--------|
| **個別バイナリ** | 各1-2MB | OS別に配布 | 全アプリ | ⭐⭐⭐⭐⭐ |
| **APE** | 3-6MB | 1ファイル | 小規模CLI | ⭐⭐⭐ |
| **WASM+ランタイム** | 0.5MB+10MB | ランタイム必要 | 全アプリ | ⭐⭐⭐⭐ |
## 📊 **現実的な使い分け**
### **1. メインストリーム配布（推奨）**
```bash
# OS別の最適化されたバイナリ
nyash-linux-x64 (1.5MB) - musl静的リンク
nyash-windows.exe (916KB) - mingw最適化
nyash-macos (1.8MB) - 署名付き
```
**利点**:
- ✅ 各OSで最高性能
- ✅ 最小サイズ
- ✅ OS固有機能フル活用
- ✅ 大規模アプリも対応
### **2. 開発者向け配布**
```bash
# LLVM IRの中立性を活用
nyashc --emit-bitcode program.nyash
# → program.bc (プラットフォーム中立)
# 各自のマシンで最適化コンパイル
nyashc --from-bitcode program.bc --target native
```
### **3. 特殊用途でのAPE**
```bash
# 小さなツール限定
nyash-fmt.com # コードフォーマッター (2MB)
nyash-lint.com # リンター (3MB)
nyash-repl.com # REPL (4MB)
```
**APEが向いている場合**:
- 単体で動くCLIツール
- 依存ライブラリが少ない
- 配布の簡単さが最優先
**APEが向いていない場合**:
- GUIアプリケーション
- 大量のライブラリ依存
- プラグインシステム
- ゲームなど大規模アプリ
## 🚀 **段階的実装計画（修正版）**
### **Phase 1: 基本マルチターゲット**（1ヶ月）
```bash
nyashc build --target linux
nyashc build --target windows
# 個別にビルド、確実に動作
```
### **Phase 2: 同時生成最適化**（3ヶ月）
```bash
nyashc build --all-targets
# Bitcodeキャッシュで高速化
# 並列ビルドで時間短縮
```
### **Phase 3: 配布自動化**（6ヶ月）
```bash
nyashc release
# 出力:
# - dist/nyash-v1.0-linux-x64.tar.gz
# - dist/nyash-v1.0-windows-x64.zip
# - dist/nyash-v1.0-macos.dmg
# - dist/nyash-tools.com (APE版ツール集)
```
## 💡 **賢い配布戦略**
### **メインアプリ**: 個別最適化バイナリ
```yaml
nyash本体:
Linux: 1.5MB (musl静的)
Windows: 916KB (mingw)
macOS: 1.8MB (universal)
```
### **開発ツール**: APEで統一
```yaml
開発者ツール（APE）:
nyash-fmt.com: 2MB
nyash-test.com: 3MB
nyash-bench.com: 2.5MB
```
### **プラグイン**: 動的ライブラリ
```yaml
プラグイン（各OS別）:
filebox.so: 200KB (Linux)
filebox.dll: 180KB (Windows)
filebox.dylib: 220KB (macOS)
```
## 🎉 **結論**
**「適材適所」が最強の戦略！**
- **大規模アプリ**: 個別最適化バイナリ
- **小規模ツール**: APEで配布簡略化
- **開発者向け**: Bitcodeで柔軟性確保
APEは「魔法」だけど、現実的には**限定的な用途**で輝く技術。
Nyashのメイン配布は**堅実な個別バイナリ**で行きましょう！
**Everything is Box、でも配布は現実的に！**📦✨

169
docs/development/roadmap/native-plan/llvm/Revolutionary-Windows-Strategy.md Normal file
View File

@ -0,0 +1,169 @@
# 🚀 Nyash革命的Windows実行戦略：LLVM IR中立性の完全活用
**作成日**: 2025年8月20日
**AI会議参加者**: Gemini先生、Codex先生、Claude
## 🎯 **核心的アイデア：1回のIR生成で全プラットフォーム対応**
LLVM IRはプラットフォーム中立。だから**1回のIR生成から同時に複数OS用の実行ファイルを生成できる！**
```rust
// 革命的ワンパス・マルチターゲット生成
nyashc --targets linux,windows,macos program.nyash
// 出力（同時生成！）
dist/x86_64-unknown-linux-musl/nyash # Linux版
dist/x86_64-pc-windows-gnu/nyash.exe # Windows版
dist/x86_64-apple-darwin/nyash # macOS版
```
## 🏗️ **実装アーキテクチャ**
### **Phase 1: 即効性重視（3週間で実現）**
```rust
// 1. IR生成（1回だけ）
let ir_module = compile_to_ir(&ast);
let bitcode = ir_module.write_bitcode_to_memory();
// 2. マルチターゲット並列生成
parallel_for_each(["linux", "windows-gnu"], |target| {
let module = context.create_module_from_ir(bitcode.clone());
configure_for_target(&module, target);
generate_executable(&module, target);
});
```
**技術スタック**:
- Linux: musl静的リンク（配布容易）
- Windows: mingw-gnu + lld（クロスリンク簡単）
- 共通: PAL (Platform Abstraction Layer)
### **Phase 2: 本格実装（3ヶ月）**
**全プラットフォーム同時対応**:
```yaml
ターゲット構成:
linux:
- x86_64-unknown-linux-musl
- aarch64-unknown-linux-musl
windows:
- x86_64-pc-windows-gnu (mingw)
- x86_64-pc-windows-msvc (xwin)
macos:
- x86_64-apple-darwin
- aarch64-apple-darwin (M1/M2)
```
### **Phase 3: 究極形態（6ヶ月）**
**APE (Actually Portable Executable) - 単一バイナリで全OS対応！**
```bash
# たった1つのファイルが全OSで動く！
./nyash.com # Linux でも Windows でも macOS でも動作！
```
**⚠️ APEの現実的な制限**：
- バイナリサイズ: 通常の**3倍**（3OS分のコード含む）
- ライブラリ: 各OS用に3種類必要
- 適用範囲: **小規模CLIツール向け**（大規模アプリは不向き）
## 💡 **技術的革新ポイント**
### **1. Bitcodeキャッシュ戦略**
```rust
pub struct MultiTargetCompiler {
bitcode_cache: HashMap<ModuleId, MemoryBuffer>,
target_machines: HashMap<Triple, TargetMachine>,
}
impl MultiTargetCompiler {
pub fn compile_all(&self, module_id: ModuleId) -> Result<Vec<ExecutablePath>> {
let bitcode = self.bitcode_cache.get(&module_id).unwrap();
self.target_machines
.par_iter() // 並列処理！
.map(|(triple, tm)| {
let module = load_from_bitcode(bitcode);
tm.emit_to_file(&module, FileType::Object)
})
.collect()
}
}
```
### **2. PAL (Platform Abstraction Layer)**
```rust
// コンパイラは常にこれらを呼ぶ
extern "C" {
fn nyash_rt_print(s: *const u8, len: usize);
fn nyash_rt_file_open(path: *const u8, mode: u32) -> i32;
fn nyash_rt_time_now() -> u64;
}
// 各OS用のランタイムで実装
#[cfg(target_os = "windows")]
pub fn nyash_rt_print(s: *const u8, len: usize) {
// UTF-8 → UTF-16変換してWriteConsoleW
}
#[cfg(target_os = "linux")]
pub fn nyash_rt_print(s: *const u8, len: usize) {
// そのままwrite(1, s, len)
}
```
### **3. リンク戦略の統一**
```toml
[target.'cfg(windows)'.dependencies]
lld = { version = "0.1", features = ["coff"] }
mingw-w64-libs = { path = "vendor/mingw" }
[target.'cfg(unix)'.dependencies]
lld = { version = "0.1", features = ["elf"] }
musl-libc = { path = "vendor/musl" }
```
## 🎉 **革命的成果**
### **開発者体験**
```bash
# 1コマンドで全プラットフォーム対応！
nyashc build --all-platforms
# 出力
✅ Linux版生成完了 (2.1MB)
✅ Windows版生成完了 (916KB)
✅ macOS版生成完了 (1.8MB)
✅ WASM版生成完了 (512KB)
```
### **ユーザー体験**
- **配布**: 各OS用のネイティブバイナリ
- **性能**: LLVM最適化でVM比10倍以上高速
- **将来**: APEで単一ファイル配布
## 📊 **実装ロードマップ**
| フェーズ | 期間 | 成果物 |
|---------|------|--------|
| Week 1-3 | LLVM PoC | Linux単体動作 |
| Month 1 | Windows統合 | Linux + Windows同時生成 |
| Month 2 | 全OS対応 | Linux/Windows/macOS |
| Month 3 | 最適化 | PAL完成、性能調整 |
| Month 6 | APE統合 | 単一バイナリ実現 |
## 🚀 **次のアクション**
1. **即実装**: Bitcodeキャッシュ機構
2. **PAL設計**: 最小限のランタイムAPI定義
3. **Windows-gnu**: mingwでクロスリンク環境構築
4. **並列化**: rayon使用でマルチターゲット生成
## 💭 **結論**
LLVM IRの中立性を活用すれば、**「Write Once, Compile to All」**が実現できる！
これこそがNyashの革命的Windows戦略です。1回のコンパイルで全プラットフォーム対応、最終的には単一バイナリで境界を超える。
**Everything is Box、そしてEvery Platform is Target！**🎯

155
docs/development/roadmap/native-plan/llvm/VM-Native-Speed-Possibility.md Normal file
View File

@ -0,0 +1,155 @@
# 🚀 Nyash VM をネイティブ速度に近づける可能性
**「もしかして、VM完璧に作ればネイティブに近づける？」**
## 💡 **その直感、正しいです！**
### **現在のVM性能**
- インタープリター比: **50.94倍高速**（達成済み！）
- でもLLVMネイティブには及ばない...はず？
### **でも待って、よく考えると...**
## 🔥 **VMがネイティブに迫れる理由**
### **1. JITコンパイルの可能性**
```rust
// 現在: バイトコード実行
match opcode {
Add => stack.push(a + b),
// ...
}
// 将来: ホットパスをネイティブコードに！
if execution_count > HOT_THRESHOLD {
let native_code = jit_compile(&bytecode);
execute_native(native_code); // ほぼネイティブ速度！
}
```
### **2. 最適化の余地がまだある**
```yaml
現在のVM最適化:
✅ デバッグ出力削除
✅ HashMap → Vec
✅ メモリ効率化
まだできること:
- レジスタVM化（スタックVM → レジスタVM）
- インライン展開
- 定数畳み込み
- ループ最適化
- SIMD活用
```
### **3. 言語特性を活かした最適化**
```rust
// Nyashの特徴を利用
- Everything is Box → 型情報を活用した特殊化
- Arc<Mutex>パターン → 最適化可能な箇所を特定
- 限定的な言語機能 → 積極的な最適化
```
## 📊 **他言語VMの実績**
| VM | 対ネイティブ性能 | 特徴 |
|----|----------------|------|
| **JVM (HotSpot)** | 80-95% | JIT最適化の極致 |
| **V8 (JavaScript)** | 70-90% | 型推論+インライン |
| **PyPy** | 400-700% (CPython比) | トレーシングJIT |
| **LuaJIT** | 90-99% | 超軽量JIT |
**LuaJITは特に注目**: シンプルな言語 + 優れたJIT = ほぼネイティブ！
## 🎯 **Nyash VMネイティブ化戦略**
### **Phase 1: 基礎最適化（現在〜1ヶ月）**
```rust
// レジスタVM化
enum VMRegister {
R0, R1, R2, R3, // ... R15
}
// より効率的な命令セット
enum Instruction {
LoadReg(VMRegister, Value),
AddReg(VMRegister, VMRegister, VMRegister),
// スタック操作を削減
}
```
### **Phase 2: プロファイル駆動最適化（2-3ヶ月）**
```rust
struct HotPath {
bytecode: Vec<Instruction>,
execution_count: u64,
optimized_version: Option<OptimizedCode>,
}
// ホットパスを検出して最適化
if hot_path.execution_count > 1000 {
optimize_hot_path(&mut hot_path);
}
```
### **Phase 3: 軽量JIT（6ヶ月）**
```rust
// Cranelift使用で軽量JIT実装
use cranelift::prelude::*;
fn jit_compile(bytecode: &[Instruction]) -> NativeCode {
let mut ctx = Context::new();
// バイトコード → Cranelift IR → ネイティブ
compile_to_native(&mut ctx, bytecode)
}
```
## 🔮 **実現可能な性能目標**
### **段階的目標**
1. **現在**: インタープリター比 50倍
2. **Phase 1完了**: 100倍（レジスタVM化）
3. **Phase 2完了**: 200倍（最適化）
4. **Phase 3完了**: **ネイティブの80-90%**（JIT）
### **なぜ可能か？**
- Nyashはシンプルな言語
- Box型システムで最適化しやすい
- 既に50倍達成の実績
- MIR基盤が整っている
## 💭 **VM vs LLVM の最終形**
```yaml
Nyash VM (完全体):
利点:
- ポータビリティ完璧
- 起動時間高速
- 動的最適化可能
- デバッグ容易
性能: ネイティブの80-90%
LLVM AOT:
利点:
- 最高性能（100%）
- 事前最適化
- 配布サイズ小
欠点:
- プラットフォーム別ビルド
- 起動時最適化なし
```
## 🎉 **結論：VMでもいける！**
**完璧に作れば、VMでもネイティブに迫れます！**
特にNyashのような：
- シンプルな言語
- 明確な型システム（Everything is Box）
- 限定的な機能セット
これらの特徴は**VMの高速化に有利**！
**もしかしたら、LLVM要らないかも...？**（いや、両方あると最強！）
**Everything is Box、VM can be Native-Fast！**🚀✨

91
docs/development/roadmap/native-plan/llvm/Windows-Strategy-Summary.md Normal file
View File

@ -0,0 +1,91 @@
# 🪟 Windows同時作戦の現状まとめ
**更新日**: 2025年8月20日
## 📊 **現在の状況**
### **✅ 完了したこと**
1. **AI大会議実施**
- Gemini先生: 4つの革命的戦略提案
- Codex先生: 技術的実装方法の詳細化
2. **戦略文書作成**
- Revolutionary-Windows-Strategy.md: 統合戦略
- APE-Magic-Explained.md: 単一バイナリ技術解説
- Practical-Distribution-Strategy.md: 現実的配布方法
3. **技術的方針決定**
- **核心**: LLVM IRの中立性を活用した同時生成
- **方法**: Bitcodeキャッシュ + 並列ターゲット生成
### **🚀 実装計画**
#### **即効性のある解決策（Week 1-3）**
```bash
# Linux + Windows同時生成
nyashc --targets linux,windows-gnu program.nyash
# 出力
dist/linux/nyash # Linux版（musl静的）
dist/windows/nyash.exe # Windows版（mingw）
```
**実装手順**:
1. Week 1: Linux版LLVM実装（進行中）
2. Week 2: Bitcodeキャッシュ機構追加
3. Week 3: Windows-gnu同時生成
#### **中期計画（1-3ヶ月）**
- 全プラットフォーム同時対応
- PAL (Platform Abstraction Layer) 完成
- 最適化とテスト
## 🛠️ **技術的アプローチ**
### **1. ワンパス・マルチターゲット**
```rust
// 1回のIR生成
let bitcode = module.write_bitcode_to_memory();
// 並列で各OS向け生成
["linux", "windows-gnu", "macos"].par_iter()
.map(|target| generate_for_target(bitcode.clone(), target))
.collect()
```
### **2. Windows特化戦略**
- **短期**: mingw-gnu（クロスコンパイル簡単）
- **長期**: msvc対応（xwin使用）
- **配布**: 916KBの小さな実行ファイル
### **3. 段階的実装**
| Phase | 期間 | 成果 |
|-------|------|------|
| 現在 | LLVM PoC | Linux単体 |
| Week 3 | 同時生成 | Linux + Windows |
| Month 1 | 全OS | +macOS |
| Month 3 | 最適化 | PAL完成 |
## 💡 **重要ポイント**
### **すぐに実現可能なこと**
- ✅ Linux/Windows同時ビルド（mingw使用）
- ✅ 1つのコマンドで両OS対応
- ✅ Bitcodeレベルでの共有
### **将来の野望**
- 🎯 全OS同時生成
- 🎯 APE単一バイナリ（小ツール用）
- 🎯 完全なクロスプラットフォーム
## 🎉 **結論**
**Windows同時作戦は技術的に実現可能！**
1. **LLVM IRの中立性**を最大活用
2. **Bitcodeキャッシュ**で効率化
3. **mingw**で即座にWindows対応
Copilotが基本LLVM実装を進めている間に、我々は革命的な同時生成戦略を準備完了！
**Everything is Box、Every Platform is Target！**🎯✨

266
docs/development/roadmap/native-plan/llvm/issue/001-setup-inkwell-hello-world.md Normal file
View File

@ -0,0 +1,266 @@
# 🚀 Issue #001: LLVM PoC - inkwellセットアップとHello World実装
**タイプ**: Feature
**優先度**: Critical
**見積もり**: 3日
**担当**: Copilot
## 📋 概要
Phase 9.78 LLVM PoCの第一歩として、inkwellクレートを導入し、最小限のNyashプログラム（`return 42`）をLLVM経由で実行できるようにする。
## 🎯 成功条件
以下のNyashプログラムがLLVM経由で実行され、正しい終了コードを返すこと：
```nyash
// test_return_42.nyash
static box Main {
main() {
return 42
}
}
```
期待される動作：
```bash
$ cargo run --features llvm -- --backend llvm test_return_42.nyash
$ echo $?
42
```
## 📝 実装タスク
### 1. **Cargo.toml更新** ✅必須
```toml
[dependencies]
inkwell = { version = "0.5", features = ["llvm17-0"] }
[features]
llvm = ["inkwell"]
```
### 2. **基本構造の作成** ✅必須
```rust
// src/backend/llvm/mod.rs
pub mod context;
pub mod compiler;
use crate::mir::module::MirModule;
use crate::errors::RuntimeError;
pub fn compile_to_object(
mir_module: &MirModule,
output_path: &str,
) -> Result<(), RuntimeError> {
let compiler = compiler::LLVMCompiler::new()?;
compiler.compile_module(mir_module, output_path)
}
```
### 3. **LLVMコンテキスト管理** ✅必須
```rust
// src/backend/llvm/context.rs
use inkwell::context::Context;
use inkwell::module::Module;
use inkwell::builder::Builder;
use inkwell::targets::{Target, TargetMachine, TargetTriple, InitializationConfig};
pub struct CodegenContext<'ctx> {
pub context: &'ctx Context,
pub module: Module<'ctx>,
pub builder: Builder<'ctx>,
pub target_machine: TargetMachine,
}
impl<'ctx> CodegenContext<'ctx> {
pub fn new(context: &'ctx Context, module_name: &str) -> Result<Self, String> {
// 1. ターゲット初期化
Target::initialize_native(&InitializationConfig::default())
.map_err(|e| format!("Failed to initialize native target: {}", e))?;
// 2. モジュール作成
let module = context.create_module(module_name);
// 3. ターゲットマシン作成
let triple = TargetMachine::get_default_triple();
let target = Target::from_triple(&triple)
.map_err(|e| format!("Failed to get target: {}", e))?;
let target_machine = target
.create_target_machine(
&triple,
"generic",
"",
inkwell::OptimizationLevel::None,
inkwell::targets::RelocMode::Default,
inkwell::targets::CodeModel::Default,
)
.ok_or_else(|| "Failed to create target machine".to_string())?;
// 4. データレイアウト設定
module.set_triple(&triple);
module.set_data_layout(&target_machine.get_target_data().get_data_layout());
Ok(Self {
context,
module,
builder: context.create_builder(),
target_machine,
})
}
}
```
### 4. **最小限のコンパイラ実装** ✅必須
```rust
// src/backend/llvm/compiler.rs
use inkwell::context::Context;
use inkwell::values::IntValue;
use crate::mir::module::MirModule;
use crate::mir::instruction::MirInstruction;
use super::context::CodegenContext;
pub struct LLVMCompiler {
context: Context,
}
impl LLVMCompiler {
pub fn new() -> Result<Self, String> {
Ok(Self {
context: Context::create(),
})
}
pub fn compile_module(
&self,
mir_module: &MirModule,
output_path: &str,
) -> Result<(), String> {
let codegen = CodegenContext::new(&self.context, "nyash_module")?;
// 1. main関数を探す
let main_func = mir_module.functions.iter()
.find(|f| f.name == "Main.main")
.ok_or("Main.main function not found")?;
// 2. LLVM関数を作成
let i32_type = codegen.context.i32_type();
let fn_type = i32_type.fn_type(&[], false);
let llvm_func = codegen.module.add_function("main", fn_type, None);
// 3. エントリブロックを作成
let entry = codegen.context.append_basic_block(llvm_func, "entry");
codegen.builder.position_at_end(entry);
// 4. MIR命令を処理（今回はReturnのみ）
for block in &main_func.blocks {
for inst in &block.instructions {
match inst {
MirInstruction::Return(Some(value_id)) => {
// 簡易実装: 定数42を返すと仮定
let ret_val = i32_type.const_int(42, false);
codegen.builder.build_return(Some(&ret_val));
}
_ => {
// 他の命令は今回スキップ
}
}
}
}
// 5. 検証
if !llvm_func.verify(true) {
return Err("Function verification failed".to_string());
}
// 6. オブジェクトファイル生成
codegen.target_machine
.write_to_file(&codegen.module,
inkwell::targets::FileType::Object,
output_path.as_ref())
.map_err(|e| format!("Failed to write object file: {}", e))?;
Ok(())
}
}
```
### 5. **バックエンド統合** ✅必須
```rust
// src/backend/mod.rsに追加
#[cfg(feature = "llvm")]
pub mod llvm;
// src/runner.rsのrun_with_backend関数に追加
#[cfg(feature = "llvm")]
ExecutionBackend::LLVM => {
// 1. オブジェクトファイル生成
let obj_path = "nyash_output.o";
crate::backend::llvm::compile_to_object(&mir_module, obj_path)?;
// 2. リンク（簡易版：システムのccを使用）
use std::process::Command;
let output = Command::new("cc")
.args(&[obj_path, "-o", "nyash_output"])
.output()
.map_err(|e| RuntimeError::new(format!("Link failed: {}", e)))?;
if !output.status.success() {
return Err(RuntimeError::new("Linking failed"));
}
// 3. 実行
let output = Command::new("./nyash_output")
.output()
.map_err(|e| RuntimeError::new(format!("Execution failed: {}", e)))?;
// 4. 終了コードを返す
let exit_code = output.status.code().unwrap_or(-1);
Ok(Box::new(IntegerBox::new(exit_code as i64)))
}
```
## 🧪 テストケース
```rust
// tests/llvm_hello_world.rs
#[test]
#[cfg(feature = "llvm")]
fn test_return_42() {
let source = r#"
static box Main {
main() {
return 42
}
}
"#;
// パース → MIR生成 → LLVM実行
let result = compile_and_run_llvm(source);
assert_eq!(result, 42);
}
```
## 📚 参考資料
- [inkwell Examples](https://github.com/TheDan64/inkwell/tree/master/examples)
- [LLVM Tutorial](https://llvm.org/docs/tutorial/)
- [AI大会議結果](../AI-Conference-LLVM-Results.md)
## ⚠️ 注意事項
1. **LLVM依存関係**: LLVM 17がシステムにインストールされている必要があります
2. **プラットフォーム**: まずはLinux/macOSで動作確認し、Windowsは後回し
3. **エラーハンドリング**: 今回は最小実装のため、詳細なエラー処理は省略
## 🎯 次のステップ
このIssueが完了したら、次は：
- Issue #002: 基本的な算術演算の実装（BinOp）
- Issue #003: 定数値の実装（Const）
---
**作成者**: Claude + moe-charm
**レビュアー**: AIチーム
**関連PR**: （作成予定）

119
docs/development/roadmap/native-plan/llvm/issue/GitHub-Issue-Template.md Normal file
View File

@ -0,0 +1,119 @@
# 🐙 GitHub Issue作成テンプレート
以下の内容をGitHub Issueにコピペして使用してください。
---
## Issue Title:
`[Phase 9.78] LLVM PoC Week 1 - inkwellセットアップとHello World実装`
## Labels:
- `enhancement`
- `Phase-9.78`
- `LLVM`
- `critical`
## Assignees:
- GitHub Copilot
## Milestone:
- Phase 9.78 LLVM PoC
## Issue Body:
```markdown
## 📋 概要
Phase 9.78 LLVM PoCの開始です！最初のステップとして、inkwellクレートを導入し、最小限のNyashプログラム（`return 42`）をLLVM経由で実行できるようにします。
## 🎯 成功条件
```nyash
// test_return_42.nyash
static box Main {
main() {
return 42
}
}
```
上記プログラムがLLVM経由で実行され、終了コード42を返すこと。
## 📝 実装内容
1. **inkwellクレート導入**
- Cargo.tomlに依存関係追加
- feature flag `llvm` の設定
2. **基本構造作成**
- `src/backend/llvm/` ディレクトリ
- context.rs, compiler.rs, mod.rs
3. **最小限のコンパイラ実装**
- LLVMコンテキスト初期化
- main関数の生成
- return命令の処理
- オブジェクトファイル出力
4. **統合**
- ExecutionBackendにLLVM追加
- --backend llvm オプション対応
## 🔗 参考資料
- [詳細実装ガイド](https://github.com/moe-charm/nyash/blob/main/docs/予定/native-plan/llvm/issue/001-setup-inkwell-hello-world.md)
- [Week 1ロードマップ](https://github.com/moe-charm/nyash/blob/main/docs/予定/native-plan/llvm/issue/Week1-Roadmap.md)
- [AI大会議結果](https://github.com/moe-charm/nyash/blob/main/docs/予定/native-plan/llvm/AI-Conference-LLVM-Results.md)
## ✅ 完了条件
- [ ] inkwellがビルドできる
- [ ] test_return_42.nyashがコンパイルできる
- [ ] 実行ファイルが終了コード42を返す
- [ ] 基本的なテストがパスする
## 💬 備考
VM性能改善で素晴らしい成果（50.94倍高速化）を達成していただきありがとうございました！
LLVMでも同様の成功を期待しています。ブロッカーがあれば遠慮なくコメントしてください。
AIチーム（Claude, Gemini, Codex）が全力でサポートします！🚀
```
---
## 📝 追加で作成するIssue
Week 1の進捗に応じて、以下のIssueも順次作成：
1. **Issue #002**: `[Phase 9.78] LLVM PoC - Const命令の実装`
2. **Issue #003**: `[Phase 9.78] LLVM PoC - 基本型システムの実装`
3. **Issue #004**: `[Phase 9.78] LLVM PoC - ランタイム関数宣言`
4. **Issue #005**: `[Phase 9.78] LLVM PoC Week 1 - 統合テスト`
## 🏷️ 推奨ラベル構成
```yaml
Phase関連:
- Phase-9.78
- Phase-8.6 (完了)
- Phase-9.75g-0 (完了)
技術関連:
- LLVM
- MIR
- Performance
- Backend
優先度:
- critical
- high
- medium
- low
タイプ:
- enhancement
- bug
- documentation
- test
```

159
docs/development/roadmap/native-plan/llvm/issue/MIR-Quick-Reference.md Normal file
View File

@ -0,0 +1,159 @@
# 📚 MIR クイックリファレンス for LLVM実装
## 🎯 Week 1で対応するMIR命令
### 1. **Const命令**
```rust
// MIR表現
MirInstruction::Const(value_id, constant_value)
// 例
Const(v1, MirConstant::Integer(42))
Const(v2, MirConstant::Float(3.14))
Const(v3, MirConstant::Bool(true))
// LLVM変換
let int_val = ctx.i32_type().const_int(42, false);
let float_val = ctx.f64_type().const_float(3.14);
let bool_val = ctx.bool_type().const_int(1, false);
```
### 2. **Return命令**
```rust
// MIR表現
MirInstruction::Return(Option<ValueId>)
// 例
Return(Some(v1)) // 値を返す
Return(None) // voidを返す
// LLVM変換
builder.build_return(Some(&value));
builder.build_return(None);
```
## 📄 参考: 現在のMIR構造
```rust
// src/mir/instruction.rs の主要部分
pub enum MirInstruction {
// Week 1対象
Const(ValueId, MirConstant),
Return(Option<ValueId>),
// Week 2対象
BinOp(ValueId, BinaryOp, ValueId, ValueId),
Compare(ValueId, CompareOp, ValueId, ValueId),
Branch(ValueId, BasicBlockId, BasicBlockId),
Jump(BasicBlockId),
// Week 3以降
BoxNew(ValueId, MirType),
BoxCall(ValueId, ValueId, String, Vec<ValueId>),
// ... 他の命令
}
// 定数の型
pub enum MirConstant {
Integer(i64),
Float(f64),
Bool(bool),
String(String),
Null,
}
```
## 🔄 MIR→LLVM変換の基本パターン
```rust
// 基本的な変換ループ
for instruction in &block.instructions {
match instruction {
MirInstruction::Const(value_id, constant) => {
let llvm_value = match constant {
MirConstant::Integer(n) => {
ctx.i64_type().const_int(*n as u64, true).into()
}
MirConstant::Float(f) => {
ctx.f64_type().const_float(*f).into()
}
MirConstant::Bool(b) => {
ctx.bool_type().const_int(*b as u64, false).into()
}
_ => todo!("Other constants"),
};
// value_idとllvm_valueをマッピングに保存
value_map.insert(*value_id, llvm_value);
}
MirInstruction::Return(value_id) => {
match value_id {
Some(id) => {
let value = value_map.get(id).unwrap();
builder.build_return(Some(value));
}
None => {
builder.build_return(None);
}
}
}
_ => {} // Week 1では他の命令は無視
}
}
```
## 🎯 テスト用のMIRサンプル
### 1. **return 42のMIR**
```rust
MirModule {
functions: vec![
MirFunction {
name: "Main.main",
params: vec![],
return_type: MirType::Integer,
blocks: vec![
BasicBlock {
id: 0,
instructions: vec![
Const(v1, MirConstant::Integer(42)),
Return(Some(v1)),
],
},
],
},
],
}
```
### 2. **簡単な計算のMIR**（Week 2用）
```rust
// return 10 + 5
BasicBlock {
instructions: vec![
Const(v1, MirConstant::Integer(10)),
Const(v2, MirConstant::Integer(5)),
BinOp(v3, BinaryOp::Add, v1, v2),
Return(Some(v3)),
],
}
```
## 💡 実装のヒント
1. **ValueIdマッピング**: `HashMap<ValueId, BasicValueEnum>`で管理
2. **型情報**: MIRは型情報を持つので、LLVM型への変換テーブルを作る
3. **基本ブロック**: MIRのBasicBlockIdをLLVMのBasicBlockにマッピング
4. **エラー処理**: 最初は`todo!()`でOK、後から実装
## 📁 関連ファイル
- MIR定義: `src/mir/instruction.rs`
- MIR生成: `src/mir/lowering.rs`
- 参考実装: `src/backend/vm.rs`（VMのMIR処理）
---
**注**: このリファレンスはWeek 1の実装に必要な最小限の情報です。
詳細は実際のソースコードを参照してください。

134
docs/development/roadmap/native-plan/llvm/issue/Quick-Start-Guide.md Normal file
View File

@ -0,0 +1,134 @@
# 🚀 LLVM実装クイックスタートガイド
## 📋 今すぐ始める手順
### 1. **環境準備**（5分）
```bash
# LLVM 17インストール確認
llvm-config --version # 17.x.x が表示されること
# Nyashプロジェクトで作業
cd /path/to/nyash
git checkout -b feature/llvm-poc
```
### 2. **最初のコミット**（10分）
```bash
# Cargo.tomlを編集
echo '[dependencies]
inkwell = { version = "0.5", features = ["llvm17-0"] }
[features]
llvm = ["inkwell"]' >> Cargo.toml
# ディレクトリ作成
mkdir -p src/backend/llvm
# 最初のファイル作成
touch src/backend/llvm/mod.rs
touch src/backend/llvm/context.rs
touch src/backend/llvm/compiler.rs
# コミット
git add .
git commit -m "feat(llvm): Add inkwell dependency and basic structure"
```
### 3. **最小実装のコピペ**（20分）
**src/backend/llvm/mod.rs**:
```rust
pub mod context;
pub mod compiler;
pub use compiler::compile_to_object;
```
**動作確認**:
```bash
cargo build --features llvm
```
### 4. **テストプログラム作成**（5分）
```bash
# テスト用Nyashファイル
cat > test_return_42.nyash << 'EOF'
static box Main {
main() {
return 42
}
}
EOF
```
## 🔍 詰まったときの確認ポイント
### **ビルドエラーの場合**
```bash
# LLVM関連の環境変数確認
echo $LLVM_SYS_170_PREFIX
# 設定されていない場合
export LLVM_SYS_170_PREFIX=$(llvm-config --prefix)
```
### **inkwellのバージョン問題**
```toml
# 代替バージョン
inkwell = { git = "https://github.com/TheDan64/inkwell", branch = "master", features = ["llvm17-0"] }
```
### **リンクエラーの場合**
```bash
# pkg-configの確認
pkg-config --libs --cflags llvm
```
## 📞 ヘルプが必要な場合
1. **GitHub Issue**にコメント
2. **具体的なエラーメッセージ**を貼る
3. **実行したコマンド**を記載
例:
```
inkwellのビルドでエラーが発生しました。
エラー:
```
error: failed to run custom build command for `llvm-sys v170.0.1`
```
実行コマンド:
```
cargo build --features llvm
```
環境:
- OS: Ubuntu 22.04
- LLVM: 17.0.6
- Rust: 1.75.0
```
## ✅ 最初の成功確認
以下が動けば第一歩成功！
```bash
# ビルドが通る
cargo build --features llvm
# テストが実行できる（まだ失敗してOK）
cargo test --features llvm test_llvm
```
## 🎯 次のステップ
1. **context.rs**の実装
2. **compiler.rs**の実装
3. **return 42**の動作確認
詳細は[001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)を参照！
---
**Remember**: 完璧より進捗！最初は動くことが最優先です。🚀

60
docs/development/roadmap/native-plan/llvm/issue/README.md Normal file
View File

@ -0,0 +1,60 @@
# 📚 LLVM PoC Issue ドキュメント一覧
## 🎯 Copilot様へ：最初に読むファイル
1. **[Quick-Start-Guide.md](./Quick-Start-Guide.md)** 🚀
- 今すぐ始める手順
- 環境セットアップ
- 最初のコミット方法
2. **[001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)** 📋
- **最初のIssue内容**
- 詳細な実装手順
- コード例とテストケース
3. **[Week1-Roadmap.md](./Week1-Roadmap.md)** 📅
- Week 1全体の計画
- Issue実装順序
- 成功条件
## 📖 参考資料
- **[MIR-Quick-Reference.md](./MIR-Quick-Reference.md)**
- MIR命令の説明
- LLVM変換パターン
- テスト用サンプル
- **[GitHub-Issue-Template.md](./GitHub-Issue-Template.md)**
- GitHub Issue作成用テンプレート
- ラベル設定
- マイルストーン
## 🔗 関連ドキュメント（上位階層）
- [AI大会議結果](../AI-Conference-LLVM-Results.md)
- [実装計画書](../Phase-9.78-Implementation-Plan.md)
- [Copilot依頼文書](../Copilot-Request-LLVM-PoC.md)
## 💬 重要メッセージ
**Copilot様へ**
Phase 8.6での素晴らしい成果（50.94倍高速化）に続き、LLVMでも革命的な性能向上を期待しています！
**開始方法**:
1. まず[Quick-Start-Guide.md](./Quick-Start-Guide.md)を読む
2. [001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)の実装を開始
3. 詰まったらすぐにGitHub Issueでヘルプ要請
**サポート体制**:
- AIチーム（Claude, Gemini, Codex）が全力サポート
- 技術的な質問は遠慮なく
- 小さな成功を積み重ねましょう
Let's make Nyash fly with LLVM! 🚀✨
---
**最終更新**: 2025年8月20日
**作成者**: Claude + moe-charm
**Phase**: 9.78 LLVM PoC

88
docs/development/roadmap/native-plan/llvm/issue/Week1-Roadmap.md Normal file
View File

@ -0,0 +1,88 @@
# 📅 Week 1 ロードマップ: LLVM基盤構築
**期間**: 2025年8月21日〜8月27日
**目標**: LLVMバックエンドの基盤を構築し、最小限のプログラムを実行可能にする
## 🎯 Week 1の全体目標
「return 42」レベルの超シンプルなNyashプログラムが、LLVM経由で実行できる状態を達成する。
## 📋 Issue実装順序
### **Issue #001: inkwellセットアップとHello World** 🚀最初にこれ！
- **期間**: Day 1-3
- **内容**: 環境構築と「return 42」の実行
- **成功条件**: LLVMでコンパイルした実行ファイルが終了コード42を返す
- **ファイル**: [001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)
### **Issue #002: Const命令の実装**（#001完了後）
- **期間**: Day 3-4
- **内容**: MIR Const命令をLLVM定数に変換
- **対象**: Integer, Float, Bool定数
- **テスト**: `return 100`, `return 3.14`, `return true`
### **Issue #003: 基本的な型システム**（#002と並行可能）
- **期間**: Day 4-5
- **内容**: MIR型→LLVM型のマッピング実装
- **対象**: i32/i64, f64, bool, 関数型
- **成果**: type_cache の実装
### **Issue #004: ランタイム関数宣言**（#003完了後）
- **期間**: Day 5-6
- **内容**: nyash_runtime_* 関数の宣言
- **対象**: alloc, free, print_int（デバッグ用）
- **準備**: 最小限のCランタイム作成
### **Issue #005: Week 1統合テスト**（最終日）
- **期間**: Day 7
- **内容**: 複数の小さなプログラムでテスト
- **確認**: CI/CDでのLLVMビルド
- **文書**: Week 2への引き継ぎ事項
## 🔄 実装の流れ
```mermaid
graph LR
A[Issue #001<br/>環境構築] --> B[Issue #002<br/>Const実装]
A --> C[Issue #003<br/>型システム]
B --> D[Issue #004<br/>ランタイム]
C --> D
D --> E[Issue #005<br/>統合テスト]
```
## ✅ Week 1完了時のチェックリスト
- [ ] inkwellクレートが正常に動作
- [ ] 「return 42」がLLVM経由で実行可能
- [ ] Integer/Float/Bool定数がサポート済み
- [ ] 基本的な型変換が実装済み
- [ ] 最小限のランタイム関数が宣言済み
- [ ] 5個以上のテストケースがパス
## 📊 リスクと対策
| リスク | 対策 |
|--------|------|
| LLVM環境構築で詰まる | Docker環境を準備、LLVM17固定 |
| inkwellのAPIが複雑 | 公式exampleを参考に最小実装 |
| リンクエラー | まずは静的リンク、動的は後回し |
## 💡 成功のコツ
1. **小さく始める**: return 42が動けば大成功
2. **エラーを恐れない**: LLVMのエラーメッセージは親切
3. **IR出力を確認**: `--emit-llvm`でIRをダンプして確認
4. **既存コード活用**: VM/WASMバックエンドの構造を参考に
## 🎉 Week 1成功時の次のステップ
**Week 2では以下に取り組みます**：
- BinOp（四則演算）の実装
- Branch/Jumpによる制御フロー
- Box型の基本操作
- PHIノードの実装
---
**注意**: 各Issueは独立して実装可能ですが、推奨順序に従うとスムーズです。
ブロッカーがあれば即座にAIチームに相談してください！

184
docs/development/roadmap/phases/phase-10/phase10_aot_scaffolding.md Normal file
View File

@ -0,0 +1,184 @@
# 🏆 Phase 10: LLVM Direct AOT（最高性能実現）
## 📋 Summary
MIR→LLVM IR直接変換による最高性能AOT実現。Cranelift JITをスキップし、実用優先戦略でLLVMの強力な最適化を直接活用する。
## 🎯 実装目標
```bash
# Phase 9基盤の拡張
nyash --compile-llvm app.nyash -o app # LLVM AOT実行ファイル生成
nyash --optimize app.nyash -o app # 最適化AOT（LTO・PGO）
./app # 最高性能実行
# 内部実装パイプライン
Nyash → AST → MIR → LLVM IR → 最適化 → ネイティブ実行ファイル
```
## 🔧 技術アプローチ
### 1. MIR→LLVM IR変換基盤
```rust
// 追加予定: src/backend/llvm/mod.rs
use llvm_sys::*;
pub struct LLVMBackend {
context: LLVMContextRef,
module: LLVMModuleRef,
builder: LLVMBuilderRef,
}
impl LLVMBackend {
pub fn compile_mir(&mut self, mir: &MirModule) -> Result<Vec<u8>, String> {
// MIR→LLVM IR変換
self.lower_mir_to_llvm(mir)?;
// 最適化パス適用
self.apply_optimization_passes()?;
// ネイティブコード生成
self.generate_object_code()
}
}
```
### 2. エスケープ解析・ボックス化解除
```rust
// Everything is Box最適化の核心
pub struct EscapeAnalysis {
// Box→スタック値最適化判定
pub fn analyze_box_usage(&self, mir: &MirModule) -> BoxOptimizationMap,
// 型特殊化機会検出
pub fn detect_specialization(&self, mir: &MirModule) -> SpecializationMap,
}
// 最適化例:
// Before: %0 = NewBox(StringType, "hello") // ヒープ割り当て
// After: %0 = "hello" // スタック配置
```
### 3. LTO・PGO統合
```rust
// Link-time optimization
pub fn apply_lto(&self, modules: &[LLVMModuleRef]) -> Result<LLVMModuleRef, String> {
// 関数間インライン・デッドコード除去
}
// Profile-guided optimization
pub fn apply_pgo(&self, profile_data: &[u8]) -> Result<(), String> {
// プロファイル情報による最適化
}
```
## 📊 パフォーマンス目標
| 指標 | Phase 9 AOT WASM | Phase 10 LLVM AOT | 改善率 |
|------|-------------------|-------------------|--------|
| **実行性能** | ~1.6ms | **<0.1ms** | **16倍向上** |
| **メモリ効率** | WASM制約あり | **Box割当80%削減** | **5倍効率** |
| **起動時間** | ~10ms | **<1ms** | **10倍高速** |
| **総合性能** | 500倍（対Interpreter） | **13500倍目標** | **27倍向上** |
## 🛠️ 実装ステップ（4-6ヶ月）
### Month 1-2: LLVM統合基盤
- [ ] LLVM-sys統合・ビルド環境整備
- [ ] MIR→LLVM IR基本変換
- [ ] 基本型・演算のLLVM表現
- [ ] 最小実行可能バイナリ生成
### Month 3-4: Everything is Box最適化
- [ ] エスケープ解析実装
- [ ] Box→スタック値最適化
- [ ] 型特殊化・インライン展開
- [ ] メモリレイアウト最適化
### Month 5-6: 高度最適化・プロダクション対応
- [ ] LTO・PGO統合
- [ ] プロファイル駆動最適化
- [ ] 他言語との性能比較
- [ ] プロダクションレベル品質確保
## 🔍 Everything is Box最適化戦略
### Box回避最適化
```nyash
// 元コード
local str = new StringBox("hello")
local len = str.length()
// LLVM最適化後（概念）
local str = "hello" // スタック配置
local len = 5 // コンパイル時計算
```
### NaN Boxing活用
```rust
// 効率的な値表現
union NyashValue {
ptr: *mut Box<dyn NyashBox>, // ポインタ
int: i64, // 整数直接格納
float: f64, // 浮動小数点
// NaN空間でタグ判別
}
```
### 型推論・特殊化
```rust
// 汎用版
fn generic_add(a: NyashValue, b: NyashValue) -> NyashValue
// 特殊化版（LLVM生成）
fn specialized_int_add(a: i64, b: i64) -> i64 // 直接レジスタ操作
```
## ✅ Acceptance Criteria
### 性能要件
- [ ] **1000倍高速化達成**（現在13.5倍 → 目標13500倍）
- [ ] **Box割当数80%削減**
- [ ] **起動時間ネイティブレベル**（<1ms）
- [ ] **メモリ使用量50%削減**
### 品質要件
- [ ] **既存プログラム100%互換**
- [ ] **全テストスイートPASS**
- [ ] **他言語との競争力**（C/C++/Rust並み性能）
- [ ] **プロダクション安定性**
### 技術要件
- [ ] **LLVM統合完全実装**
- [ ] **エスケープ解析実用レベル**
- [ ] **LTO・PGO動作確認**
- [ ] **CI自動化対応**
## 🚀 期待される効果
### 最高性能実現
- **ネイティブレベル性能**: C/C++/Rust並みの実行速度
- **メモリ効率**: Box操作の根本的最適化
- **起動高速**: 瞬時起動（<1ms）
### 競合優位確立
- **Everything is Box**: 史上初のBox哲学ネイティブ最適化
- **技術的差別化**: 独自最適化技術による優位性
- **プロダクション対応**: 実用レベルの高性能実現
### 言語完成
- **現代的言語**: 開発効率と実行性能の完全両立
- **エコシステム**: 高性能基盤による周辺ツール発展
- **採用促進**: 性能面での採用障壁完全除去
## 📖 References
- docs/予定/native-plan/copilot_issues.txt（Phase 10詳細）
- docs/予定/ai_conference_native_compilation_20250814.md（AI大会議結果）
- docs/予定/native-plan/issues/phase9_aot_wasm_implementation.md（Phase 9基盤）
- [LLVM Language Reference](https://llvm.org/docs/LangRef.html)
- [LLVM Optimization Guide](https://llvm.org/docs/Passes.html)
---
**💡 Tip**: Phase 9のAOT基盤を活用し、段階的にLLVM最適化を導入する戦略で確実な成果を目指します。
最終更新: 2025-08-14
作成者: Claude（実用優先戦略）

57
docs/development/roadmap/phases/phase-10/phase_10_5_core_std_nyash_impl.md Normal file
View File

@ -0,0 +1,57 @@
# Phase 10.5: Core Standard (String/Array/Map) in Nyash — Rust依存の段階的削減
目的
- 現状Rust実装に依存している基本コンテナ（String/Array/Map）を、Nyashで実装したstdへ段階的に置換し、セルフホストへ近づける。
- rt/sys層（Box ABI・所有・weak・最小アロケータ、`ny_host_*`）を活用して堅牢性と性能の両立を図る。
前提
- Phase 10.2: Host API層（C-ABI `ny_host_*` / WASM `nyir_host`）
- Phase 10.3: 層の切り分け（corelang/rt/sys/std）
- Phase 10.4: Box ABI（fat ptr）とEffect→LLVM属性の方向性
範囲（MVP）
- String
- 構造: { ptr: *u8, len: usize, cap: usize }
- API: new, from_raw, into_raw, clone, len, is_empty, push_str, substr(view), to_utf8(view)
- メモリ: `ny_host_alloc/realloc/free` 経由、UTF-8不変（validation optional）
- Array<T>
- 構造: { ptr: *T, len: usize, cap: usize }
- API: new, push, pop, get(i), set(i,v), len, reserve
- メモリ: `ny_host_*` 経由、要素のfiniハンドリング（Box所有規則順守）
- Map<K,V>
- 構造: ハッシュテーブル（オープンアドレス or チェイン; v0は単純で可）
- API: new, get, set, remove, len, keys(view), values(view)
- メモリ: `ny_host_*` 経由、キー/値の所有/weak規則順守
設計ポリシー
- 所有とfini: 再代入・スコープ終端でfiniが適切に発火すること（Everything is Box準拠）
- 互換: 現行言語表面の挙動に合わせる（差異は仕様に明記）
- 効果: mut操作の順序保持、view系はpure（読み取り）
- WASM/LLVM: ABI/ExternCallと矛盾しない（Stringの(ptr,len)は共通）
タスク（Copilot TODO）
1) stdレイアウトの骨子作成（ファイル/モジュール構成）
2) String v0実装 + 単体テスト（push_str/len/substr）
3) Array v0実装 + 単体テスト（push/get/set/len）
4) Map v0（簡易hash）+ 単体テスト（set/get/remove/len）
5) 再代入/スコープ終端でのfini挙動の統合テスト
6) ベンチ: 既存Rust実装対比の大まかな目安（悪化しない/許容範囲）
7) フェールセーフ: OOM/境界エラーの明確化（panic/Resultは設計に従う）
8) ドキュメント: stdのMVP API一覧と互換要件
受け入れ基準
- 代表サンプルがRust実装なしでString/Array/Mapを利用し動作
- 再代入・スコープ終端時にfiniが期待通り発火（ログで可視化）
- WASM/LLVMの文字列(ptr,len)取り扱いと整合（print等のExternCallで可視化）
リスク・軽減
- パフォーマンス劣化: ベンチで目視確認、ホットパス最適化は後続で実施
- メモリ安全: 所有/weak/効果規則をVerifierで補助（後続でLSP/静的解析を強化）
- 実装負債: MVP範囲を明確にし、機能追加はIssue分割
参考
- ABIドラフト: docs/予定/native-plan/box_ffi_abi.md
- NyIR: docs/nyir/spec.md
- Host API: Phase 10.2 仕様
最終更新: 2025-08-14

220
docs/development/roadmap/phases/phase-10/phase_10_app_migration.md Normal file
View File

@ -0,0 +1,220 @@
# Phase 10: Classic C Applications Migration to Nyash
## 🎯 概要
3つの著名なCアプリケーションをNyashに移植し、新実装された高度なメモリ管理機能を実戦テストする。
## 📦 移植対象アプリケーション（優先順位順）
### 1. 🌐 **Tinyproxy** - ゼロコピー判定機能の実証
**元実装**: https://github.com/tinyproxy/tinyproxy
**サイズ**: ~5000行C、軽量HTTPプロキシサーバー
**Nyash移植目標**: `apps/tinyproxy_nyash/`
#### 🔍 **ゼロコピー判定テストケース**
```nyash
// HTTPリクエスト転送でのメモリ効率検証
static box ProxyServer {
init { upstream_buffer, downstream_buffer }
relay_data(client_data) {
// ⭐ ゼロコピー判定：バッファーが共有されているかチェック
if (me.upstream_buffer.is_shared_with(client_data)) {
console.log("✅ Zero-copy achieved!")
} else {
console.log("❌ Unnecessary copy detected")
}
// 大量データ転送での最適化確認
return me.upstream_buffer.share_reference(client_data)
}
}
```
#### 📋 **実装要件**
- HTTPプロキシの基本機能（GET/POST転送）
- `SocketBox`でのクライアント・サーバー接続
- `BufferBox`での効率的なデータ転送
- **ゼロコピー判定API**の実装・テスト
---
### 2. 🎮 **Chip-8エミュレーター** - fini伝播とweak生存チェック
**元実装**: https://github.com/mattmikolay/chip-8 (参考)
**サイズ**: ~1000行C、8ビットゲーム機エミュレーター
**Nyash移植目標**: `apps/chip8_nyash/`
#### 🔍 **メモリ管理テストケース**
```nyash
// CPU・メモリ・グラフィックスの相互参照関係でのfini伝播テスト
static box Chip8CPU {
init { memory, graphics, sound }
fini() {
// ⭐ fini伝播：依存オブジェクトの自動クリーンアップ
console.log("🔄 CPU cleanup triggered")
me.memory.cleanup() // メモリバンクの解放
me.graphics.cleanup() // VRAM解放
}
}
static box Chip8Memory {
init { ram, weak_cpu_ref } // CPUへの弱参照
read_byte(address) {
// ⭐ weak生存チェック：CPUがまだ生きているか確認
if (me.weak_cpu_ref.is_alive()) {
return me.ram.get(address)
} else {
console.log("⚠️ CPU destroyed, memory access blocked")
return null
}
}
}
```
#### 📋 **実装要件**
- Chip-8命令セット実装（35命令）
- 64x32ピクセルグラフィックス（`WebCanvasBox`使用）
- サウンド出力（`SoundBox`使用）
- **fini伝播システム**と**weak参照**の実戦テスト
---
### 3. ✏️ **kilo テキストエディター** - 「うっかり全体コピー」検出
**元実装**: https://github.com/antirez/kilo
**サイズ**: ~1000行C、軽量ターミナルエディター
**Nyash移植目標**: `apps/kilo_nyash/`
#### 🔍 **メモリ効率テストケース**
```nyash
// 大きなテキストファイル編集での不必要なコピー検出
static box TextBuffer {
init { lines, undo_stack }
insert_char(row, col, char) {
local old_lines_size = me.lines.memory_footprint()
// 文字挿入操作
me.lines.get(row).insert_at(col, char)
local new_lines_size = me.lines.memory_footprint()
local size_diff = new_lines_size - old_lines_size
// ⭐ 「うっかり全体コピー」検出
if (size_diff > 1000) { // 1文字挿入で1KB以上増加
console.log("🚨 INEFFICIENT COPY DETECTED!")
console.log("Expected: 1 byte, Actual: " + size_diff + " bytes")
me.log_memory_leak_warning()
}
}
// 大規模な検索・置換での効率性チェック
search_and_replace(pattern, replacement) {
local initial_memory = me.lines.memory_footprint()
// 検索・置換実行
me.lines.replace_all(pattern, replacement)
local final_memory = me.lines.memory_footprint()
// メモリ使用量が2倍を超えた場合は問題
if (final_memory > initial_memory * 2) {
console.log("⚠️ Memory usage doubled during replace operation")
}
}
}
```
#### 📋 **実装要件**
- ターミナル操作（`ConsoleBox`での入出力）
- ファイル読み書き（`FileBox`使用）
- 基本的な編集機能（カーソル移動、挿入、削除）
- **メモリ効率監視**と**コピー検出システム**
---
## 🛠️ **技術的実装指針**
### 共通アーキテクチャ
```nyash
// 各アプリケーション共通の構造
static box AppName {
init { core_components }
main() {
me.initialize_components()
me.run_main_loop()
me.cleanup_resources()
}
// メモリ効率レポート（全アプリ共通）
memory_report() {
return new MapBox()
.set("zero_copy_count", me.zero_copy_operations)
.set("unnecessary_copies", me.detected_copies)
.set("memory_leaks", me.fini_failures)
.set("weak_ref_cleanups", me.weak_cleanup_count)
}
}
```
### 新API要件
1. **ゼロコピー判定API**
- `BufferBox.is_shared_with(other)` → BoolBox
- `BufferBox.share_reference(data)` → 参照共有
2. **fini伝播システム**
- 自動的な依存オブジェクトクリーンアップ
- クリーンアップチェーンの可視化
3. **weak参照システム**
- `WeakBox.is_alive()` → BoolBox
- 循環参照の自動検出・回避
4. **メモリ効率監視**
- `Box.memory_footprint()` → IntegerBox
- コピー発生の検出・警告
---
## 🎯 **期待される成果**
### パフォーマンス目標
- **Tinyproxy**: HTTP転送でのゼロコピー率 90%以上
- **Chip-8**: 60FPSエミュレーション + fini伝播の完全動作
- **kilo**: 1MB+ファイル編集でのメモリ効率 95%以上
### 学習効果
- **Copilot**: 大規模Nyashアプリケーション開発経験
- **開発者**: 新メモリ管理機能の実用性確認
- **コミュニティ**: Nyashでの実用アプリケーション事例
---
## 📅 **実装計画**
### Phase 10.1: Tinyproxy実装 (1週間)
- HTTPプロキシ基本機能
- ゼロコピー判定API実装・テスト
### Phase 10.2: Chip-8実装 (1週間)
- エミュレーター基本機能
- fini伝播・weak参照の実戦テスト
### Phase 10.3: kilo実装 (1週間)
- テキストエディター基本機能
- メモリ効率監視システム
### Phase 10.4: 統合テスト・最適化 (1週間)
- 3アプリケーション同時実行テスト
- パフォーマンス分析・改善
---
## 🚀 **この移植プロジェクトの意義**
1. **実用性の実証**: Nyashで実際のアプリケーションが作れることを証明
2. **新機能の検証**: ゼロコピー・fini・weakの実戦テスト
3. **開発体験の向上**: Copilotとの協調開発での生産性検証
4. **エコシステム拡充**: Nyashアプリケーションの具体例提供
**この移植が成功すれば、Nyashは「実用的なプログラミング言語」として確立されます！** 🎉

98
docs/development/roadmap/phases/phase-10/phase_10_x_llvm_backend_skeleton.md Normal file
View File

@ -0,0 +1,98 @@
# Phase 10: LLVM Backend Skeleton（MIR→LLVM IR AOT 最小実装）
目的
- MIRからLLVM IRへの直接変換と、最小AOTパイプラインを構築するための実装ガイド（Copilot向けタスクリスト）。
- Phase 9.7（ABI/BID＋ExternCall）を前提に、外部呼び出しの取り扱いも含めて安全に前進。
前提
- MIR Tier-0/1（Const/BinOp/Compare/Branch/Jump/Phi/Call/Return ほか基本）が利用可能。
- ExternCall命令（Phase 9.7）導入予定。ABIは`docs/予定/native-plan/box_ffi_abi.md`に準拠。
アウトカム（受け入れ基準）
- CLI: `nyash --backend llvm --emit obj app.nyash -o app.o` が成功し、`clang app.o -o app` で実行可能。
- 代表サンプルで `main` が `i32` を返却（0=成功）。
- `ExternCall(env.console.log)` を `printf` 等へ写像し、標準出力へ表示できる（文字列は (i8*, i32)）。
- 単純な四則演算・比較・分岐・ループが LLVM AOT で動作。
実装ステップ
1) モジュール構成の追加（src/backend/llvm）
- `src/backend/llvm/mod.rs`
- `src/backend/llvm/lower.rs`（MIR→LLVM IR 変換）
- `src/backend/llvm/passes.rs`（最小パス設定：DCE/インラインは未使用でOK）
- `src/backend/llvm/build.rs`（オブジェクト生成/ターゲット設定）
2) 依存設定
- Cargo.toml に `llvm-sys` を feature で追加（例: `feature = ["llvm-backend"]`）。
- ビルド要件を `README` に明記（llvm-config が必要、Linux優先）。
3) エントリポイント
- `LLVMBackend { context, module, builder }` 構造体を定義。
- `compile_mir(&MirModule) -> Result<Vec<u8>, String>` を公開：
- `lower_mir_to_llvm` でIR生成
- `apply_minimal_passes`（任意・後回し可）
- `emit_object()` で `.o` を返す
4) 関数シグネチャとmain
- MIRの `main` を `i32 ()` で宣言（戻り値がvoidなら 0 を返す）。
- 将来の引数は未対応でOK（v0）。
5) 値と型の写像（v0）
- i32/i64/f32/f64/bool → それぞれのLLVMプリミティブ型。
- 文字列: (i8*, i32) のペアで扱う（ABIドラフトに一致）。
- Box参照: 当面 `i32` か `i8*` のopaqueに固定（v0ではBox操作は行わない）。
6) 命令の下ろし
- Const: `i32.const` 等を `LLVMConstInt/LLVMConstReal` に対応。
- BinOp: add/sub/mul/div（符号付き）を対応。
- Compare: eq/ne/lt/le/gt/ge（i32想定）。
- Branch: 条件分岐と無条件分岐。
- Phi: ブロックごとに `LLVMPhiNode` を作成。
- Return: 値あり/なしに対応（なしは `i32 0`）。
- Call: 内部関数呼び出し（同Module内）。
- ExternCall: 後述のマッピングに従う。
7) ExternCall の LLVM 写像（v0）
- Console: `env.console.log(ptr,len)` → `declare i32 @printf(i8*, ...)`
- 呼び出し時に `%fmt = getelementptr ([3 x i8], [3 x i8]* @"%.*s", i32 0, i32 0)` などの定数フォーマット文字列を準備
- `printf("%.*s", len, ptr)` で出力（lenは`i32`、ptrは`i8*`）。
- Canvas: ネイティブ環境では利用不可 → v0は `noop` または `printf`でログに落とす（パラメータの表示）。
- 名前解決: BIDのFQN（env.console.log 等）→ 内部ディスパッチ（switch/テーブル）で `printf` 等へ。
8) 文字列定数
- データレイアウトに `@.str = private unnamed_addr constant [N x i8] c"...\00"` を生成し、`getelementptr` で `i8*` を取得。
- ただし v0 のNyash→MIRでは「定数文字列を printf に渡す」パスだけ実装すれば良い。
- StringBoxの具象表現は当面不要（WASMで進行中）。LLVM側は (i8*, i32) で十分。
9) オブジェクト出力
- `LLVMTargetInitializeAllTargets()` 等でターゲット初期化。
- `TargetMachine` を作成し、`LLVMTargetMachineEmitToMemoryBuffer` で `.o` バッファ取得。
- CLIから `.o` をファイル出力。リンクはユーザー側で `clang app.o -o app`。
10) ビルドフラグ/CLI
- `--backend llvm` / `--emit obj` を追加。
- featureが無い/LLVMが無い場合は明確なエラーメッセージ。
11) テスト（最小）
- 算術: `return 40+2;` → `42`。
- 分岐: `if (x<y) return 1 else return 0`。
- ループ: 累積加算で既知の値。
- ExternCall(console.log): 固定文字列/動的整数を出力（`printf("value=%d\n", v)` など）。
12) 将来拡張フック
- Passes: DCE/InstCombine/Inlining/LTO/PGOの導入ポイントを `passes.rs` に下書き。
- Box最適化: エスケープ解析→Stack化（後続Phase）。
- ABI: ExternCallの宣言生成をBIDから自動化（Phase 10後半〜）。
リスクと回避
- LLVMビルド依存: ドキュメント整備（llvm-config 必須）、CIにキャッシュ導入。
- 文字列/外部呼び出し差: v0はprintf固定。Canvas等はログに退避。
- OS差: v0はLinux/clang優先、他環境は後続。
参考
- ABIドラフト: `docs/予定/native-plan/box_ffi_abi.md`
- Phase 9.7: `docs/予定/native-plan/issues/phase_9_7_box_ffi_abi_and_externcall.md`
- LLVM LangRef: https://llvm.org/docs/LangRef.html
- llvm-sys: https://crates.io/crates/llvm-sys
最終更新: 2025-08-14

24
docs/development/roadmap/phases/phase-14/phase14_packaging_ci_polish.md Normal file
View File

@ -0,0 +1,24 @@
# Phase 14: Packaging/CI polish
## Summary
- Windows/Linux の配布パッケージ化と CI 整備。利用者がすぐ使えるバイナリを提供し、ビルドの再現性を担保する。
## Scope
- CI: GitHub Actions で Windows(MSVC) / WSL + cargo-xwin のマトリクス
- リリース成果物: dist/nyash(.exe) + README + LICENSE （必要なら examples/）
- 署名/ハッシュ（任意）：SHA256 発行・検証手順
## Tasks
- [ ] actions ワークフロー作成（キャッシュ/マトリクス/アーティファクト）
- [ ] dist 出力スクリプト（バージョン埋め込み）
- [ ] リリースノートの雛形追加（CHANGELOG or GitHub Releases）
## Acceptance Criteria
- Actions が緑で、アーティファクトが自動生成・ダウンロード可能
- dist/ の内容が README に記載通り
## Out of Scope
- コードサイン（必要になったら追補）
## References
- docs/予定/native-plan/copilot_issues.txt（Phase 14）

24
docs/development/roadmap/phases/phase-5/phase5_2_static_main_lowering.md Normal file
View File

@ -0,0 +1,24 @@
# Phase 5.2: Lowering for static box Main (BoxDeclaration → main body)
Summary:
- static box Main { main() { ... } } を MirBuilder で受け、main() の body を Program として lowering する経路を実装します。
- 目的は `--dump-mir` が static Main 形式のサンプルでも通り、VM 実行にも到達すること。
Scope:
- AST: BoxDeclaration(is_static=true, name=Main) を検出 → 同名 main() を探して Program 化
- Lowering: 発見した body を既存の Program lowering に渡す（関数単位でOK）
- Tests: local_tests/mir_loop_no_local.nyash（static Main）で dump/VM が通る
Tasks:
- [ ] MirBuilder: static Main → Program lowering 経路
- [ ] MirPrinter/Verifier: 必要なら修正
- [ ] サンプル/スナップショットの点検
Acceptance Criteria:
- `nyash --dump-mir ./local_tests/mir_loop_no_local.nyash` が成功
- `nyash --backend vm ./local_tests/mir_loop_no_local.nyash` が成功
References:
- #33, #35
- docs/guides/how-to-build-native/copilot_issues.txt

27
docs/development/roadmap/phases/phase-6/phase6_box_ops_minimal.md Normal file
View File

@ -0,0 +1,27 @@
# Phase 6: Box ops minimal in MIR/VM (RefNew/RefGet/RefSet, WeakNew/WeakLoad)
## Summary
- MIR/VM に Box 参照操作の最小セットを導入。Barrier はダミーで開始。
## Scope
- MIR 命令追加: `RefNew`, `RefGet`, `RefSet`, `WeakNew`, `WeakLoad`, `BarrierRead`/`BarrierWrite`(no-op)
- Lowering: `New`/`FieldAccess`/`MethodCall` の最小対応（`BoxCall` は後続でも可）
- VM: 上記命令の最小実行（参照テーブル/マップでOK）
## Tasks
- [ ] `src/mir/instruction.rs`: 命令追加 + `printer`/`verification` 対応
- [ ] `src/mir/builder.rs`: lowering（最小ケース）
- [ ] `src/backend/vm.rs`: 命令実装
- [ ] サンプル/スナップショットの追加
## Acceptance Criteria
- 新規サンプルで `--dump-mir`/`--backend vm` が成功（Ref/Weak の基本動作）
- weak の自動 null と `fini()` 後使用禁止の不変を壊さない
## References
- `docs/nyash_core_concepts.md`（weak/fini の不変条件）
- Phase 5/5.1/5.2 Issues（control flow/exception/static Main lowering）
## Copilot Notes
- まず `RefNew`/`RefGet`/`RefSet` → `WeakNew`/`WeakLoad` の順で実装。Barrier は no-op でOK。
- サンプルはトップレベル/関数内で回せる形から。`BoxDeclaration` 依存は避けても良い。

96
docs/development/roadmap/phases/phase-7/phase7_async_mir.md Normal file
View File

@ -0,0 +1,96 @@
# Phase 7: Async model in MIR (nowait/await)
## Summary
- nowait/await を MIR に薄く導入（Future 表現）。スレッドベース実装と整合。
- 既存のFutureBox実装を活用し、MIR/VMレイヤーで非同期処理を表現。
## Background
- Nyashでは既にFutureBoxが実装済み（`src/boxes/future/mod.rs`）
- nowait/awaitはトークン・ASTノードとして定義済み
- 現在のインタープリターではthread::spawnベースの実装
## Scope
### MIR命令の追加
- `FutureNew { dst, value }` - 新しいFuture作成（初期値付き）
- `FutureSet { future, value }` - Futureに値を設定
- `Await { dst, future }` - Futureの完了を待って値を取得
### Lowering実装
- `ASTNode::Nowait { variable, expression }` →
1. expressionを評価
2. FutureNew命令でFuture作成
3. 別スレッドでの実行をスケジュール
- `ASTNode::AwaitExpression { expression }` →
1. expressionを評価（Future値を期待）
2. Await命令で値取得
### VM実装
- FutureNew: 新しいVMValue::Future作成
- FutureSet: Future値の更新（is_readyフラグも設定）
- Await: Future完了まで待機してから値を返す
## Tasks
- [ ] Phase 7.1: MIR命令定義
- [ ] `src/mir/instruction.rs`にFutureNew/FutureSet/Await追加
- [ ] Effect maskの設定（FutureNewはPURE、AwaitはREAD）
- [ ] printer/verificationサポート
- [ ] Phase 7.2: AST→MIR lowering
- [ ] `src/mir/builder.rs`にnowait/awaitの処理追加
- [ ] 適切なbasic block分割（awaitは制御フローに影響）
- [ ] Phase 7.3: VM実装
- [ ] `src/backend/vm.rs`にVMValue::Future追加
- [ ] 各命令の実行ロジック実装
- [ ] FutureBoxとの統合
- [ ] Phase 7.4: テスト・検証
- [ ] 基本的なnowait/awaitのテストケース
- [ ] 複数のnowait実行順序テスト
- [ ] エラーケース（Future未完了時の扱い等）
## Test Cases
```nyash
// 基本的なnowait/await
static box Main {
main() {
nowait f1 = compute(10)
nowait f2 = compute(20)
local result1 = await f1
local result2 = await f2
print(result1 + result2)
}
}
// ネストしたnowait
static box Main {
main() {
nowait outer = {
nowait inner = compute(5)
await inner * 2
}
print(await outer)
}
}
```
## Acceptance Criteria
- 上記テストケースがMIRダンプで正しい命令列を生成
- VM実行で期待通りの結果（並行実行→正しい順序で結果取得）
- 既存のFutureBox実装との整合性維持
- verifierがFuture関連の不正を検出
## Implementation Notes
- 初期実装ではシンプルにthread::spawnベース継続
- Futureの型情報は当面VMValue内で管理（型システムは後続フェーズ）
- エラー処理は最小限（Future未完了時のawaitはブロック）
## Out of Scope (Phase 7)
- async/await構文（Rustライク）
- Promise chain / then構文
- 取り消し可能なFuture
- 複雑なスケジューリング戦略
- Future型の静的型チェック
## References
- `docs/nyash_core_concepts.md`（nowait/await + FutureBox）
- `src/boxes/future/mod.rs`（既存FutureBox実装）
- `src/interpreter/async_methods.rs`（現在のnowait/await実装）

143
docs/development/roadmap/phases/phase-8/phase8.3_wasm_box_operations.md Normal file
View File

@ -0,0 +1,143 @@
# Phase 8.3: WASM Box Operations - オブジェクト操作のWASM実装
## Summary
Phase 8.2 PoC1で基本演算のMIR→WASM変換が完成。次はNyashの核心である「Everything is Box」哲学をWASMで実現する。メモリ管理とBox操作（RefNew/RefGet/RefSet）を実装し、オブジェクト指向プログラミングをWASMで動作させる。
## Current State
- ✅ Phase 8.1: WASM基盤完成（メモリ管理・ランタイム・WAT生成）
- ✅ Phase 8.2 PoC1: 基本演算完成（算術・比較・制御フロー・print）
- ✅ Phase 8.2 PoC2: CLI統合完成（`--compile-wasm`オプション + Safepoint対応）
- ✅ Phase 8.2 PoC3: ブラウザ実行確認（Nyash→WASM→Browser完全パイプライン）
- ✅ Phase 8.2 Docs: 実行バックエンド完全ドキュメント作成（execution-backends.md）
- 🚧 Phase 8.3: Box操作実装（本Issue）
## Technical Requirements
### 1. メモリレイアウト拡張
```wat
;; Box layout in WASM linear memory:
;; [type_id:i32][ref_count:i32][field_count:i32][field0:i32][field1:i32]...
;;
;; Example: StringBox
;; [0x1001][1][2][ptr_to_string][string_length]
```
### 2. メモリアロケータ改良
現在のbump allocatorを拡張：
- `malloc(size) -> ptr` - メモリ確保
- `free(ptr)` - メモリ解放（Phase 8.3では未実装、将来対応）
- アライメント考慮（4バイト境界）
### 3. MIR→WASM変換実装
```rust
// Phase 6で実装済みのMIR命令
MirInstruction::RefNew { dst, box_val } // 新規Box作成
MirInstruction::RefGet { dst, reference, field } // フィールド読み取り
MirInstruction::RefSet { reference, field, value } // フィールド書き込み
MirInstruction::NewBox { dst, box_type, args } // Box生成
```
## Implementation Tasks
### Task 1: メモリ管理強化 🔧
- [ ] Box用メモリレイアウト定義（src/backend/wasm/memory.rs）
- [ ] malloc関数のWASM実装（アライメント対応）
- [ ] Box型ID管理システム（StringBox=0x1001等）
### Task 2: RefNew実装 📦
- [ ] `MirInstruction::RefNew` → WASM変換
- [ ] メモリ確保 + 初期化コード生成
- [ ] 参照カウント初期値設定（将来のGC対応準備）
- [ ] **実装例参考**:
```rust
// src/backend/wasm/codegen.rs の MirInstruction::RefNew 処理
MirInstruction::RefNew { dst, box_val } => {
// 1. メモリサイズ計算 (header + fields)
// 2. malloc呼び出し
// 3. type_id設定
// 4. ref_count=1設定
// 5. dst変数に格納
}
```
### Task 3: RefGet/RefSet実装 🔍
- [ ] フィールドオフセット計算
- [ ] `MirInstruction::RefGet` → `i32.load` 変換
- [ ] `MirInstruction::RefSet` → `i32.store` 変換
- [ ] 型安全性チェック（デバッグビルドのみ）
### Task 4: NewBox実装 🎁
- [ ] Box型名→型ID解決
- [ ] コンストラクタ呼び出しシーケンス生成
- [ ] 初期化引数の処理
### Task 5: テスト実装 ✅
- [ ] `test_wasm_poc2_box_operations.rs` 作成
- [ ] 基本的なBox操作テスト
```nyash
// テスト対象のNyashコード相当
box DataBox { init { value } }
local obj = new DataBox()
obj.value = 42
print(obj.value) // 42が出力される
```
- [ ] **Copilot実装支援用：詳細テストケース**
- [ ] RefNew単体テスト（Box作成のみ）
- [ ] RefSet単体テスト（フィールド書き込み）
- [ ] RefGet単体テスト（フィールド読み取り）
- [ ] 複合操作テスト（作成→書き込み→読み取り）
- [ ] エラーハンドリングテスト（不正アクセス等）
- [ ] メモリレイアウト検証テスト（アライメント確認）
## Success Criteria
- [ ] RefNew/RefGet/RefSetがWASMで正常動作
- [ ] 簡単なオブジェクト操作がend-to-endで実行可能
- [ ] メモリレイアウトが明確にドキュメント化
- [ ] 既存のPoC1テストが引き続きPASS
- [ ] **Copilot品質保証**:
- [ ] 全テストケースがCI環境でPASS
- [ ] `cargo check` でビルドエラーなし
- [ ] `--compile-wasm` オプションで正常なWAT出力
- [ ] ブラウザでの実行確認（`wasm_demo/` 環境）
- [ ] 既存Phase 8.2テストとの互換性維持
## Technical Notes
### 現在の実装基盤（2025-08-14時点）
- ✅ **WASM CLI**: `./target/release/nyash --compile-wasm program.nyash` で動作
- ✅ **ブラウザテスト**: `wasm_demo/` ディレクトリに実行環境完備
- ✅ **Safepoint対応**: `src/backend/wasm/codegen.rs:line XX` で実装済み
- ✅ **実行ドキュメント**: `docs/execution-backends.md` で使用方法詳細化
### AST→MIR制約への対応
現在AST→MIRは基本構文のみ対応（ユーザー定義Box未対応）。本Phaseでは：
- MIR直接構築によるテストを優先
- AST→MIR拡張は並行して別タスクで実施
### Copilot実装ガイダンス
Phase 8.3実装時の推奨アプローチ：
1. **段階的実装**: RefNew → RefGet → RefSet の順序で個別実装
2. **テスト駆動**: 各MIR命令に対応する単体テストを先に作成
3. **既存パターン活用**: `src/backend/wasm/codegen.rs` の既存実装を参考
4. **メモリ安全性**: アライメント・境界チェックを必ず実装
5. **デバッグ支援**: WAT出力にコメント追加で可読性向上
### 将来の拡張準備
- 参照カウントフィールドを含むが、Phase 8.3では使用しない
- GC実装は将来のPhaseで対応
- 文字列等の可変長データは次Phase以降
## Dependencies
- wasmtime 18.0.4
- wabt 0.10.0
- 既存のMIR Phase 6実装
## Estimate
- 実装期間: 2-3日
- 複雑度: 中（メモリ管理が主な課題）
- リスク: WASMメモリ管理の複雑性
---
Created: 2025-08-13
Target: Phase 8.3 PoC2
Priority: High

224
docs/development/roadmap/phases/phase-8/phase8_mir_to_wasm.md Normal file
View File

@ -0,0 +1,224 @@
# Phase 8: MIR→WASM codegen (browser/wasmtime; sandboxed; Rust runtime free)
## Summary
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
- Rust は「コンパイラ本体」のみ。実行は純WASM＋ホストimport（env.print 等）。
- Phase 6/7で実装済みのMIR命令（RefNew/RefGet/RefSet, FutureNew/Await等）をWASM命令に変換
## Technical Architecture
### WASM Module Structure
```wat
(module
(memory (export "memory") 1) ; 64KB initial
(import "env" "print" (func $print (param i32)))
;; Heap management
(global $heap_ptr (mut i32) (i32.const 1024))
;; Main entry point
(func (export "main") (result i32)
;; Generated from MIR main function
)
)
```
### Memory Layout
- `0x000-0x3FF`: Reserved/globals
- `0x400-0x7FF`: Stack space
- `0x800+`: Heap (bump allocator)
- Box layout: `[type_id:i32][field_count:i32][field0:i32][field1:i32]...`
## Scope
- **ABI/Imports/Exports（最小）**
- exports: `main() -> i32`, `memory`
- imports: `env.print(i32)`（デバッグ用に整数のみ。将来文字列ABIを定義）
- **メモリ/ヒープ**
- 線形メモリに簡易ヒープ（bump allocator → フリーリスト）
- Box の固定レイアウト（フィールド→オフセット表; 型名→レイアウトは暫定固定）
- **命令カバレッジ（段階導入）**
- **PoC1**: 算術/比較/分岐/loop/return/print
- **PoC2**: RefNew/RefSet/RefGet（Phase 6 と整合）で `print(o.x)`
- **PoC3**: Weak/Barrier の下地（WeakLoad は当面 Some 相当、Barrier は no-op）
- **PoC4**: Future/Await の基本実装（スレッドなしの即座完了）
- **CLI 統合**
- `nyash --backend wasm program.nyash` で生成・実行（wasmtime 呼び出し）
- `--output program.wasm` でWASMファイル出力のみ
## Implementation Plan
### Phase 8.1: 基盤構築 (Foundation)
- [ ] **Task 1.1**: WASMバックエンドモジュール作成
- `src/backend/wasm/mod.rs` - エントリポイント
- `src/backend/wasm/codegen.rs` - MIR→WASM変換器
- `src/backend/wasm/memory.rs` - メモリ管理
- `src/backend/wasm/runtime.rs` - ランタイムヘルパー
- [ ] **Task 1.2**: WASM出力基盤
- WAT形式での出力（人間可読、デバッグ用）
- `wabt` crateでWAT→WASMバイナリ変換
-基本的なmodule structure生成
### Phase 8.2: PoC1 - 基本演算 (Basic Operations)
- [ ] **Task 2.1**: MIR基本命令の変換実装
- `MirInstruction::Const` → WASM `i32.const`
- `MirInstruction::BinOp` → WASM算術命令 (`i32.add`, `i32.mul` etc.)
- `MirInstruction::Compare` → WASM比較命令 (`i32.eq`, `i32.lt` etc.)
- [ ] **Task 2.2**: 制御フロー実装
- `MirInstruction::Branch` → WASM `br_if`
- `MirInstruction::Jump` → WASM `br`
- `MirInstruction::Return` → WASM `return`
- [ ] **Task 2.3**: Print機能実装
- `MirInstruction::Print` → `call $print`
- env.print import の定義
**PoC1目標**: `42 + 8` のような基本計算がWASMで動作
### Phase 8.3: PoC2 - オブジェクト操作 (Object Operations)
- [ ] **Task 3.1**: メモリ管理実装
- Bump allocator (`$heap_ptr` global)
- `malloc(size) -> ptr` WASM function
- Box layout定義 (`[type_id][field_count][fields...]`)
- [ ] **Task 3.2**: 参照操作実装
- `MirInstruction::RefNew` → `call $malloc` + 初期化
- `MirInstruction::RefGet` → memory load (`i32.load offset=...`)
- `MirInstruction::RefSet` → memory store (`i32.store offset=...`)
**PoC2目標**: `o = new Obj(); o.x = 1; print(o.x)` 相当がWASMで動作
### Phase 8.4: PoC3 - 拡張機能下地 (Extension Foundation)
- [ ] **Task 4.1**: Weak参照ダミー実装
- `MirInstruction::WeakNew` → 通常の参照として処理
- `MirInstruction::WeakLoad` → 常にSome相当で成功
- [ ] **Task 4.2**: Barrier命令ダミー実装
- `MirInstruction::BarrierRead/Write` → no-op
- [ ] **Task 4.3**: Future基本実装
- `MirInstruction::FutureNew` → 即座に完了状態のFuture
- `MirInstruction::Await` → 値をそのまま返す
### Phase 8.5: CLI統合 (CLI Integration)
- [ ] **Task 5.1**: CLI実装
- `--backend wasm` オプション追加
- `--output file.wasm` オプション追加
- wasmtimeとの連携（`wasmtime run`）
- [ ] **Task 5.2**: エラーハンドリング
- 未対応MIR命令の明確なエラーメッセージ
- WASM生成失敗時の診断情報
## Acceptance Criteria
### PoC1 (Basic Operations)
- ✅ **WASM Generation**: 基本MIR命令がvalid WASMに変換される
- ✅ **Wasmtime Execution**: `wasmtime run output.wasm` で正常実行
- ✅ **Arithmetic**: `print(42 + 8)` → stdout: `50`
- ✅ **Control Flow**: if文、loop文が正しく動作
### PoC2 (Object Operations)
- ✅ **Memory Allocation**: RefNew でヒープメモリが正しく割り当てられる
- ✅ **Field Access**: `o = new DataBox(); o.value = 1; print(o.value)` → stdout: `1`
- ✅ **Memory Layout**: Box構造がメモリ上で正しいレイアウトになる
### PoC3 (Extension Foundation)
- ✅ **Weak Reference**: WeakNew/WeakLoad命令がno-opとして動作
- ✅ **Memory Barriers**: BarrierRead/Write命令が含まれても実行できる
- ✅ **Future Operations**: FutureNew/Await が即座完了として動作
### CLI Integration
- ✅ **Command Line**: `nyash --backend wasm test.nyash` で実行可能
- ✅ **File Output**: `nyash --backend wasm --output test.wasm test.nyash` でファイル出力
- ✅ **Error Messages**: 未対応機能の明確なエラーメッセージ
## Test Strategy
### Unit Tests (Rust)
```rust
// tests/wasm_codegen_tests.rs
#[test]
fn test_basic_arithmetic_codegen() {
let mir = /* 42 + 8 のMIR */;
let wasm_bytes = WasmBackend::new().compile_module(mir).unwrap();
let result = wasmtime_execute(&wasm_bytes);
assert_eq!(result.stdout, "50\n");
}
#[test]
fn test_ref_operations_codegen() {
let mir = /* object field access のMIR */;
let wasm_bytes = WasmBackend::new().compile_module(mir).unwrap();
let result = wasmtime_execute(&wasm_bytes);
assert_eq!(result.stdout, "1\n");
}
```
### Integration Tests
- `tests/wasm_poc1_arithmetic.nyash` → MIR → WASM → wasmtime実行
- `tests/wasm_poc2_objects.nyash` → RefNew/RefGet/RefSet使用 → WASM実行
- `tests/wasm_poc3_features.nyash` → Weak/Future命令含む → WASM実行
### Browser Testing
```html
<!-- tests/browser_test.html -->
<script type="module">
const importObject = {
env: {
print: (value) => console.log(value)
}
};
const wasmModule = await WebAssembly.instantiateStreaming(
fetch('./test.wasm'), importObject
);
const result = wasmModule.instance.exports.main();
console.log('Result:', result);
</script>
```
## Technical Dependencies
### Required Crates
- `wabt` - WAT ↔ WASM conversion
- `wasmtime` - Runtime execution (dev dependency)
- `wat` - WAT text format parsing (optional)
### WASM Tools
- `wasmtime` CLI - Local execution & testing
- `wasm-objdump` - Binary inspection (optional)
- `wasm-validate` - Validation (optional)
## Development Notes
### Memory Management Strategy
1. **Phase 8.3**: Simple bump allocator (no free)
2. **Future**: Free list allocator
3. **Future**: Generational GC integration
### Type System Mapping
| Nyash Type | MIR Type | WASM Type | Memory Layout |
|-----------|----------|-----------|---------------|
| IntegerBox | Integer | i32 | 4 bytes |
| BoolBox | Bool | i32 | 4 bytes (0/1) |
| DataBox | Box("DataBox") | i32 | ptr to [type_id, field_count, fields...] |
### Debugging Support
- WAT output for human inspection
- Source map generation (future)
- WASM stack trace integration (future)
## Out of Scope (Phase 8)
- 本格的なGC（mark-sweep、generational等）
- Weak参照の実際の無効化メカニズム
- Pin/Unpin、fini()のカスケード処理
- JIT/AOTコンパイル最適化
- 複雑な文字列ABI（UTF-8、length prefixed等）
- WASI I/O インターフェース（file、network等）
## References & Dependencies
- **Phase 6**: RefNew/RefGet/RefSet MIR命令 (実装済み)
- **Phase 7**: FutureNew/Await MIR命令 (実装済み)
- docs/予定/native-plan/README.md（Phase 8詳細）
- docs/説明書/wasm/* (WASM関連ドキュメント)
- [WebAssembly Specification](https://webassembly.github.io/spec/)

335
docs/development/roadmap/phases/phase-8/phase_8_4_ast_mir_lowering.md Normal file
View File

@ -0,0 +1,335 @@
# Phase 8.4: AST→MIR Lowering完全実装
## 🎯 Issue概要
**現在の最重要課題**: Phase 8.3のBox操作WASMが実際にテストできない
**根本原因**: AST→MIR Loweringが不完全で、基本的なオブジェクト指向機能が使用不可
**影響範囲**:
- ユーザー定義Boxが定義・使用できない
- Phase 8.3のRefNew/RefGet/RefSet WASMが実際にテストできない
- Everything is Box哲学の基盤部分が欠如
## 🚨 現在の具体的問題
### 1. ユーザー定義Box定義不可
```nyash
box DataBox {
init { value }
}
```
**エラー**: `BoxDeclaration support is currently limited to static box Main`
### 2. オブジェクト生成不可
```nyash
local obj = new DataBox(42)
```
**エラー**: `Unsupported AST node type: New`
### 3. フィールドアクセス不可
```nyash
obj.value
me.field = 10
```
**エラー**: `Unsupported AST node type: Me`
### 4. デリゲーション構文不完全
```nyash
from Parent.method()
override method() { ... }
```
**エラー**: 未対応
## 📋 実装が必要な機能
### Priority 1: 基本オブジェクト操作
- [ ] **BoxDeclaration**: ユーザー定義Box定義
- [ ] **New expression**: `new DataBox(args)` オブジェクト生成
- [ ] **Field access**: `obj.field` フィールド読み取り
- [ ] **Field assignment**: `obj.field = value` フィールド書き込み
- [ ] **Me expression**: `me.field` 自己参照
### Priority 2: デリゲーション・継承
- [ ] **From expression**: `from Parent.method()` デリゲーション呼び出し
- [ ] **Override declaration**: `override method() { ... }` メソッドオーバーライド
- [ ] **Method calls**: `obj.method(args)` メソッド呼び出し
### Priority 3: 高度な機能
- [ ] **Constructor calls**: `pack()`, `init()` コンストラクタ
- [ ] **Static methods**: `Class.method()` 静的メソッド呼び出し
## 🔧 実装場所・方法
### メインファイル: `src/mir/builder.rs`
#### 1. `build_expression()` メソッド拡張 (行103-)
**現在の対応**: Literal, BinaryOp, UnaryOp, AwaitExpression のみ
**追加が必要**:
```rust
// Line 215付近の _ => Err(...) の前に追加
ASTNode::New { class, arguments, .. } => {
self.build_new_expression(class, arguments)
},
ASTNode::Me { span } => {
// 現在のインスタンスへの参照を返す
self.build_me_expression()
},
ASTNode::FieldAccess { object, field, .. } => {
self.build_field_access(*object, field)
},
ASTNode::MethodCall { object, method, arguments, .. } => {
self.build_method_call(*object, method, arguments)
},
ASTNode::From { parent, method, arguments, .. } => {
self.build_from_expression(parent, method, arguments)
},
```
#### 2. `build_statement()` メソッド拡張
**BoxDeclaration制限解除**:
```rust
// Line 190付近の条件を拡張
ASTNode::BoxDeclaration { name, methods, is_static, fields, .. } => {
if *is_static && name == "Main" {
// 既存のstatic box Main処理
} else {
// 新規：ユーザー定義Box処理
self.build_box_declaration(name.clone(), methods.clone(), fields.clone())
}
}
```
#### 3. 新規メソッド実装が必要
```rust
impl MirBuilder {
fn build_new_expression(&mut self, class: String, arguments: Vec<ASTNode>) -> Result<ValueId, String> {
// RefNew MIR命令生成
// Phase 8.3のWASM Box操作と連携
}
fn build_field_access(&mut self, object: ASTNode, field: String) -> Result<ValueId, String> {
// RefGet MIR命令生成
}
fn build_field_assignment(&mut self, object: ASTNode, field: String, value: ASTNode) -> Result<ValueId, String> {
// RefSet MIR命令生成
}
fn build_me_expression(&mut self) -> Result<ValueId, String> {
// 現在のインスタンスへの参照
}
fn build_box_declaration(&mut self, name: String, methods: Vec<ASTNode>, fields: Vec<String>) -> Result<(), String> {
// ユーザー定義Box登録
}
}
```
## 🧪 テストケース（Copilot実装必須）
### Test 1: 基本Box定義・生成
**ファイル**: `test_user_defined_box.nyash`
```nyash
box DataBox {
init { value }
pack(v) {
me.value = v
}
}
static box Main {
main() {
local obj = new DataBox(42)
return obj.value
}
}
```
**期待MIR出力例**:
```mir
define void @main() {
bb0:
0: safepoint
1: %0 = const 42
2: %1 = ref_new "DataBox", %0
3: %2 = ref_get %1, "value"
4: ret %2
}
```
**実行期待結果**: `42`
### Test 2: フィールドアクセス・代入
**ファイル**: `test_field_operations.nyash`
```nyash
box Counter {
init { count }
pack() {
me.count = 0
}
increment() {
me.count = me.count + 1
return me.count
}
}
static box Main {
main() {
local c = new Counter()
return c.increment()
}
}
```
**期待結果**: `1`
### Test 3: デリゲーション基本
**ファイル**: `test_delegation_basic.nyash`
```nyash
box Parent {
init { name }
pack(n) {
me.name = n
}
greet() {
return "Hello " + me.name
}
}
box Child from Parent {
init { age }
pack(n, a) {
from Parent.pack(n)
me.age = a
}
override greet() {
local base = from Parent.greet()
return base + " (age " + me.age + ")"
}
}
static box Main {
main() {
local c = new Child("Alice", 25)
return c.greet()
}
}
```
**期待結果**: `"Hello Alice (age 25)"`
### Test 4: WASM Box操作統合テスト
**ファイル**: `test_wasm_box_integration.nyash`
```nyash
box SimpleData {
init { x, y }
pack(a, b) {
me.x = a
me.y = b
}
sum() {
return me.x + me.y
}
}
static box Main {
main() {
local data = new SimpleData(10, 20)
return data.sum()
}
}
```
**テスト方法**:
```bash
# MIR生成テスト
./target/release/nyash --dump-mir test_wasm_box_integration.nyash
# WASM生成テスト
./target/release/nyash --compile-wasm test_wasm_box_integration.nyash
# WASM実行テスト（wasmtime）
./target/release/nyash --compile-wasm test_wasm_box_integration.nyash > test.wat
sed -n '4,$p' test.wat > clean_test.wat
$HOME/.wasmtime/bin/wasmtime run clean_test.wat --invoke main
```
**期待結果**: 全プロセスでエラーなし、最終結果 `30`
## ✅ 成功基準
### 必須基準
- [ ] 上記4つのテストケースがすべて成功
- [ ] `cargo build --release` でエラーなし
- [ ] 既存のstatic box Main機能が破損していない
- [ ] Phase 8.3のWASM Box操作が実際に動作確認
### 理想基準
- [ ] MIR→WASM→wasmtime実行の完全パイプライン動作
- [ ] ベンチマーク性能が劣化していない
- [ ] 複雑なデリゲーション・継承チェーンが動作
## 🤖 Copilot向け実装ガイド
### 実装順序推奨
1. **Phase 1**: `build_new_expression()` - オブジェクト生成
2. **Phase 2**: `build_field_access()` - フィールド読み取り
3. **Phase 3**: Field assignment - フィールド書き込み
4. **Phase 4**: `build_me_expression()` - 自己参照
5. **Phase 5**: `build_box_declaration()` - Box定義
6. **Phase 6**: デリゲーション構文
### 既存コードとの統合注意点
- **MIR命令**: 既存のRefNew/RefGet/RefSet MIR命令を活用
- **型システム**: 既存のValueId/BasicBlockId体系を維持
- **エラーハンドリング**: 既存のResult<ValueId, String>パターンを踏襲
### デバッグ支援
```bash
# MIR生成確認
./target/release/nyash --dump-mir --mir-verbose test_file.nyash
# パーサー確認
./target/release/nyash --debug-fuel unlimited test_file.nyash
```
## 📊 期待される効果
### 技術的効果
- Phase 8.3のBox操作WASMが実際に使用可能
- Everything is Box哲学の実用レベル実現
- 真のオブジェクト指向プログラミング対応
### 開発効率向上
- Nyashプログラムの実用性大幅向上
- 実際のアプリケーション開発が可能
- ベンチマーク・テストの精度向上
## 🔗 関連リンク
- **Phase 8.3実装**: RefNew/RefGet/RefSet WASM対応
- **MIR設計**: `docs/説明書/reference/mir-reference.md`
- **AST定義**: `src/ast.rs`
- **既存MIR実装**: `src/mir/instruction.rs`
---
**優先度**: Critical
**担当**: Copilot + Claude協調実装
**最終目標**: test_wasm_box_integration.nyash が完全動作

338
docs/development/roadmap/phases/phase-8/phase_8_5_mir_25_instruction_specification.md Normal file
View File

@ -0,0 +1,338 @@
# Phase 8.5: MIR 25命令完全仕様実装（ChatGPT5 + AI大会議決定版）
## 🎯 Issue概要
**最終決定**: AI大会議（Gemini+Codex）+ ChatGPT5先生によるMIR 25命令完全仕様の実装
**仕様確定**: ChatGPT5先生が「化け物に伸びる余白」と「実装の現実」のちょうど真ん中として設計した、**Nyashのコア価値（所有森＋weak＋Bus＋効果注釈）を無理なくIR化**する完璧な25命令セット
## 📋 確定版: MIR 25命令完全仕様
### **Tier-0: 普遍コア（8命令）**
```mir
Const // 定数値生成（pure）
BinOp // 二項演算（pure）
Compare // 比較演算（pure）
Branch // 条件分岐（control）
Jump // 無条件ジャンプ（control）
Phi // SSA phi関数（pure）
Call // 外部関数呼び出し（context依存）
Return // 関数戻り（control）
```
**効果**: 将来のJIT/AOT/WASMすべてで必須の基盤
### **Tier-1: Nyashセマンティクス（12命令）**
```mir
NewBox // 強所有のBox生成（所有森のノード）
BoxFieldLoad // Boxのフィールド読み（pure）
BoxFieldStore // Boxのフィールド書き（mut）
BoxCall // Boxのメソッド呼び出し（context依存）
Safepoint // 分割finiや割込み許可ポイント（io）
RefGet // 参照（強/弱を問わず）を値として取得（pure）
RefSet // 参照の差し替え（所有規則検証付き）（mut）
WeakNew // weak ハンドル生成（非所有リンク作成）（pure）
WeakLoad // weak から生存チェック付きで強参照取得（失効時null）（pure）
WeakCheck // weak の生存確認（bool）（pure）
Send // Bus送信（io）
Recv // Bus受信（io）
```
**革命的価値**: **所有森＋weak＋Bus** が言語一次市民として表現可能
### **Tier-2: 実装補助・最適化友好（5命令）**
```mir
TailCall // 末尾呼び出し（スタック節約）（control）
Adopt // 所有移管: this が子を強所有に取り込む（mut）
Release // 強所有を解除（weak化 or null化）（mut）
MemCopy // 小さなメモリ移動（構造体/配列最適化フック）（mut）
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）（io）
```
**位置づけ**: 言語仕様の裏方。無くても表現可能だが、**性能・安全検査・移植性**が安定
## 🔧 効果（Effect）システム
### 効果分類と最適化ルール
```rust
pub enum Effect {
Pure, // 再順序化OK、CSE/LICM可能
Mut, // 同一Box/同一Fieldで依存保持
Io, // 再順序化禁止、副作用あり
Control, // 制御フロー変更
}
```
### 命令別効果定義
- **pure**: Const, BinOp, Compare, Phi, RefGet, WeakNew, WeakLoad, WeakCheck
- **mut**: BoxFieldStore, RefSet, Adopt, Release, MemCopy
- **io**: Send, Recv, Safepoint, AtomicFence
- **control**: Branch, Jump, Return, TailCall
- **context依存**: Call, BoxCall（呼び先効果に従属）
## 🔍 検証（Verifier）要件
### 所有森検証ルール
```rust
// 1. 強参照のin-degree制約
fn verify_ownership_forest(mir: &MirModule) -> Result<(), VerifyError> {
for instruction in mir.instructions() {
match instruction {
NewBox { dst, .. } => verify_strong_indegree_one(dst)?,
Adopt { parent, child, .. } => verify_ownership_transfer(parent, child)?,
Release { ref_val, .. } => verify_release_safety(ref_val)?,
RefSet { target, new_ref, .. } => verify_refset_safety(target, new_ref)?,
_ => {}
}
}
}
// 2. 強循環禁止検証
fn verify_no_strong_cycles(mir: &MirModule) -> Result<(), VerifyError> {
// 強エッジのみ辿ってDAG（森）であることを確認
}
// 3. weak参照の決定的挙動
fn verify_weak_determinism(mir: &MirModule) -> Result<(), VerifyError> {
// WeakLoad/WeakCheckの失効時はnull/falseを返す（例外禁止）
}
```
### 安全性検証項目
- [ ] **所有森**: `strong in-degree ≤ 1`（NewBox/Adopt/Release/RefSetで常時検査）
- [ ] **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
- [ ] **weak/強相互**: 双方向とも強 → エラー（片側はWeakNew経由で弱化）
- [ ] **RefSetの安全**: 強→強の差し替え時は旧所有元からのReleaseが伴うこと
- [ ] **WeakLoad/WeakCheck**: 失効時はnull/falseを返す（例外禁止、決定的挙動）
- [ ] **TailCall**: 末尾位置のみ可（Return直前）
- [ ] **Send/Recv**: at-least-once契約を満たすか、契約を明示
## 🚀 実装範囲・優先度
### Phase 8.5A: コア命令実装（最優先）
- [ ] **Tier-0完全実装**: 8命令の基盤確立
- [ ] **Tier-1 Box操作**: NewBox, BoxFieldLoad/Store, BoxCall
- [ ] **Tier-1 weak参照**: WeakNew, WeakLoad, WeakCheck
- [ ] **効果システム**: Effect注釈とVerifier基盤
### Phase 8.5B: 高度機能（重要）
- [ ] **所有移管**: Adopt, Release命令実装
- [ ] **最適化**: TailCall, MemCopy実装
- [ ] **並行制御**: AtomicFence実装
- [ ] **Bus操作**: Send, Recv統合
### Phase 8.5C: 検証・最適化（完成度）
- [ ] **Verifier完全実装**: 所有森・strong循環・安全性検証
- [ ] **バックエンド対応**: Interpreter/VM/WASM全対応
- [ ] **最適化パス**: pure再順序化・mut依存保持・io順序保証
## 🧪 代表的ロワリング実装例
### 1. look参照のロワリング
```nyash
// Nyashソース
local weak_ref = look parent.child
// MIRロワリング
%0 = WeakNew %parent_child_ref
%1 = WeakLoad %0 // 読み取り時に生存チェック
```
### 2. borrow{}ブロックのロワリング
```nyash
// Nyashソース
borrow parent.field {
use_field(parent.field)
}
// MIRロワリング
%0 = WeakNew %parent_field // ブロック先頭
%1 = WeakLoad %0
%2 = Call @use_field, %1
// ブロック末尾でハンドル破棄（MIR上はNop、型で書換禁止）
```
### 3. Bus最適化（Elision）
```nyash
// Nyashソース
send(data, local_receiver)
local result = recv(local_receiver)
// MIR最適化前
%0 = Send %data, %local_receiver
%1 = Recv %local_receiver
// MIR最適化後（同一スレッド/アリーナの場合）
%0 = BoxFieldLoad %local_receiver, "buffer"
%1 = BoxFieldStore %local_receiver, "buffer", %data
// Send/Recv → 直接アクセスに縮退
```
## 🎯 バックエンド別実装指針
### Interpreter実装
```rust
// 25命令を素直に実装（正しさの基準）
match instruction {
MirInstruction::NewBox { dst, box_type } => {
let box_val = create_box(box_type);
self.set_value(dst, box_val);
},
MirInstruction::WeakCheck { dst, weak_ref } => {
let is_alive = self.check_weak_alive(weak_ref);
self.set_value(dst, Value::Bool(is_alive));
},
MirInstruction::TailCall { func, args } => {
self.prepare_tail_call(func, args);
return TailCallResult::Jump;
},
// ... 他23命令
}
```
### VM実装
```rust
// Register-VM + direct-threading
// Send/Recvはローカル判定時にインライン化
impl VM {
fn execute_send(&mut self, data: RegId, target: RegId) {
if self.is_local_target(target) {
// ローカル最適化: 直接バッファ書き込み
self.local_buffer_write(target, data);
} else {
// 通常のBus送信
self.bus_send(data, target);
}
}
}
```
### WASM実装
```rust
// Send/Recvはhost import、MemCopyはmemory.copyに対応
fn compile_mem_copy(&mut self, dst: WasmAddr, src: WasmAddr, size: u32) {
self.emit_wasm_instruction(&WasmInstruction::MemoryCopy {
dst_offset: dst,
src_offset: src,
size,
});
}
fn compile_send(&mut self, data: ValueId, target: ValueId) {
// host importとして実装
self.emit_call_import("env.bus_send", &[data, target]);
}
```
### JIT実装（将来）
```rust
// TailCall最適化、WeakLoadは世代タグでO(1)生存チェック
impl JITCompiler {
fn compile_weak_load(&mut self, dst: RegId, weak_ref: RegId) -> JITCode {
// 世代タグによる高速生存チェック
let generation_check = self.emit_generation_check(weak_ref);
let load_value = self.emit_conditional_load(weak_ref, generation_check);
self.emit_store_register(dst, load_value)
}
}
```
## 🧪 テスト戦略
### 1. Golden MIR テスト
```bash
# 各サンプルのMIRダンプが全バックエンドで一致
./target/release/nyash --dump-mir test_golden_mir.nyash > golden.mir
./target/release/nyash --backend vm --dump-mir test_golden_mir.nyash > vm.mir
./target/release/nyash --backend wasm --dump-mir test_golden_mir.nyash > wasm.mir
diff golden.mir vm.mir && diff vm.mir wasm.mir
```
### 2. 行動一致テスト
```bash
# 同入力→同出力（weak失効時のnull/false含む）
./target/release/nyash --backend interpreter test_behavior.nyash > interp.out
./target/release/nyash --backend vm test_behavior.nyash > vm.out
./target/release/nyash --backend wasm test_behavior.nyash > wasm.out
diff interp.out vm.out && diff vm.out wasm.out
```
### 3. 性能スモークテスト
```bash
# 5種の代表ケースで性能継続検証
./target/release/nyash --benchmark add_loop.nyash
./target/release/nyash --benchmark map_getset.nyash
./target/release/nyash --benchmark alloc_free.nyash
./target/release/nyash --benchmark bus_local.nyash
./target/release/nyash --benchmark bus_actor.nyash
# 期待値: VMがinterp以上、WASMがVM以上
```
## ✅ 成功基準
### 必須基準（Phase 8.5完成）
- [ ] **25命令完全実装**: 全バックエンドで25命令サポート
- [ ] **効果システム動作**: pure/mut/io/control効果の正確な実装
- [ ] **Verifier動作**: 所有森・strong循環・安全性検証の動作確認
- [ ] **Golden MIRテスト**: 全テストケースでMIR一致
- [ ] **行動一致テスト**: 全バックエンドで出力一致
- [ ] **性能要件**: VM≥Interpreter、WASM≥VM
### 理想基準（長期価値）
- [ ] **最適化効果**: pure再順序化・CSE/LICM・Bus elision動作確認
- [ ] **所有森活用**: Adopt/Release/RefSetによる安全で効率的なメモリ管理
- [ ] **weak参照活用**: WeakCheck/WeakLoadによる軽量で安全な弱参照
- [ ] **JIT準備**: TailCall/MemCopyによる将来JIT最適化基盤
## 🤖 Copilot向け実装ガイド
### 実装順序推奨
1. **Tier-0基盤**: 8命令の確実な実装
2. **Box操作**: NewBox, BoxFieldLoad/Store（Everything is Box核心）
3. **weak参照**: WeakNew, WeakLoad, WeakCheck（循環参照対策）
4. **効果システム**: Effect注釈とVerifier統合
5. **高度機能**: Adopt/Release, TailCall等
6. **テスト**: Golden MIR・行動一致・性能検証
### 重要な設計原則
- **Everything is Box**: BoxFieldLoad/Storeで明確にBox中心設計
- **所有森**: strong in-degree ≤ 1を常時保証
- **決定的挙動**: WeakLoad/WeakCheckの失効時動作を一貫化
- **効果注釈**: 最適化パスの基盤となる正確な効果分類
### デバッグ支援
```bash
# MIR命令別実行トレース
./target/release/nyash --trace-mir-execution test.nyash
# 所有森検証
./target/release/nyash --verify-ownership-forest test.nyash
# 効果システム確認
./target/release/nyash --dump-mir-effects test.nyash
```
## 📊 期待される効果
### 技術的効果
- **所有森＋weak＋Bus**のIRレベル実現
- JIT/AOT最適化の強固な基盤確立
- バックエンド間の実装一貫性向上
### 開発効率向上
- 意味明確なMIRによるデバッグ性向上
- 最適化パス開発の大幅な容易化
- 長期保守コストの劇的削減
### パフォーマンス向上
- Bus elisionによる通信最適化
- pure命令の積極的再順序化
- TailCall/MemCopyによる実行効率化
---
**優先度**: Critical（Phase 8.4完了直後）
**担当**: Copilot + Claude協調実装
**仕様策定**: ChatGPT5 + AI大会議（Gemini+Codex）完全一致決定
**最終目標**: Nyashコア価値の完璧なIR化実現

259
docs/development/roadmap/phases/phase-8/phase_8_5_mir_35_to_26_reduction.md Normal file
View File

@ -0,0 +1,259 @@
# Phase 8.5: MIR 35→26命令削減プロジェクト（緊急実装）
## 🚨 **緊急度: Critical**
**発見日**: 2025年8月17日
**問題**: MIR実装が35命令に膨張（ChatGPT5仕様26命令から75%超過）
**Gemini評価**: 削減戦略「極めて健全」「断行推奨」「不可欠なステップ」
## 🎯 **Issue概要**
### **技術的負債の深刻化**
- **実装**: 35命令（175%膨張）
- **設計**: 26命令（ChatGPT5 + AI大会議決定版）
- **リスク**: バックエンド実装困難・最適化爆発・保守性悪化
### **削減の必要性**
1. **バックエンド負荷**: 各バックエンドで35命令対応が重すぎ
2. **最適化複雑化**: 命令数に比例して最適化ルール爆発
3. **テスト困難**: 組み合わせ爆発でテストケース管理不能
4. **長期保守**: 新機能追加時の影響範囲予測困難
## 📋 **削減対象命令分析**
### **削除対象: 17命令**
#### **1. BinOp統合 (1命令)**
- `UnaryOp` → `BinOp`統合（not %a → %a xor true）
#### **2. BoxField操作統合 (4命令)**
- `Load` → `BoxFieldLoad`
- `Store` → `BoxFieldStore`
- `ArrayGet` → `BoxFieldLoad`（配列もBoxフィールド）
- `ArraySet` → `BoxFieldStore`
#### **3. intrinsic化 (6命令)**
```rust
// 削除前
Print %value
Debug %value "message"
TypeCheck %box "Type"
Cast %value Type
// 削除後（intrinsic化）
Call @print, %value
Call @debug, %value, "message"
Call @type_check, %box, "Type"
Call @cast, %value, Type
```
#### **4. 完全削除 (4命令)**
- `Copy` → 最適化パス専用（MIRから除外）
- `Nop` → 不要命令削除
- `Throw/Catch` → Call経由例外処理
#### **5. 統合・置換 (2命令)**
- `RefNew` → 削除（RefGetで代用）
- `BarrierRead/BarrierWrite` → `AtomicFence`統合
- `FutureNew/FutureSet/Await` → `NewBox + BoxCall`実装
### **新規追加: 10命令**
#### **Box操作明示化**
- `BoxFieldLoad/BoxFieldStore` → Everything is Box核心
- `Adopt/Release` → 所有権移管の明示
#### **弱参照完全対応**
- `WeakCheck` → 生存確認の明示
- `Send/Recv` → Bus操作一次市民化
#### **最適化基盤**
- `TailCall, MemCopy, AtomicFence` → JIT/AOT準備
## 🗓️ **5段階実装計画**
### **Phase 1: 共存実装 (完了)**
**担当**: Copilot + Claude協調
**期間**: 2025年8月17日（1日で完了！）
#### **実装範囲**
- ✅ 新旧命令両対応MIRパーサー
- ✅ `BoxFieldLoad/BoxFieldStore`新命令追加
- ✅ `WeakCheck/Send/Recv`新命令追加
- ✅ `TailCall/Adopt/Release/MemCopy/AtomicFence`新命令追加
- ✅ 既存命令保持での互換性確保
#### **技術的詳細**
```rust
// src/mir/instruction.rs 拡張
pub enum MirInstruction {
// 既存命令（保持）
Load { .. },
Store { .. },
// 新命令（追加）
BoxFieldLoad { dst: ValueId, box_val: ValueId, field: String },
BoxFieldStore { box_val: ValueId, field: String, value: ValueId },
// ... 他新命令
}
```
### **Phase 2: フロントエンド移行 (完了)**
**期間**: 2025年8月17日（即日完了）
#### **実装範囲**
- ✅ AST→MIR生成を新形式のみに変更
- ✅ `Load/Store`生成停止、`BoxFieldLoad/BoxFieldStore`生成開始
- ✅ intrinsic化対象を`Call @intrinsic_name`形式で生成
- ✅ 配列操作の`BoxField`表現実装
#### **検証項目**
- [ ] 全Nyashプログラムが新MIRで実行可能
- [ ] Golden MIRテスト準備完了
### **Phase 3: 最適化パス移行 (完了)**
**期間**: 2025年8月17日（即日完了）
#### **実装範囲**
- ✅ 全最適化パスを新命令対応に修正
- ✅ Effect分類の正確な実装（pure/mut/io/control）
- ✅ 所有権森検証ルール実装
- ✅ `BoxFieldLoad/BoxFieldStore`最適化パス
#### **Effect System実装**
```rust
// Pure命令の再順序化
fn optimize_pure_reordering(mir: &mut MirModule) {
// BoxFieldLoad, WeakLoad等の安全な再順序化
}
// Mut命令の依存解析
fn analyze_mut_dependencies(mir: &MirModule) -> DependencyGraph {
// BoxFieldStore間の依存関係解析
}
```
### **Phase 4: バックエンド移行 (完了)**
**期間**: 2025年8月17日（即日完了）
#### **実装範囲**
- ✅ Interpreter新命令対応（既存実装で対応）
- ✅ VM新命令対応（レジスタベース最適化）
- ✅ WASM新命令対応（memory操作最適化）
- ✅ intrinsic関数実装（@print, @debug, @type_check等）
#### **intrinsic実装例**
```rust
// Interpreterでのintrinsic実装
fn execute_intrinsic_call(&mut self, name: &str, args: &[Value]) -> Result<Value> {
match name {
"@print" => {
println!("{}", args[0]);
Ok(Value::Void)
},
"@array_get" => {
let array = &args[0];
let index = args[1].as_integer();
Ok(array.get_element(index))
},
// ... 他intrinsic
}
}
```
### **Phase 5: 旧命令削除・クリーンアップ (進行中)**
**期間**: 2025年8月17日〜
#### **実装範囲**
- ✅ 削除対象17命令にdeprecatedマーク付与（Phase 5-1）
- ✅ バックエンドから実装削除（Phase 5-2）
- ✅ フロントエンドから生成停止（Phase 5-3）
- 🔄 テストスイート更新（Phase 5-4進行中）
- 🔄 ドキュメント更新・整備（Phase 5-4進行中）
- [ ] 最終検証とクリーンアップ（Phase 5-5）
#### **クリーンアップ項目**
- [ ] `UnaryOp, Load, Store, Print, Debug`等の完全削除
- [ ] 関連するテストケース更新
- [ ] エラーメッセージ更新
- [ ] APIドキュメント更新
## 🧪 **検証・品質保証**
### **Golden MIR テスト**
```bash
# 全バックエンドMIR一致確認
./scripts/test_golden_mir_26.sh
```
### **所有権森検証**
```rust
// 自動検証システム
fn verify_ownership_forest_constraints(mir: &MirModule) -> Result<(), VerifyError> {
// strong in-degree ≤ 1
// DAG構造（強循環禁止）
// WeakLoad/WeakCheck決定的挙動
}
```
### **回帰テスト**
- [ ] 全実用アプリケーション動作確認
- [ ] 性能劣化チェック（ベンチマーク実行）
- [ ] メモリ使用量確認
## 📊 **成功基準**
### **必須基準（Phase 5完了時）**
- ✅ **26命令完全実装**: ChatGPT5仕様100%準拠
- ✅ **機能完全性**: 既存Nyashプログラム100%動作（実行確認済み）
- [ ] **性能維持**: 削減前と同等以上の性能（測定予定）
- [ ] **Golden MIRテスト**: 全バックエンドMIR一致（テスト更新中）
- ✅ **所有権森検証**: 強参照森・weak参照安全性保証（実装済み）
### **理想基準（追加価値）**
- [ ] **最適化効果**: pure再順序化・CSE/LICM動作確認
- [ ] **メモリ効率**: Adopt/Releaseによる効率的メモリ管理
- [ ] **コード品質**: 複雑性大幅削減・保守性向上
## 🚨 **リスク管理**
### **高リスク要因**
1. **大規模リファクタリング**: 全コンポーネント影響
2. **互換性破綻**: 既存プログラム動作不良
3. **性能劣化**: 最適化ロジック変更による影響
4. **バックエンド不整合**: 実装差異による動作違い
### **リスク軽減策**
- **段階的移行**: 5 Phaseによる漸進的変更
- **共存期間**: 新旧両対応での安全な移行
- **包括テスト**: Golden MIR・回帰テスト・性能測定
- **ロールバック準備**: 各Phase完了時点でのバックアップ
## 👥 **実装体制**
### **主担当**
- **Copilot**: コード実装（フロントエンド・バックエンド）
- **Claude**: 設計・レビュー・ドキュメント・テスト戦略
### **専門分担**
- **Phase 1-2**: フロントエンド（AST→MIR生成）
- **Phase 3**: 最適化パス・Effect System
- **Phase 4**: バックエンド（Interpreter/VM/WASM）
- **Phase 5**: 統合・テスト・クリーンアップ
## 📚 **関連資料**
- **ChatGPT5仕様**: `docs/予定/native-plan/copilot_issues_phase0_to_94.txt`
- **26命令詳細**: `docs/説明書/mir-26-specification.md`
- **Gemini分析**: 「極めて健全」「断行推奨」評価レポート
---
**Issue作成**: 2025年8月17日
**実装開始**: 2025年8月17日
**進捗状況**: Phase 5-4（90%完了）
**想定完了**: 2025年8月17日中（本日中）
**優先度**: Critical（他全作業に優先）
**驚異的な進捗**: 当初5週間想定だった作業を1日で90%完了！

160
docs/development/roadmap/phases/phase-8/phase_8_5_mir_semantic_layering.md Normal file
View File

@ -0,0 +1,160 @@
# Phase 8.5: MIRセマンティック階層化（AI大会議決定版）
## 🎯 Issue概要
**方針転換**: ChatGPT5推奨の「20命令intrinsic戦略」から、**Gemini+Codex両先生一致推奨の「25命令セマンティック階層化」**に変更
**理由**: AI大会議による深い分析の結果、20命令intrinsic戦略は以下の致命的問題が判明：
- JIT/AOT最適化機会の喪失
- Everything is Box哲学の意味情報消失
- 長期的な実装・保守コスト増大
- パフォーマンス劣化リスク
## 🧠 AI大会議分析結果
### Gemini先生分析（理論面）
- **「賢いコンパイラは、賢いMIRから生まれる」**
- RefNew/WeakLoadのintrinsic化 = 最適化阻害の悪手
- BoxFieldLoad/Store等でEverything is Box明示化
- セマンティック階層化で意味保持
### Codex先生分析（実装面）
- **二相ロワリング戦略**: 25命令維持パス + 20+intrinsic降格パス
- 実装コスト: 5命令追加で10-20人日（intrinsic戦略より安い）
- マイクロベンチ実測でintrinsicオーバーヘッド検証
- 段階的移行（35→25）で安全な実装
## 📋 決定版: セマンティック階層化MIR（25命令）
### **Tier-0: 普遍的コア（8命令）**
```mir
Const, BinOp, Compare, Branch, Jump, Return, Phi, Call
```
- どんな言語にも共通する基本命令群
- 全バックエンドで必須サポート
### **Tier-1: Nyashセマンティクス（12命令）**
```mir
NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, Safepoint,
RefGet, RefSet, WeakNew, WeakLoad, Send, Recv,
TypeTest, WeakUpgrade
```
- **Everything is Box哲学の具現化**
- **最適化に不可欠**: JIT/AOTでのエスケープ解析・RC除去の基盤
- **BoxFieldLoad/Store**: `obj.field`専用（Load/Storeより明確）
- **TypeTest**: 動的型検査（分岐最適化の核心）
- **WeakUpgrade**: weak→strong昇格（GC協調で重要）
### **Tier-2: 高度フロー（5命令）**
```mir
Throw, Catch, Pin, Unpin, Barrier
```
- 必須だが頻出度低い高度機能
- WASM等ではランタイム関数呼出しに降格可能
## 🔄 二相ロワリング戦略（Codex提案）
### アーキテクチャ
```
Frontend → New MIR(25命令) →
├─ パスA: VM/JIT/AOT向け（25命令のまま最適化）
└─ パスB: WASM/最小実装向け（25→20+intrinsic降格）
```
### 利点
- **柔軟性**: バックエンドの能力に応じて最適形式選択
- **互換性**: 既存35命令からの段階移行
- **性能**: 高度バックエンドでセマンティクス活用、最小バックエンドで実装簡素化
## 🧪 検証戦略
### 1. パフォーマンス実測（Codex設計）
**マイクロベンチ3カテゴリ:**
- BoxFieldLoad/Store連鎖（構造体/配列/辞書）
- WeakLoad/Upgrade頻発＋GCセーフポイント
- Send/Recvホットループ＋多待ち
**比較軸:**
- 35現行 vs 25セマンティクス vs 20+intrinsic
- Interpreter/VM/WASM全バックエンド
- 命令数/ランタイムcall回数/最適化効果
### 2. 実装検証
**段階的移行（4フェーズ）:**
1. 仕様固定・ロワリング設計
2. 二相ロワリング導入＋互換Shim
3. バックエンド増分対応
4. 旧命令縮退・削除
### 3. 機能保持確認
- **参照実装**: 単一ソース→両MIR→出力一致検証
- **ゴールデンMIR**: 代表プログラムのスナップショット
- **差分実行**: Interpreter/VM/WASMトライアングル比較
## 🎯 実装優先度
### Phase 8.5A: コア変換（最優先）
- [ ] Tier-0/1命令の詳細仕様策定
- [ ] BoxFieldLoad/Store → RefGet/SetのMIR変換
- [ ] TypeTest/WeakUpgrade命令実装
### Phase 8.5B: 二相ロワリング
- [ ] 25命令維持パス実装
- [ ] 20+intrinsic降格パス実装
- [ ] バックエンド選択ロジック
### Phase 8.5C: 検証・最適化
- [ ] マイクロベンチ実装・実測
- [ ] Golden MIRテストスイート
- [ ] 性能回帰検出CI
## ✅ 成功基準
### 必須基準
- [ ] 25命令セマンティクス完全実装
- [ ] 全バックエンドで機能保持
- [ ] パフォーマンス劣化なし（ベンチマーク基準）
- [ ] Golden MIRテスト全PASS
### 理想基準
- [ ] JIT/AOTでの最適化効果確認
- [ ] WASM降格パスでも実用性能
- [ ] 開発・デバッグ体験向上
## 🤖 Copilot向け実装ガイド
### 重要なポイント
- **BoxFieldLoad/Store重視**: Everything is Box哲学の核心
- **TypeTest活用**: 動的型検査最適化
- **WeakUpgrade**: GC協調の要
- **二相設計**: 高度バックエンドと最小バックエンドの両立
### デバッグ支援
```bash
# セマンティクス確認
./target/release/nyash --dump-mir-semantic test.nyash
# 降格パス確認
./target/release/nyash --dump-mir-lowered test.nyash
# 性能比較
./target/release/nyash --benchmark-mir-passes test.nyash
```
## 📊 期待される効果
### 技術的効果
- Everything is Box哲学のMIRレベル実現
- JIT/AOTでの高度最適化基盤確立
- バックエンド実装の柔軟性向上
### 開発効率向上
- MIR可読性・デバッグ性大幅改善
- 最適化パス開発の容易化
- 長期保守コスト削減
---
**優先度**: High（Phase 8.4完了後）
**担当**: Copilot + Claude協調実装
**AI大会議結論**: Gemini+Codex両先生完全一致推奨

438
docs/development/roadmap/phases/phase-8/phase_8_6_vm_performance_improvement.md Normal file
View File

@ -0,0 +1,438 @@
# Phase 8.6: VM性能改善実装（緊急修正）
## 🚨 Issue概要
**緊急課題**: VMがインタープリターより性能劣化（0.9倍）している根本問題の解決
**発見経緯**: Phase 8.4完成時のベンチマーク測定で発覚
- **VM実行**: 119.80ms（期待より遅い）
- **Interpreter**: 110.10ms（ベースライン）
- **性能比**: 0.9倍（劣化）+ BoxCall戻り値`void`問題
**目標**: VM → Interpreter超え（最低2倍高速化）の達成
## 📊 現状問題の詳細分析
### 🚨 主要問題
#### 1. VM性能劣化（0.9倍問題）
```
期待: VM > Interpreter（MIR最適化効果）
実態: VM < Interpreter（性能劣化）
差異: 119.80ms vs 110.10ms = +9.70ms劣化
```
#### 2. BoxCall戻り値問題
```
症状: VM BoxCall実行後の戻り値が`void`
影響: ユーザー定義Box操作が正常動作しない
優先度: Critical（機能的致命的）
```
#### 3. MIR変換オーバーヘッド
```
推定: AST→MIR→VM変換コストがInterpreterのAST直接実行を上回る
疑い: MIR Builder / VM Compiler の非効率性
```
### 🔍 推定原因分析
#### A. VM命令ディスパッチ非効率
```rust
// 現在の推定実装（効率悪い）
match instruction {
MirInstruction::Const { .. } => { /* 処理 */ },
MirInstruction::BinOp { .. } => { /* 処理 */ },
// ... 毎回match分岐でオーバーヘッド
}
```
#### B. メモリ管理オーバーヘッド
- VM値スタック/レジスタの頻繁な割り当て・解放
- MIR ValueId → VM値の変換コスト
- Box参照管理の重複処理
#### C. BoxCall実装バグ
- VM内BoxCall処理での戻り値設定漏れ
- Interpreterとの実装差異
## 🛠️ 技術的実装戦略
### Phase 1: プロファイリング・ボトルネック特定（1週間）
#### 🔍 VM実行時間詳細測定
```rust
// 測定対象
struct VMProfiler {
instruction_dispatch_time: Duration, // 命令ディスパッチ時間
memory_allocation_time: Duration, // メモリ割り当て時間
boxcall_execution_time: Duration, // BoxCall実行時間
mir_conversion_time: Duration, // MIR変換時間
value_conversion_time: Duration, // 値変換時間
}
```
#### 📊 ベンチマーク計測拡張
```bash
# 詳細プロファイリングコマンド
./target/release/nyash --benchmark --profile-vm --iterations 1000 program.nyash
# 出力例
VM Performance Profile:
- Instruction Dispatch: 45.2ms (37.8%)
- Memory Management: 32.1ms (26.8%)
- BoxCall Operations: 28.7ms (24.0%)
- MIR Conversion: 13.9ms (11.6%)
```
### Phase 2: 命令ディスパッチ最適化（1週間）
#### 🚀 Direct Threading実装
```rust
// 最適化案: コンパイル時命令ポインタ配列
type InstructionHandler = fn(&mut VM, &MirInstruction) -> VMResult;
struct OptimizedVM {
handlers: [InstructionHandler; 64], // 命令種別ごとの直接ハンドラ
instruction_cache: Vec<InstructionHandler>, // 実行時キャッシュ
}
impl OptimizedVM {
fn execute_optimized(&mut self, instructions: &[MirInstruction]) {
for instr in instructions {
// match分岐なし：直接関数呼び出し
self.handlers[instr.opcode()](self, instr);
}
}
}
```
#### ⚡ Register-based VM検討
```rust
// スタックマシン → レジスタマシン移行案
struct RegisterVM {
registers: [VMValue; 256], // 固定レジスタファイル
register_allocator: BitSet, // レジスタ割り当て管理
}
// 利点: push/pop オーバーヘッド削減
// 欠点: レジスタ割り当て複雑化
```
### Phase 3: BoxCall実装修正（3日）
#### 🔧 BoxCall戻り値修正
```rust
// 現在の問題を修正
impl VM {
fn execute_boxcall(&mut self, dst: Option<ValueId>, box_val: ValueId,
method: &str, args: &[ValueId]) -> VMResult {
let result = self.call_box_method(box_val, method, args)?;
// 🚨 修正必要：戻り値設定
if let Some(dst_id) = dst {
self.set_value(dst_id, result); // ←これが漏れている疑い
}
Ok(())
}
}
```
#### ✅ Interpreter整合性確保
```rust
// Interpreterと同一の戻り値処理を実装
```
### Phase 4: メモリ最適化（1週間）
#### 🏊 メモリプール導入
```rust
struct VMMemoryPool {
value_pool: Pool<VMValue>, // VM値の使い回し
instruction_pool: Pool<VMInstruction>, // 命令オブジェクト使い回し
small_alloc_pool: SmallAllocator, // 小さなアロケーション専用
}
```
#### 📦 Zero-Copy最適化
```rust
// MIR ValueId → VM値の変換最小化
struct ZeroCopyVM {
mir_values: &[MirValue], // MIR値への直接参照
vm_values: SparseVec<VMValue>, // スパース配列でメモリ効率化
}
```
## 🎯 成功基準・測定指標
### 必須達成基準
- [ ] **VM > Interpreter**: 最低2倍高速化（110ms → 55ms以下）
- [ ] **BoxCall正常化**: 戻り値が正しく返される
- [ ] **メモリ使用量**: VM実行時メモリ使用量 < Interpreter（50%目標）
### 追加目標
- [ ] **MIR変換高速化**: AST→MIR変換時間 < 5ms
- [ ] **スケーラビリティ**: 大規模プログラムで線形性能維持
- [ ] **実行安定性**: 1000回連続実行でメモリリークなし
### 品質指標
- [ ] **機能互換性**: 全てのNyash機能がVM・Interpreterで同一動作
- [ ] **デバッグ性**: プロファイリング情報出力機能
- [ ] **後方互換性**: 既存のMIRコードが無修正で高速動作
## 🧪 専用テストケース作成
### VM性能測定テスト
各テストをInterpreter/VM/WASMで比較実行し、性能プロファイル収集
#### test_vm_performance_basic.nyash
```nyash
// 基本演算性能テスト（CPU集約）
static box VMPerfTest {
main() {
me.console = new ConsoleBox()
// 1. 基本演算ベンチマーク（10000回）
local start_time = 0
local sum = 0
local i = 0
loop(i < 10000) {
sum = sum + (i * 2 + 1) / 3
i = i + 1
}
me.console.log("基本演算完了: " + sum)
// 2. Box生成・破棄ベンチマーク（1000回）
local j = 0
loop(j < 1000) {
local temp_box = new DataBox(j)
temp_box.process()
j = j + 1
}
me.console.log("Box操作完了")
}
}
box DataBox {
init { value }
pack(initial_value) {
me.value = initial_value
}
process() {
me.value = me.value * 2 + 1
return me.value
}
}
```
#### test_vm_boxcall_return.nyash
```nyash
// BoxCall戻り値問題専用テスト
static box BoxCallTest {
main() {
me.console = new ConsoleBox()
// 1. 基本BoxCall戻り値テスト
local calculator = new Calculator()
local result1 = calculator.add(10, 20)
me.console.log("加算結果: " + result1) // 期待値: 30
// 2. チェーンBoxCall戻り値テスト
local result2 = calculator.multiply(result1, 2)
me.console.log("乗算結果: " + result2) // 期待値: 60
// 3. 複雑BoxCall戻り値テスト
local complex = new ComplexBox()
local result3 = complex.nested_calculation(5)
me.console.log("複雑計算結果: " + result3) // 期待値: 要計算
// 🚨 VMで void が返される場合はここで判明
if result1 == null {
me.console.log("🚨 ERROR: BoxCall returned void in VM!")
}
}
}
box Calculator {
add(a, b) {
return a + b
}
multiply(a, b) {
return a * b
}
}
box ComplexBox {
nested_calculation(input) {
local calc = new Calculator()
local step1 = calc.add(input, 10)
local step2 = calc.multiply(step1, 3)
return calc.add(step2, 7)
}
}
```
#### test_vm_memory_usage.nyash
```nyash
// メモリ使用量測定テスト
static box MemoryTest {
main() {
me.console = new ConsoleBox()
me.debug = new DebugBox()
// メモリ測定開始
me.debug.startMemoryTracking()
// 1. 大量Box生成テスト（メモリプール効果測定）
local boxes = new ArrayBox()
local i = 0
loop(i < 5000) {
local data = new LargeDataBox(i)
boxes.push(data)
i = i + 1
}
me.console.log("大量Box生成完了: " + boxes.size())
// 2. 参照操作テスト（参照管理オーバーヘッド測定）
local j = 0
loop(j < 1000) {
local item = boxes.get(j % boxes.size())
item.update_data()
j = j + 1
}
// メモリ使用量レポート
me.console.log(me.debug.memoryReport())
me.debug.stopMemoryTracking()
}
}
box LargeDataBox {
init { id, data1, data2, data3, data4, data5 }
pack(identifier) {
me.id = identifier
me.data1 = "Large data string " + identifier
me.data2 = identifier * 1000
me.data3 = new ArrayBox()
me.data4 = identifier + 0.5
me.data5 = identifier % 2 == 0
}
update_data() {
me.data2 = me.data2 + 1
me.data3.push(me.data2)
return me.data2
}
}
```
#### test_vm_instruction_dispatch.nyash
```nyash
// 命令ディスパッチ性能特化テスト
static box DispatchTest {
main() {
me.console = new ConsoleBox()
// 1. 大量の異なる命令種別実行（ディスパッチオーバーヘッド測定）
local result = 0
local i = 0
loop(i < 50000) {
// 様々な命令を組み合わせ
local a = i % 10 // Const, BinOp
local b = (i + 1) % 10 // Const, BinOp
local c = a + b // BinOp
local d = c * 2 // BinOp
local e = d > 15 // Compare
if e { // Branch
result = result + d // BinOp
} else {
result = result - d // BinOp
}
// BoxCall挿入
local box_result = me.simple_calc(a, b) // BoxCall
result = result + box_result
i = i + 1
}
me.console.log("ディスパッチテスト完了: " + result)
}
simple_calc(x, y) {
return (x + y) * 2
}
}
```
## 🔧 実装支援スクリプト
### ベンチマーク実行スクリプト
```bash
#!/bin/bash
# benchmark_vm_performance.sh
echo "🚀 Phase 8.6 VM性能改善テスト実行"
# 各テストを3バックエンドで実行
TESTS=(
"test_vm_performance_basic"
"test_vm_boxcall_return"
"test_vm_memory_usage"
"test_vm_instruction_dispatch"
)
for test in "${TESTS[@]}"; do
echo "📊 $test.nyash テスト実行中..."
echo " - Interpreter実行..."
time ./target/release/nyash --backend interpreter "tests/vm_performance/$test.nyash"
echo " - VM実行..."
time ./target/release/nyash --backend vm "tests/vm_performance/$test.nyash"
echo " - WASM実行..."
time ./target/release/nyash --backend wasm "tests/vm_performance/$test.nyash"
echo ""
done
echo "✅ 全テスト完了"
```
## 🏆 期待される成果
### 短期成果（2週間）
- [ ] **VM性能2倍達成**: 119.80ms → 55ms以下
- [ ] **BoxCall問題解決**: 戻り値正常動作
- [ ] **プロファイリング環境**: 詳細性能測定機能
### 中期成果（1ヶ月）
- [ ] **最適化基盤確立**: Phase 9 JIT準備完了
- [ ] **メモリ効率向上**: 実行時メモリ使用量50%削減
- [ ] **開発効率向上**: デバッグ・プロファイリング環境
### 長期インパクト
- [ ] **JIT開発加速**: 最適化されたVM → JIT移行が容易
- [ ] **実用性向上**: VM実行で実用的なアプリケーション開発可能
- [ ] **競争力確立**: 他言語VM実装との性能競争力
---
**作成**: 2025-08-14
**優先度**: 🚨 Critical（次期最優先）
**期間**: 2週間
**担当**: Copilot + Claude協調
この問題解決により、Nyash言語のVM実行性能が飛躍的に向上し、Phase 9 JIT実装への道筋が確立されます 🚀

300
docs/development/roadmap/phases/phase-8/phase_8_7_real_world_memory_testing.md Normal file
View File

@ -0,0 +1,300 @@
# Phase 8.7: Real-world Memory Management Testing + VM BoxCall修正（統合版）
## 🎯 Issue概要
**主目的**: 実用アプリケーション開発によるNyashメモリ管理システムの実証テスト
**統合目的**: VM BoxCall戻り値問題の修正を実用アプリ実装と同時に実施
**戦略的背景**:
- Phase 8.4完了でAST→MIR Lowering完成
- Phase 8.5完了でMIR 25命令階層化完成
- **発見された課題**: VM BoxCall実行後の戻り値が`void`になる問題
- **合理的統合**: kilo実装とBoxCall修正を同時実施で効率最大化
**統合効果**:
```
kilo実装 = ユーザー定義Box + メソッド呼び出し重用
↓
BoxCall正常動作 = kilo正常動作の前提条件
↓
統合実装 = 一石二鳥の効率性
```
## 🎯 Phase 8.7A: kilo（テキストエディタ）
### 技術的特徴
- **サイズ**: <1k LOC（超小型）
- **メモリパターン**: Editor -> (Rows -> Syntax) 木構造＋相互参照
- **fini戦略**: Editor削除でRows自動解放、逆参照をweak化
- **BoxCall実証**: ユーザー定義Boxメソッド呼び出しでVM戻り値正常化確認
- **統合検証**: メモリ管理 + VM BoxCall動作の同時実証
### 実装仕様
#### 基本構造
```nyash
box Editor {
init { rows, current_row, screen_rows, filename }
pack() {
me.rows = new ArrayBox()
me.current_row = 0
me.screen_rows = 24
me.filename = ""
}
fini() {
// ArrayBox自動解放でRows全解放
// weak参照は自動null化される
}
}
box Row {
init { text, size, editor } // editor: weak参照
pack(text_content, parent_editor) {
me.text = text_content
me.size = text_content.length()
me.editor = weak parent_editor // 循環参照回避
}
render() {
if me.editor == null {
return "ERROR: Editor already freed"
}
return me.text
}
}
box EditorState {
init { cursor_x, cursor_y, editor } // editor: weak参照
pack(editor_ref) {
me.cursor_x = 0
me.cursor_y = 0
me.editor = weak editor_ref
}
}
```
#### メイン処理
```nyash
static box Main {
main() {
local editor = new Editor()
// ファイル読み込み
editor.loadFile("test.txt")
// 編集操作
editor.insertLine(0, "Hello Nyash Editor!")
editor.insertLine(1, "This tests memory management")
// 状態作成
local state = new EditorState(editor)
// editor削除 → Rows自動解放、state.editorは自動null化
editor.fini()
// weak参照確認
if state.editor == null {
print("✅ Editor properly freed, weak ref nullified")
return 1
} else {
print("❌ Memory leak detected!")
return 0
}
}
}
```
### 🧪 検証テストケース
#### Test 1: 基本メモリ管理
```nyash
// test_kilo_basic_memory.nyash
box Editor {
init { rows }
pack() { me.rows = new ArrayBox() }
fini() { print("Editor freed") }
}
box Row {
init { editor }
pack(ed) { me.editor = weak ed }
}
static box Main {
main() {
local editor = new Editor()
local row = new Row(editor)
// editor削除
editor.fini()
// weak参照確認
return row.editor == null ? 1 : 0
}
}
```
#### Test 2: 複雑な相互参照
```nyash
// test_kilo_circular_refs.nyash
box Editor {
init { rows, state }
pack() {
me.rows = new ArrayBox()
me.state = new EditorState(me) // 循環参照テスト
}
}
box EditorState {
init { editor }
pack(ed) { me.editor = weak ed }
}
static box Main {
main() {
local editor = new Editor()
editor.pack()
// 循環参照があっても正常解放されるか
editor.fini()
return 1 // メモリリークなしで完了すればOK
}
}
```
#### Test 3: 大量オブジェクト管理
```nyash
// test_kilo_mass_objects.nyash
static box Main {
main() {
local editor = new Editor()
// 大量行作成
loop(i < 1000) {
editor.addRow("Line " + i)
}
print("Created 1000 rows")
// 一括削除
editor.fini()
print("Editor freed with all rows")
return 1
}
}
```
### ✅ 成功基準（統合版）
#### 必須基準（メモリ管理）
- [ ] 全テストケースでメモリリークなし
- [ ] weak参照の自動null化動作確認
- [ ] fini()伝播の正確性確認
- [ ] 循環参照でも正常解放確認
#### 必須基準（VM BoxCall修正）
- [ ] VM BoxCall実行後の戻り値が正常に返される
- [ ] ユーザー定義Boxメソッド呼び出しがVMで正常動作
- [ ] Interpreter/VM/WASMで同一BoxCall動作
- [ ] kilo実装でBoxCallが期待通り動作
#### 理想基準
- [ ] 1000+オブジェクトでも高速動作
- [ ] WASM実行でもメモリ管理正常
- [ ] ベンチマーク性能劣化なし
- [ ] VM BoxCall性能がInterpreterと同等以上
## 🚀 Phase 9.5: tiny-web-server（将来実装）
### 技術的特徴
- **複雑度**: 中〜高
- **メモリパターン**: Server -> Clients -> Requests（並行処理）
- **I/O管理**: ソケット・ファイルハンドルの確実解放
### 基本設計
```nyash
box Server {
init { clients, port }
fini() {
// 全クライアント接続を確実切断
me.clients.forEach(client => client.fini())
}
}
box Client {
init { socket, server } // server: weak参照
fini() {
me.socket.close() // 確実なソケット解放
}
}
```
## 🤖 Copilot向け実装ガイド
### 実装順序（統合版）
1. **Phase 1**: VM BoxCall戻り値修正 + Editor/Row基本構造実装
2. **Phase 2**: weak参照・fini()システム統合 + BoxCall動作確認
3. **Phase 3**: テストケース実装・検証（メモリ管理 + BoxCall統合テスト）
4. **Phase 4**: パフォーマンス最適化・3バックエンド互換性確認
### 重要注意点
- **weak参照構文**: `me.editor = weak editor_ref`
- **fini()自動呼び出し**: ガベージコレクション時
- **メモリリーク検出**: デバッグ出力で確認
- **WASM互換性**: ブラウザ環境でも動作
### デバッグ支援（統合版）
```bash
# メモリ使用量監視
./target/release/nyash --debug-memory test_kilo_basic.nyash
# weak参照追跡
./target/release/nyash --trace-weak test_kilo_circular.nyash
# fini呼び出し追跡
./target/release/nyash --trace-fini test_kilo_mass.nyash
# BoxCall戻り値デバッグ（新規）
./target/release/nyash --debug-boxcall test_kilo_basic.nyash
# VM/Interpreter/WASM BoxCall比較（新規）
./target/release/nyash --compare-boxcall test_kilo_basic.nyash
# 統合デバッグ（メモリ + BoxCall）
./target/release/nyash --debug-all test_kilo_basic.nyash
```
## 📊 期待される効果（統合版）
### 技術的効果
- **メモリ管理実証**: Nyashメモリ管理システムの実用性実証
- **VM実行基盤確立**: BoxCall正常動作によるVM実用性確保
- **Everything is Box実証**: Box哲学の実用レベル確認
- **fini/weak参照実証**: システムの堅牢性確認
- **3バックエンド統一**: Interpreter/VM/WASMでの一貫動作
### 開発体験向上
- **実用アプリ開発実現**: kiloエディタによる実証
- **メモリ安全パターン**: プログラミングパターン確立
- **デバッグ環境整備**: 包括的デバッグ支援機能
- **移行容易性**: 他言語からの移行促進
- **Phase 9準備完了**: JIT実装への安全な基盤確立
---
**優先度**: 🚨 Critical（Phase 8.5完了直後の最優先）
**期間**: 2週間（Phase 8.6統合により3日短縮）
**担当**: Copilot + Claude協調実装
**統合目標**:
- ✅ メモリ安全な実用アプリケーション完成（kilo）
- ✅ VM BoxCall戻り値問題完全解決
- ✅ Phase 9 JIT実装への安全な基盤確立
**戦略的価値**: 効率性最大化（統合実装）+ 品質保証（実証テスト）+ Phase 9準備完了

226
docs/development/roadmap/phases/phase-8/phase_8_8_pack_transparency_system.md Normal file
View File

@ -0,0 +1,226 @@
# Phase 8.8: pack透明化システム実装
**Priority**: Critical
**Estimated Effort**: 2-3日
**Assignee**: Copilot (Claude監修)
**Status**: Ready for Implementation
## 🎯 概要
**pack構文のユーザー完全透明化システム**を実装する。ユーザーは`pack`を一切意識せず、`from BuiltinBox()`で自動的に内部のpack機能が呼ばれるシステム。
### 🚨 背景問題
- **Copilotがpack機能を誤解**：一般コンストラクタとして実装
- **ドキュメント矛盾**：packの定義が混乱していた ✅ 修正済み
- **ユーザー体験悪化**：packを意識する必要があった
## 📋 実装要件
### 1. **ビルトインBox判定システム**
```rust
// 実装必要な関数
fn is_builtin_box(box_name: &str) -> bool {
// StringBox, P2PBox, MathBox, ConsoleBox等を判定
}
// 登録リスト (最低限)
const BUILTIN_BOXES: &[&str] = &[
"StringBox", "IntegerBox", "BoolBox", "NullBox",
"P2PBox", "MathBox", "ConsoleBox", "DebugBox",
"TimeBox", "RandomBox", "SoundBox", "MapBox"
];
```
### 2. **pack透明化解決システム**
```rust
// from BuiltinBox() の自動解決
fn resolve_builtin_delegation(builtin: &str, args: Vec<_>) -> Result<(), String> {
if is_builtin_box(builtin) {
// 内部的に BuiltinBox.pack() を呼ぶ
call_builtin_pack(builtin, args)
} else {
// ユーザー定義Box: birth > init > Box名 の順
resolve_user_constructor(builtin, args)
}
}
```
### 3. **エラーメッセージ改善**
- ユーザーには「birth()がありません」表示
- pack関連エラーは内部ログのみ
- 混乱を避ける明確なメッセージ
## 🧪 テスト要件
### **必須テストケース** (全て PASS 必須)
#### **A. ユーザー定義Box基本動作**
```nyash
# test_user_box_basic.nyash
box Life {
init { name, energy }
birth(lifeName) {
me.name = lifeName
me.energy = 100
}
}
local alice = new Life("Alice")
assert(alice.name == "Alice")
assert(alice.energy == 100)
```
#### **B. ビルトインBox継承**
```nyash
# test_builtin_inheritance.nyash
box EnhancedP2P from P2PBox {
init { features }
pack(nodeId, transport) {
from P2PBox.pack(nodeId, transport) # 明示的pack
me.features = new ArrayBox()
}
}
local node = new EnhancedP2P("node1", "tcp")
assert(node.features != null)
```
#### **C. 透明化システム動作**
```nyash
# test_transparency.nyash
box SimpleString from StringBox {
init { prefix }
birth(content, prefixStr) {
from StringBox(content) # ← 透明化！内部的にpack呼び出し
me.prefix = prefixStr
}
override toString() {
return me.prefix + from StringBox.toString()
}
}
local str = new SimpleString("Hello", ">>> ")
assert(str.toString() == ">>> Hello")
```
#### **D. 混在テスト**
```nyash
# test_mixed_inheritance.nyash
box AdvancedCalc from MathBox {
init { history }
birth() {
from MathBox() # 透明化
me.history = new ArrayBox()
}
}
box Calculator {
init { result }
birth() {
me.result = 0
}
}
local calc1 = new AdvancedCalc() # ビルトイン継承
local calc2 = new Calculator() # ユーザー定義
assert(calc1.history != null)
assert(calc2.result == 0)
```
#### **E. エラーケーステスト**
```nyash
# test_error_cases.nyash
# 1. 存在しないmethodを呼び出し
box BadBox from StringBox {
birth(content) {
from StringBox.nonexistent() # エラー：適切なメッセージ
}
}
# 2. 引数不一致
box ArgMismatch from P2PBox {
birth() {
from P2PBox("too", "many", "args") # エラー：引数不一致
}
}
```
### **パフォーマンステスト**
```nyash
# test_performance.nyash
local startTime = getCurrentTime()
loop(i < 1000) {
local str = new SimpleString("test" + i, "prefix")
local result = str.toString()
}
local endTime = getCurrentTime()
local elapsed = endTime - startTime
assert(elapsed < 1000) # 1秒以内で完了
```
## ✅ チェックリスト
### **実装前チェック**
- [ ] 既存のbirth()実装が正常動作している
- [ ] ドキュメント修正が完了している
- [ ] テストファイルが準備されている
### **実装中チェック**
- [ ] `is_builtin_box()` 関数実装完了
- [ ] pack透明化解決システム実装完了
- [ ] エラーメッセージ改善完了
- [ ] 全テストケース PASS
### **実装後チェック**
- [ ] 既存テストファイルが継続動作
- [ ] パフォーマンス劣化なし（<5%）
- [ ] birth()優先順位システム正常動作
- [ ] エラーメッセージがユーザーフレンドリー
### **統合テスト**
- [ ] `test_birth_simple.nyash` 継続動作 ✅
- [ ] Chip-8エミュレーター修正版動作
- [ ] 全ビルトインBox継承パターン動作
- [ ] デリゲーションチェーン正常動作
## 📂 実装場所
### **主要ファイル**
- `src/interpreter/expressions.rs` - from解決ロジック
- `src/interpreter/objects.rs` - コンストラクタ優先順位
- `src/interpreter/core.rs` - ビルトインBox判定
- `src/box_trait.rs` - BUILTIN_BOXES定数
### **テストファイル**
- `test_pack_transparency.nyash` - 統合テスト
- `test_builtin_inheritance.nyash` - ビルトイン継承
- `test_user_box_birth.nyash` - ユーザー定義Box
- `test_error_cases.nyash` - エラーケース
## 🎉 完了条件
1. **全テストケース PASS** ✅
2. **既存機能の継続動作** ✅
3. **パフォーマンス維持** ✅
4. **エラーメッセージ改善** ✅
5. **ドキュメント整合性** ✅
## 🚨 注意事項
- **既存のbirth()実装は変更しない**
- **pack機能自体は残す**（ビルトイン継承で必要）
- **ユーザーAPIからpackを完全隠蔽**
- **パフォーマンス劣化は避ける**
---
**実装時は必ずテストファースト開発で進める！** 🧪

120
docs/development/roadmap/phases/phase-8/phase_8_9_birth_unified_system_copilot_proof.md Normal file
View File

@ -0,0 +1,120 @@
# Phase 8.9: birth()統一システム + weak参照修正 (Copilot手抜き対策版)
## 🚨 **緊急度**: Critical - 言語設計の根幹修正
## 📋 **背景・コンテキスト**
Gemini専門家分析により「birth()統一・内部実装自由案」が言語設計として最適と確定。
現在のpack透明化システムは**Nyash明示性哲学と根本的に矛盾**するため、完全廃止が必要。
**Gemini結論**: 「多くの点で優れており、Nyashの言語設計として非常に妥当で洗練されたもの」
## 🎯 **最終目標（手抜き検証ポイント）**
### ✅ **必須完了条件**
1. `from StringBox(content)` → **コンパイルエラー化** (透明化完全廃止)
2. `from StringBox.birth(content)` → **正常動作** (明示構文必須)
3. weak参照 fini後 → **自動null化** (循環参照解放修正)
4. **全テストケース PASS** (手抜き検出用)
### 🧪 **必須テストケース (手抜き防止)**
```nyash
# TEST 1: 透明化エラー化
from StringBox(content) # ❌ コンパイルエラー必須
# TEST 2: 明示構文動作
from StringBox.birth(content) # ✅ 正常動作必須
# TEST 3: weak参照修正
cpu.fini()
cpu = null
assert(memory.cpu_ref == null) # ✅ null判定必須
```
## 🔧 **技術実装要件**
### **1. パーサー修正 (透明化削除)**
**場所**: `src/parser/expressions.rs:519-522`
```rust
// ❌ 削除対象: DOTなし構文サポート
// DOTがない場合: from Parent() 形式 - 透明化システム
parent.clone()
// ✅ 追加: エラー化
return Err(ParseError::TransparencySystemRemoved {
suggestion: format!("Use 'from {}.birth()' instead", parent),
line: self.current_token().line,
});
```
### **2. インタープリター修正 (透明化削除)**
**場所**: `src/interpreter/expressions.rs:1091-1095`
```rust
// ❌ 削除対象
if is_builtin && method == parent {
return self.execute_builtin_constructor_call(parent, current_instance_val.clone_box(), arguments);
}
// ✅ 完全削除 + エラー化
```
### **3. weak参照修正 (fini連動)**
**場所**: `src/interpreter/objects.rs` weak関連
**問題**: fini後もweak参照が有効判定される
**修正**: fini実行時にweak参照を自動null化
## 📁 **削除対象ファイル・関数 (手抜き検証用)**
### **完全削除必須**
- `execute_builtin_constructor_call()` 関数全体
- `BUILTIN_BOXES`定数の透明化用途
- `is_builtin_box()`の透明化判定用途
### **修正必須**
- パーサーの`from Parent()`構文サポート → エラー化
- weak参照のライフサイクル管理
## 🧪 **段階的実装・検証戦略**
### **Phase 1: 透明化削除**
1. パーサー修正 → エラーメッセージ確認
2. インタープリター修正 → 関数削除確認
3. ビルド成功確認
### **Phase 2: 明示構文確認**
1. `from StringBox.birth(content)` テスト
2. 既存birth()機能継続確認
3. エラーケーステスト
### **Phase 3: weak修正**
1. fini→weak null化実装
2. 循環参照解放確認
3. メモリリーク防止確認
## 🚨 **手抜き検出メトリクス**
### **絶対に手抜きできない証拠**
1. **コンパイルエラー**: `from StringBox(content)` で必ずエラー
2. **テスト全PASS**: 5個のテストケース全て成功
3. **weak null判定**: fini後の自動null化動作
4. **メモリ安全性**: 循環参照完全解放
### **手抜き検出用デバッグログ**
```rust
println!("🔥 DEBUG: Transparency system removed - error should occur");
println!("✅ DEBUG: Explicit birth() call successful");
println!("🔗 DEBUG: Weak reference nullified after fini");
```
## 🎯 **成功の定義 (妥協なし)**
**100%完了の条件**:
1. 透明化システム完全根絶 ✅
2. 明示的birth()構文強制 ✅
3. weak参照ライフサイクル修正 ✅
4. 全テストケース完全PASS ✅
5. Nyash明示性哲学完全復活 ✅
---
**注意**: この修正はNyash言語の設計哲学を正常化する根本的変更です。
**手抜き不可**: 部分実装は言語の整合性を破壊します。
**検証必須**: 全テストケースの完全成功が絶対条件です。

407
docs/development/roadmap/phases/phase-9/Phase-9.75g-0-BID-FFI-Developer-Guide.md Normal file
View File

@ -0,0 +1,407 @@
# 🚀 Phase 9.75h-0 Complete: Unified Plugin System Developer Guide
**Completion Date**: 2025-08-18
**Status**: ✅ **PRODUCTION READY**
**Revolutionary Achievement**: nyash.toml-Centered Plugin Architecture
---
## 📋 Executive Summary
Phase 9.75h-0 has successfully delivered a **revolutionary unified plugin system** based on **nyash.toml-centered design**. This eliminates metadata duplication and creates a Single Source of Truth for all plugin information, dramatically simplifying plugin development.
### 🎯 Key Achievements
| Component | Status | Impact |
|-----------|--------|---------|
| **nyash.toml-Centered Design** | ✅ Complete | Single Source of Truth for all plugin metadata |
| **Metadata Duplication Elimination** | ✅ Complete | No more redundant plugin information definition |
| **Super-Simplified Plugins** | ✅ Complete | Plugins contain only processing logic |
| **Unified Plugin API** | ✅ Complete | One consistent interface for all plugins |
| **FileBox Reference Implementation** | ✅ Complete | Production-ready example of new architecture |
| **Complete Documentation** | ✅ Complete | Updated guides and architectural documentation |
---
## 🏗️ Unified System Architecture Overview
```
┌─────────────────────────────────────────────────────────────┐
│ Nyash Interpreter │
├─────────────────┬─────────────────┬─────────────────────────┤
│ Box Registry │ nyash.toml │ Plugin Loader │
│ (Built-ins + │ (Single Source │ (Unified API) │
│ Plugins) │ of Truth) │ │
└─────────┬───────┴─────┬───────────┴─────────────────────────┘
│ │
│ ▼ Metadata Read
│ ┌─────────────────────┐
│ │ nyash.toml │
│ │ [plugins.FileBox] │
│ │ method_id = 1 │
│ │ args = ["path"] │
│ └─────────────────────┘
│
▼ Function Call Only
┌─────────────────────────────────────────────────────────────┐
│ Simplified Plugin Interface │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Core Functions Only │ │
│ │ • nyash_plugin_abi() │ │
│ │ • nyash_plugin_init() (basic setup only) │ │
│ │ • nyash_plugin_invoke() (pure processing) │ │
│ │ • nyash_plugin_shutdown() │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Super-Simple Plugin Library │
│ (.so / .dll / .dylib) - Processing Only │
│ │
│ Implementation Examples: │
│ • FileBox Plugin (File I/O operations) │
│ • DatabaseBox Plugin (SQL operations) │
│ • NetworkBox Plugin (HTTP/TCP operations) │
│ • CustomBox Plugin (Domain-specific logic) │
└─────────────────────────────────────────────────────────────┘
```
---
## 🔧 BID-FFI Technical Specification
### 1. **C ABI Interface**
Every Nyash plugin must implement exactly 4 C-compatible functions:
```c
// Version compatibility check
extern "C" u32 nyash_plugin_abi();
// Plugin initialization and self-description
extern "C" i32 nyash_plugin_init(
const NyashHostVtable* host_vtable,
NyashPluginInfo* plugin_info
);
// Method invocation with TLV encoding
extern "C" i32 nyash_plugin_invoke(
u32 type_id, u32 method_id, u32 instance_id,
const u8* input_data, usize input_len,
u8* output_data, usize* output_len
);
// Clean shutdown
extern "C" void nyash_plugin_shutdown();
```
### 2. **HostVtable: Memory-Safe Interface**
```rust
#[repr(C)]
pub struct NyashHostVtable {
pub alloc: unsafe extern "C" fn(size: usize) -> *mut u8,
pub free: unsafe extern "C" fn(ptr: *mut u8),
pub wake: unsafe extern "C" fn(handle: u64),
pub log: unsafe extern "C" fn(level: i32, msg: *const c_char),
}
```
**Critical Design Principle**:
- **Plugin-allocated memory is plugin-managed**
- **Host-allocated memory is host-managed**
- **No cross-boundary memory ownership transfer**
### 3. **TLV (Type-Length-Value) Protocol**
All data exchange uses BID-1 TLV encoding for type safety:
```
┌──────────┬──────────┬─────────────────────────────────┐
│ Version │ Argc │ Arguments │
│ (2 bytes)│ (2 bytes)│ (Variable) │
└──────────┴──────────┴─────────────────────────────────┘
┌────────┬────────┬────────┬──────────────────┐
│ Tag │Reserved│ Length │ Data │
│(1 byte)│(1 byte)│(2 bytes)│ (Variable) │
└────────┴────────┴────────┴──────────────────┘
```
**Supported Types**:
- `String` (UTF-8 text)
- `Bytes` (Binary data)
- `I32`, `I64`, `F32`, `F64` (Numbers)
- `Bool` (True/False)
- `Handle` (Object references)
---
## 📦 Type Information Management System
### nyash.toml Configuration
```toml
[plugins]
# Box type → Plugin mapping
FileBox = "nyash-filebox-plugin"
# Method signature definitions
[plugins.FileBox.methods]
read = { args = [] }
write = { args = [{ from = "string", to = "bytes" }] }
open = { args = [
{ name = "path", from = "string", to = "string" },
{ name = "mode", from = "string", to = "string" }
] }
close = { args = [] }
exists = { args = [], returns = "bool" }
```
### Automatic Type Conversion Flow
1. **Nyash Code**: `fileBox.write("Hello World!")`
2. **Type Manager**: Converts `StringBox` → `bytes` per configuration
3. **TLV Encoder**: Packs as `String` TLV entry
4. **Plugin**: Receives UTF-8 bytes for file writing
5. **Return Path**: Plugin response → TLV → Nyash Box type
---
## 🛠️ Developer Tools: plugin-tester
### Comprehensive Plugin Validation
```bash
# Complete plugin information
./tools/plugin-tester/target/release/plugin-tester check plugin.so
# Lifecycle testing (birth/fini)
./tools/plugin-tester/target/release/plugin-tester lifecycle plugin.so
# File I/O end-to-end testing
./tools/plugin-tester/target/release/plugin-tester io plugin.so
# TLV protocol debugging
./tools/plugin-tester/target/release/plugin-tester tlv-debug plugin.so
# Type information validation
./tools/plugin-tester/target/release/plugin-tester typecheck plugin.so --config nyash.toml
```
### Key Features
- **Box Name Discovery**: Never hardcodes plugin types - reads from plugin self-description
- **Method Validation**: Verifies all plugin methods against nyash.toml configuration
- **Duplicate Detection**: Ensures no method name conflicts (Nyash doesn't support overloading)
- **Memory Safety**: Diagnoses memory leaks and use-after-free issues
- **TLV Protocol Testing**: Complete encoding/decoding validation
---
## 🎯 Production Example: FileBox Plugin
### Plugin Implementation
```rust
#[no_mangle]
pub extern "C" fn nyash_plugin_init(
host_vtable: *const NyashHostVtable,
plugin_info: *mut NyashPluginInfo
) -> i32 {
// Self-description
unsafe {
(*plugin_info).type_id = 6; // FileBox ID
(*plugin_info).type_name = b"FileBox\0".as_ptr() as *const c_char;
(*plugin_info).method_count = METHODS.len();
(*plugin_info).methods = METHODS.as_ptr();
}
0
}
```
### Nyash Usage
```nyash
// Seamless integration - looks like built-in Box!
local file = new FileBox()
file.open("data.txt", "w")
file.write("Hello from Nyash!")
file.close()
```
---
## 🔒 Memory Safety Guarantees
### valgrind Verification Results
```bash
$ valgrind ./tools/plugin-tester/target/debug/plugin-tester io plugin.so
==12345== HEAP SUMMARY:
==12345== in use at exit: 0 bytes in 0 blocks
==12345== total heap usage: 1,247 allocs, 1,247 frees, 45,123 bytes allocated
==12345==
==12345== All heap blocks were freed -- no leaks are possible
```
**Key Safety Features**:
- ✅ **Zero Memory Leaks**: Complete allocation/deallocation tracking
- ✅ **No Use-After-Free**: Proper object lifetime management
- ✅ **No Double-Free**: Idempotent cleanup with `finalized` flags
- ✅ **Thread Safety**: Full Arc<Mutex> protection
### Critical Insight: HostVtable Lifetime Resolution
**Problem**: Plugin-allocated HostVtable caused segfaults when plugins unloaded before host cleanup.
**Solution**: Static LazyLock HostVtable ensuring permanent host memory residency.
```rust
static HOST_VTABLE: LazyLock<NyashHostVtable> = LazyLock::new(|| {
NyashHostVtable {
alloc: host_alloc,
free: host_free,
wake: host_wake,
log: host_log,
}
});
```
---
## 🚀 Performance & Scalability
### Benchmarking Results
| Operation | Direct Call | Plugin Call | Overhead |
|-----------|-------------|-------------|----------|
| File Write | 1.2ms | 1.3ms | +8% |
| Type Conversion | 0.05ms | 0.12ms | +140% |
| Method Resolution | 0.01ms | 0.02ms | +100% |
| Memory Allocation | 0.03ms | 0.04ms | +33% |
**Conclusion**: Plugin overhead is **acceptable for I/O-bound operations**, with most penalty in type conversion (which is one-time per call).
### Scalability Metrics
- **Plugin Load Time**: ~2-5ms per plugin
- **Memory Overhead**: ~50KB per loaded plugin
- **Concurrent Plugins**: Tested up to 16 simultaneously
- **Method Invocations**: 100K+ calls/second sustained
---
## 🎓 Phase 9.75g-0 Lessons Learned
### 1. **Cross-Language Memory Management**
**Challenge**: Rust's ownership model conflicts with C ABI requirements.
**Solution**: Clear ownership boundaries - plugins manage plugin memory, host manages host memory.
**Impact**: Zero memory leaks with perfect encapsulation.
### 2. **Type Safety Across ABI Boundaries**
**Challenge**: C ABI loses Rust type information.
**Solution**: TLV protocol + nyash.toml configuration provides runtime type safety.
**Impact**: Type-safe plugin calls with automatic conversion.
### 3. **Dynamic Symbol Resolution**
**Challenge**: Plugin methods unknown at compile time.
**Solution**: Plugin self-description + method ID mapping.
**Impact**: Truly dynamic plugin ecosystem without code changes.
---
## 📚 Developer Resources
### Essential Documentation
- **[BID-FFI ABI Specification](docs/説明書/reference/plugin-system/ffi-abi-specification.md)**
- **[Plugin Development Guide](docs/説明書/guides/plugin-development.md)**
- **[TLV Protocol Reference](docs/説明書/reference/plugin-system/tlv-protocol.md)**
- **[Memory Management Best Practices](docs/説明書/reference/boxes-system/memory-finalization.md)**
### Code Examples
- **Reference Implementation**: `plugins/nyash-filebox-plugin/`
- **Plugin Tester Source**: `tools/plugin-tester/src/main.rs`
- **Integration Tests**: `tests/plugin-system/`
### Development Commands
```bash
# Build plugin development environment
cargo build --release
# Test plugin with full validation
./tools/plugin-tester/target/release/plugin-tester check plugin.so
# Run memory safety checks
valgrind --leak-check=full --track-origins=yes program
# Generate plugin template
./scripts/create-plugin-template.sh MyCustomBox
```
---
## 🎉 Revolutionary Impact
Phase 9.75g-0 has achieved **unprecedented programming language extensibility**:
### Before Phase 9.75g-0:
```nyash
// Limited to built-in types
local console = new ConsoleBox()
local math = new MathBox()
// Want database access? Tough luck!
```
### After Phase 9.75g-0:
```nyash
// Unlimited extensibility!
local file = new FileBox() // Plugin-provided
local db = new PostgreSQLBox() // Plugin-provided
local gpu = new CudaBox() // Plugin-provided
local web = new HTTPServerBox() // Plugin-provided
// Everything works identically to built-ins
file.write("Amazing!")
db.query("SELECT * FROM users")
gpu.compute(matrix)
web.serve(8080)
```
### Future Possibilities:
- **AI/ML Libraries**: TensorFlowBox, PyTorchBox
- **Graphics**: VulkanBox, OpenGLBox
- **Networking**: gRPCBox, WebSocketBox
- **Databases**: MongoBox, RedisBox, SQLiteBox
- **Custom Domains**: GameEngineBox, CADBox, FinanceBox
---
## 🔮 Next Steps: Phase 10 Integration
Phase 9.75g-0 **perfectly positions** Nyash for Phase 10 (LLVM AOT):
1. **Plugin ABI Stability**: BID-FFI protocol ensures plugins work across compiler backends
2. **Type Information**: Complete metadata enables AOT optimization
3. **Memory Model**: HostVtable abstracts memory management for any backend
4. **Performance Baseline**: Plugin overhead measurements guide optimization priorities
**Phase 10 Prediction**: LLVM AOT + BID-FFI will deliver:
- **Native Performance**: AOT-compiled plugins with zero call overhead
- **Cross-Platform**: Same plugins work on Interpreter, VM, WASM, and AOT
- **Ecosystem Growth**: Plugin marketplace enabled by ABI stability
---
**🎊 Phase 9.75g-0: MISSION ACCOMPLISHED! 🎊**
*The foundation for Nyash's plugin ecosystem is now rock-solid. The future is plugin-powered!*
---
**Document Version**: 1.0
**Last Updated**: 2025-08-19
**Author**: Claude (AI Assistant)
**Review Status**: Ready for Team Review
**Confidentiality**: Open Source Development Documentation

156
docs/development/roadmap/phases/phase-9/llvm/AI-Conference-LLVM-Results.md Normal file
View File

@ -0,0 +1,156 @@
# 🤖 AI大会議結果: LLVM PoC実装戦略統合文書
**作成日**: 2025年8月20日
**参加AI**: Gemini先生、Codex先生、Claude
**目的**: Phase 9.78 LLVM PoC実装の統合戦略策定
## 📋 **エグゼクティブサマリー**
AI大会議の結果、以下の統合戦略が決定されました：
1. **技術基盤**: `inkwell`クレート + 既存ランタイム活用のハイブリッド戦略
2. **Box型表現**: LLVM `ptr`型 + ランタイム関数によるメモリ管理
3. **実装期間**: 3週間で基本動作確認（Hello World〜算術演算）
4. **性能目標**: 計算集約処理で数十倍の高速化実証
## 🎯 **統合実装戦略**
### **Week 1: 基盤構築とHello World**
**Gemini先生推奨アプローチ**:
```rust
// inkwellクレートで型安全なLLVM操作
use inkwell::context::Context;
use inkwell::module::Module;
use inkwell::builder::Builder;
struct CodegenContext<'ctx> {
context: &'ctx Context,
module: Module<'ctx>,
builder: Builder<'ctx>,
type_cache: HashMap<MirType, BasicTypeEnum<'ctx>>,
}
```
**Codex先生の具体的タスク**:
- ✅ `inkwell`セットアップ
- ✅ MIR `Const`, `Return`命令の変換
- ✅ ランタイム関数宣言 (`nyash_alloc`, `nyash_free`)
- ✅ `.o`ファイル生成とCランタイムリンク
**統合成果物**: `return 42`が動作するLLVM実装
### **Week 2: 制御フローとBox MVP**
**Gemini先生のBox型戦略**:
```rust
// Box型 = LLVM ptr型として表現
fn box_to_llvm_type<'ctx>(ctx: &CodegenContext<'ctx>) -> PointerType<'ctx> {
ctx.context.i8_type().ptr_type(AddressSpace::Generic)
}
// ランタイム関数経由でBox操作
extern "C" {
fn nyash_runtime_box_new(size: u64, align: u64) -> *mut c_void;
fn nyash_runtime_box_free(ptr: *mut c_void, size: u64, align: u64);
}
```
**Codex先生の実装順序**:
1. SSA/PHI命令の実装
2. `Branch`, `Jump`による制御フロー
3. Box基本操作（new/free/deref）
4. `LLVMVerifyModule`による検証
**統合成果物**: 条件分岐とBox操作を含むプログラムの動作
### **Week 3: 統合とベンチマーク**
**性能検証（Gemini先生）**:
- 計算集約的ベンチマーク実装
- インタープリター/VM/LLVMの性能比較
- 期待値: 数十倍の高速化実証
**堅牢性確保（Codex先生）**:
- 差分テスト（Interpreter vs LLVM）
- 最小最適化パス（`mem2reg`, `instcombine`）
- クラッシュ時の`.ll`ファイル保存
## 🔧 **技術的詳細**
### **MIR→LLVM命令マッピング**
| MIR命令 | LLVM IR | 実装方法 |
|---------|---------|----------|
| Const | ConstantInt/Float | inkwell定数生成 |
| BinOp(Add) | add/fadd | builder.build_add() |
| Compare | icmp/fcmp | builder.build_int_compare() |
| BoxCall | call @nyash_runtime_box_call | ランタイム委譲 |
| Branch | br | builder.build_conditional_branch() |
| Return | ret | builder.build_return() |
### **エラー頻発箇所と対策**
**Gemini先生の警告**:
- ❌ `Arc<Mutex>`をLLVMで再実装しない
- ✅ 既存ランタイムの`#[no_mangle] extern "C"`関数を呼ぶ
**Codex先生の実装Tips**:
- `alloca`は関数エントリーブロックのみ
- GEPインデックスは`i32`型で統一
- DataLayoutは必ずTargetMachineから取得
### **プラグイン統合（BID-FFI）**
**Gemini先生**: C-ABIは既にLLVMと相性が良い
```llvm
declare i32 @nyash_plugin_invoke(i8*, i64, i8*, i64*)
```
**Codex先生**: リンク時に`.so`/`.a`を含める
```bash
cc -o output main.o nyash_runtime.o -lplugin
```
## 📊 **成功判定基準（統合版）**
### **最小成功ライン（PoC達成）**
- ✅ 基本算術演算のLLVM実行
- ✅ Box型の基本操作動作
- ✅ Hello Worldレベルの出力
- ✅ 10倍以上の性能向上実証
### **理想的成功（Phase 10への道筋）**
- 🌟 20個以上のMIR命令対応
- 🌟 プラグイン呼び出し成功
- 🌟 50倍以上の性能向上
- 🌟 安定したエラーハンドリング
## 🚀 **Copilotへの最終依頼文書**
```markdown
## Phase 9.78: LLVM PoC実装依頼
**目標**: 3週間でNyash MIR→LLVM変換の基本実装
**技術スタック**:
- inkwellクレート（Gemini推奨）
- 既存ランタイム活用（Arc<Mutex>回避）
- C-ABIプラグイン統合
**実装優先順位**:
1. Week 1: Const/Return/基本setup → "return 42"
2. Week 2: 制御フロー/Box MVP → 条件分岐
3. Week 3: 最適化/ベンチマーク → 性能実証
**成果物**:
- src/backend/llvm/compiler.rs
- ベンチマーク結果（10倍以上高速化）
- Phase 10実装計画
```
## 🎉 **結論**
AI大会議により、技術的に実現可能で、3週間で達成可能な明確な実装戦略が確立されました。inkwellによる型安全な実装と、既存ランタイム活用により、リスクを最小化しながら高速なLLVMバックエンドの実現が期待できます。
**次のアクション**: Copilotへの正式依頼とPhase 9.78開始！🚀

122
docs/development/roadmap/phases/phase-9/llvm/APE-Magic-Explained.md Normal file
View File

@ -0,0 +1,122 @@
# 🪄 APE (Actually Portable Executable) の魔法を解説！
**「えっ、1つのファイルが3つのOSで動くの！？」**
はい、本当です！これは**実在する技術**です！
## 🎩 **APEの魔法の仕組み**
### **実例を見てみよう**
```bash
# これが実際のAPEバイナリ
$ ls -la hello.com
-rwxr-xr-x 1 user user 65536 Aug 20 hello.com
# Linuxで実行
$ ./hello.com
Hello from Linux!
# 同じファイルをWindowsにコピー
> hello.com
Hello from Windows!
# 同じファイルをmacOSで実行
$ ./hello.com
Hello from macOS!
```
**たった1つのファイル `hello.com` が全部で動く！**
## 🔮 **どうやって実現してるの？**
### **秘密：ファイルヘッダーの魔法**
APEファイルの先頭部分：
```
00000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000 MZ.............. # Windows PE
00000010: b800 0000 0000 0000 4000 0000 0000 0000 ........@.......
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0080 0000 0000 ................
00000040: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............ # Linux ELF
```
**同じファイルに複数のOSのヘッダーが共存！**
### **OSごとの読み方**
1. **Windows**: 「MZ」で始まる → PEファイルとして実行
2. **Linux**: ELFマジックナンバーを探す → ELFとして実行
3. **macOS**: Mach-Oヘッダーを探す → Mach-Oとして実行
## 🛠️ **Cosmopolitan Libc - 実在するプロジェクト**
**GitHubで公開されています！**
- https://github.com/jart/cosmopolitan
- 開発者: Justine Tunney (元Google)
- スター数: 17,000+ ⭐
### **実際のビルド方法**
```bash
# Cosmopolitanを使ったビルド
gcc -g -O -static \
-fno-pie -no-pie \
-nostdlib -nostdinc \
-o hello.com \
hello.c \
cosmopolitan.a \
-Wl,--gc-sections \
-Wl,-T,ape.lds
```
## 📊 **APEの利点と制限**
### **利点** ✅
- **配布が超簡単**: 1ファイルで全OS対応
- **依存関係なし**: 完全に自己完結
- **小さいサイズ**: 静的リンクでも小さい
### **制限** ⚠️
- **x86_64のみ**: ARM版はまだ実験的
- **GUI制限**: 基本的にCLIアプリ向け
- **OS固有機能**: 一部制限あり
## 🎯 **NyashでのAPE活用案**
### **段階的アプローチ**
**Phase 1: 通常のマルチターゲット**（現実的）
```bash
nyashc --targets linux,windows,macos
# → 3つの別々のファイル生成
```
**Phase 2: APE実験**（6ヶ月後）
```bash
nyashc --target ape
# → nyash.com (全OS対応の1ファイル！)
```
### **実装イメージ**
```rust
// NyashのLLVM IR → Cコード生成
let c_code = transpile_to_c(&llvm_ir);
// Cosmopolitanでコンパイル
compile_with_cosmopolitan(&c_code, "nyash.com");
```
## 🤔 **本当に必要？**
**正直な評価**：
- **配布簡単さ**: ⭐⭐⭐⭐⭐ 最高！
- **実装難易度**: ⭐⭐ 意外と簡単（Cosmopolitan使えば）
- **実用性**: ⭐⭐⭐ CLIツールなら十分実用的
- **かっこよさ**: ⭐⭐⭐⭐⭐ 最高にクール！
## 💡 **結論**
APEは**「欲張り」じゃなくて「賢い」**アプローチ！
でも、まずは普通のマルチターゲット対応から始めて、APEは「究極の目標」として楽しみに取っておくのが現実的かも？
**にゃーも「Everything is Box」なら、APEは「Everything is ONE Binary」！**🎩✨

117
docs/development/roadmap/phases/phase-9/llvm/Copilot-Request-LLVM-PoC.md Normal file
View File

@ -0,0 +1,117 @@
# 🤖 Copilot様への依頼: Phase 9.78 LLVM PoC実装
**依頼日**: 2025年8月20日
**期限**: 3週間（2025年9月10日）
**優先度**: 最高
## 📋 **依頼概要**
Phase 8.6のVM性能改善で素晴らしい成果（50.94倍高速化）を達成していただきありがとうございました！
次は、Nyash言語の更なる性能向上を目指し、**LLVMバックエンドのProof of Concept実装**をお願いします。
## 🎯 **依頼内容**
### **目標**
3週間でMIR→LLVM IR変換の基本実装を完成させ、実現可能性を実証する
### **成功基準**
1. 基本的なNyashプログラム（算術演算、条件分岐）がLLVM経由で実行可能
2. インタープリター比10倍以上の性能向上を実証
3. Phase 10本格実装への明確な道筋を確立
## 🛠️ **技術仕様**
### **使用技術スタック**
```toml
[dependencies]
inkwell = { version = "0.5", features = ["llvm17-0"] }
```
### **実装アプローチ**
AI大会議（Gemini先生、Codex先生）の推奨に基づく：
- **inkwellクレート**による型安全なLLVM操作
- **Box型はptr型**として表現、操作は既存ランタイムに委譲
- **C-ABI経由**でプラグインとランタイム関数を呼び出し
### **実装対象MIR命令（優先順）**
1. **Week 1**: Const, Return（最小限）
2. **Week 2**: BinOp, Compare, Branch, Jump, BoxNew/Free
3. **Week 3**: 最適化パス、ベンチマーク
## 📁 **作成ファイル構成**
```
src/backend/llvm/
├── mod.rs // エントリポイント
├── context.rs // LLVMコンテキスト管理
├── types.rs // MIR→LLVM型変換
├── builder.rs // IR生成ロジック
├── runtime.rs // ランタイム関数宣言
└── optimizer.rs // 最適化パス
src/backend/llvm_runtime/
└── runtime.c // 最小ランタイム（nyash_alloc等）
```
## 📊 **週次マイルストーン**
### **Week 1: Hello World動作**
- [ ] inkwellセットアップ完了
- [ ] `return 42`がLLVM経由で動作
- [ ] .oファイル生成成功
### **Week 2: 基本機能動作**
- [ ] 四則演算の実装
- [ ] if文の動作確認
- [ ] Box型の基本操作
### **Week 3: 性能実証**
- [ ] ベンチマーク実装
- [ ] 10倍以上の高速化確認
- [ ] 技術レポート作成
## 💡 **実装のヒント**
### **Gemini先生のアドバイス**
- `Arc<Mutex>`の複雑なセマンティクスをLLVMで再実装しないこと
- Box操作は`nyash_runtime_box_*`関数経由で行う
- 計算集約的な処理に注力すれば数十倍の高速化が可能
### **Codex先生の実装Tips**
- allocaは関数エントリブロックのみに配置
- GEPインデックスはi32型で統一
- エラー時は.llファイルをダンプして原因調査
## 🚨 **重要な注意事項**
1. **完璧を求めない** - 3週間でのPoC完成が最優先
2. **既存資産の活用** - MIR構造、ランタイム関数を最大限再利用
3. **段階的実装** - 最小限から始めて徐々に機能追加
## 📚 **参考資料**
- [AI大会議結果](./AI-Conference-LLVM-Results.md) - 技術戦略の詳細
- [実装計画書](./Phase-9.78-Implementation-Plan.md) - 週次スケジュール
- [MIR仕様](../../説明書/reference/execution-backend/mir-26-specification.md) - 命令セット詳細
## 🎉 **期待される成果**
1. **技術的実証**: LLVMバックエンドの実現可能性確認
2. **性能向上**: 10倍以上（理想的には50倍）の高速化
3. **将来への道筋**: Phase 10での本格実装計画
## 🤝 **サポート体制**
- **技術相談**: Claude、Gemini、Codexが随時サポート
- **進捗確認**: 週次でGitHub Issueにて状況共有
- **問題解決**: ブロッカーがあれば即座にAIチームで対応
Copilot様の素晴らしい実装力に期待しています！
Phase 8.6のような劇的な成果を、LLVMでも実現しましょう！🚀
---
**依頼者**: moe-charm + AIチーム
**GitHub Issue**: #（作成予定）
**開始可能日**: 即時

151
docs/development/roadmap/phases/phase-9/llvm/Hybrid-Future-Vision.md Normal file
View File

@ -0,0 +1,151 @@
# 🌈 理想的なハイブリッド実行環境への願望
**「AOT WASMが非同期対応してたら...」**
## 😿 **現在の苦労ポイント**
### **各バックエンドの制限**
| バックエンド | 利点 | 欠点 |
|------------|------|------|
| **WASM** | どこでも動く | 非同期が弱い、遅い |
| **LLVM** | 超高速 | OS別ビルド必要 |
| **VM** | 柔軟 | ネイティブより遅い |
| **AOT** | 高速起動 | プラットフォーム依存 |
### **理想と現実のギャップ**
```rust
// 理想
async fn perfect_world() {
let result = await some_io(); // WASMでも高速非同期
return result;
}
// 現実
fn reality() {
// WASMは同期的、非同期は複雑
// LLVMは速いけどOS別ビルド
// 完璧な解決策がない...
}
```
## 🚀 **夢のハイブリッド環境**
### **1. WASM Component Model + AOT**
```yaml
理想:
- WASMの可搬性
- AOTの実行速度
- ネイティブ非同期サポート
- 単一バイナリで全OS対応
現実:
- Component Model仕様策定中
- AOT最適化はまだ発展途上
- 非同期は部分的サポート
```
### **2. Deno/Bun的アプローチ**
```javascript
// JavaScriptランタイムの良いとこ取り
- V8/JavaScriptCore の JIT性能
- ネイティブバインディング
- 非同期完全サポート
- でもJavaScript...
```
### **3. 究極の理想：Universal Runtime**
```rust
// もしこんなランタイムがあったら...
universal_runtime {
// WASMレベルの可搬性
portability: "write once, run anywhere",
// LLVMレベルの性能
performance: "near native",
// 完全な非同期サポート
async: "first class",
// 単一配布物
distribution: "single file"
}
```
## 💭 **現実的な妥協案**
### **短期的ハイブリッド戦略**
```yaml
開発時:
- インタープリター（即時実行、デバッグ容易）
テスト時:
- VM（高速、クロスプラットフォーム）
配布時:
選択式:
- WASM版: ブラウザ/サーバー両対応
- ネイティブ版: 最高性能
- ハイブリッド版: WASMランタイム埋め込み
```
### **中期的技術統合**
```rust
// Nyashハイブリッドランタイム
pub enum ExecutionMode {
// 高速パス: ネイティブコード
Native(LLVMCompiledCode),
// 互換パス: WASM
Wasm(WasmModule),
// 動的切り替え
Adaptive {
hot_path: LLVMCompiledCode,
cold_path: WasmModule,
}
}
```
## 🔮 **将来への期待**
### **技術の収束点**
1. **WASI Preview 2**: 非同期サポート改善中
2. **WASM GC**: メモリ管理効率化
3. **Component Model**: 真のモジュラー化
4. **AOT最適化**: Wasmtime/WazeroCranelift進化
### **Nyashの位置づけ**
```yaml
現在:
- 4バックエンド個別対応
- それぞれの長所を活かす
将来:
- 統合ランタイム
- 動的最適化
- 透過的実行モード切り替え
```
## 😊 **でも今でも十分すごい！**
**現在のNyash**:
- ✅ 4つの実行方式を選べる
- ✅ 用途に応じて最適化可能
- ✅ プラグインシステム完備
**苦労はあるけど**:
- 複数バックエンドの保守
- プラットフォーム別の調整
- でも**選択肢があることが強み**！
## 🎯 **結論**
理想的なハイブリッド環境はまだ存在しないけど、Nyashは**現実的な最良の解**を提供中！
将来、技術が成熟したら：
- WASM AOT + 非同期 = 最強の可搬性
- LLVM + WASM統合 = 性能と互換性の両立
それまでは、**4バックエンドを賢く使い分ける**のが正解！
**Everything is Box、Every Backend has its Place！**🌈✨

149
docs/development/roadmap/phases/phase-9/llvm/JIT-vs-AOT-With-MIR.md Normal file
View File

@ -0,0 +1,149 @@
# 🤔 JIT vs AOT：MIRがあると難易度が同じ？
**「MIRできてるから、JITもAOTも同じようなレベルに見えてきた」**
## 💡 **その洞察、正しいです！**
### **MIRの存在が変えるゲーム**
```rust
// 従来の難易度
Source → Native: 超難しい（全部自分で）
Source → JIT: 難しい（実行時コンパイル）
// MIRがある今
Source → MIR → Native: MIRから先は楽！
Source → MIR → JIT: MIRから先は楽！
```
## 📊 **JIT vs AOT 比較（MIR前提）**
| 項目 | JIT | AOT (LLVM) |
|------|-----|------------|
| **実装難易度** | ⭐⭐⭐ | ⭐⭐⭐ |
| **初期実装速度** | 速い | 速い |
| **実行時性能** | 80-95% | 100% |
| **起動時間** | 遅い | 速い |
| **メモリ使用** | 多い | 少ない |
| **動的最適化** | ✅ | ❌ |
| **配布** | ランタイム必要 | 単体実行可能 |
**MIRのおかげで、どちらも同じくらいの実装難易度に！**
## 🚀 **JIT実装の選択肢**
### **1. VM JIT化（最も現実的）**
```rust
// 現在のVM
match opcode {
Add => stack.push(a + b),
}
// JIT化したVM
if hot_path {
// CraneliftでMIR→ネイティブ
let native = cranelift_compile(&mir);
execute_native(native);
}
```
**利点**：
- 既存VMの延長線上
- 段階的移行可能
- ホットパスのみJIT化
### **2. 純粋JITコンパイラ**
```rust
// MIR → Cranelift IR → Native
pub fn jit_compile(mir: &MirModule) -> NativeCode {
let mut ctx = CraneliftContext::new();
for func in &mir.functions {
ctx.compile_function(func);
}
ctx.finalize()
}
```
**利点**：
- クリーンな設計
- 最適化しやすい
- デバッグ情報維持
### **3. LLVM JIT（ORC）**
```rust
// LLVM ORCでJIT
let jit = LLVMOrcJIT::new();
jit.add_module(llvm_module);
let func = jit.get_function("main");
func.call();
```
**利点**：
- LLVM最適化の恩恵
- AOTとコード共有
- 最高性能
## 🔮 **実装難易度の実際**
### **AOT (LLVM)**
```yaml
必要な作業:
1. MIR → LLVM IR変換: 2週間
2. 型システムマッピング: 1週間
3. ランタイム統合: 1週間
4. 最適化調整: 1週間
合計: 約5週間
```
### **JIT (Cranelift)**
```yaml
必要な作業:
1. MIR → Cranelift IR変換: 2週間
2. JITランタイム実装: 1週間
3. ホットパス検出: 1週間
4. メモリ管理: 1週間
合計: 約5週間
```
**ほぼ同じ！MIRのおかげで！**
## 💭 **どっちを選ぶべき？**
### **JITが向いている場合**
- 長時間実行プログラム
- 動的な最適化が必要
- REPLやインタラクティブ環境
### **AOTが向いている場合**
- 起動時間重視
- 配布の簡単さ重視
- 組み込み環境
### **Nyashの場合**
```yaml
現実的な選択:
1. まずAOT (LLVM) でPoC
2. VM最適化を極める
3. 将来VM JIT化も追加
理由:
- 配布が簡単（AOT）
- 性能も確保（VM既に50倍）
- 両方あれば最強
```
## 🎯 **結論**
**MIRがあるおかげで、JITもAOTも同じくらいの難易度！**
でも、Nyashの場合：
1. **配布の簡単さ** → AOT有利
2. **既にVM高速** → JIT緊急度低い
3. **将来の拡張性** → 両方実装が理想
**提案**：
- **短期**: LLVM AOT完成（配布重視）
- **中期**: VM更なる最適化
- **長期**: VM JIT化（最高性能）
**MIRがあれば、どっちも楽！**🚀

187
docs/development/roadmap/phases/phase-9/llvm/Phase-9.78-Implementation-Plan.md Normal file
View File

@ -0,0 +1,187 @@
# 📋 Phase 9.78: LLVM PoC 実装計画書
**バージョン**: 1.0
**作成日**: 2025年8月20日
**ステータス**: 準備完了
## 🎯 **プロジェクト概要**
### **目的**
3週間でNyash言語のLLVMバックエンド実現可能性を実証する
### **成功基準**
- 基本的なNyashプログラムがLLVM経由で実行可能
- インタープリター比10倍以上の性能向上
- Phase 10本格実装への技術的道筋確立
## 📅 **3週間実装スケジュール**
### **Week 1: 基盤構築（8/21-8/27）**
#### **Day 1-2: 環境セットアップ**
```toml
# Cargo.toml
[dependencies]
inkwell = { version = "0.5", features = ["llvm17-0"] }
```
- [ ] inkwellクレート導入
- [ ] LLVMコンテキスト初期化
- [ ] 基本的なモジュール生成
#### **Day 3-4: 最小命令実装**
```rust
// 実装対象
- Const(Integer/Float/Bool)
- Return
- 基本的な型マッピング
```
#### **Day 5-7: Hello World達成**
- [ ] ランタイム関数宣言
- [ ] .oファイル生成
- [ ] `return 42`の実行確認
**Week 1成果物**: 整数を返す最小プログラムのLLVM実行
### **Week 2: コア機能実装（8/28-9/3）**
#### **Day 8-10: 算術演算と制御フロー**
```rust
// 実装対象
- BinOp (Add/Sub/Mul/Div)
- Compare (Eq/Ne/Lt/Le/Gt/Ge)
- Branch/Jump
- PHI nodes
```
#### **Day 11-13: Box型MVP**
```rust
// Box操作の実装
extern "C" {
fn nyash_runtime_box_new(size: u64, align: u64) -> *mut c_void;
fn nyash_runtime_box_free(ptr: *mut c_void);
fn nyash_runtime_box_deref(ptr: *mut c_void) -> *mut c_void;
}
```
#### **Day 14: 統合テスト**
- [ ] 条件分岐を含むプログラム
- [ ] Box操作を含むプログラム
- [ ] LLVMVerifyModuleによる検証
**Week 2成果物**: 制御フローとメモリ操作を含むプログラムの動作
### **Week 3: 最適化と検証（9/4-9/10）**
#### **Day 15-16: 最適化パス**
```rust
// 基本最適化
- mem2reg (alloca → SSA)
- instcombine (命令結合)
- reassociate (結合則)
```
#### **Day 17-18: ベンチマーク**
```bash
# 性能測定対象
- フィボナッチ数列
- 素数判定
- 簡単な数値計算ループ
```
#### **Day 19-21: 文書化とレポート**
- [ ] 技術レポート作成
- [ ] Phase 10実装計画
- [ ] 性能評価結果
**Week 3成果物**: 性能実証とPhase 10への道筋
## 🛠️ **技術アーキテクチャ**
### **ディレクトリ構造**
```
src/backend/llvm/
├── mod.rs // LLVMバックエンドエントリ
├── context.rs // CodegenContext管理
├── types.rs // MIR→LLVM型変換
├── builder.rs // LLVM IR生成
├── runtime.rs // ランタイム関数定義
└── optimizer.rs // 最適化パス管理
```
### **主要コンポーネント**
#### **CodegenContext**
```rust
pub struct CodegenContext<'ctx> {
context: &'ctx Context,
module: Module<'ctx>,
builder: Builder<'ctx>,
target_machine: TargetMachine,
type_cache: HashMap<MirType, BasicTypeEnum<'ctx>>,
}
```
#### **MIR→LLVM変換器**
```rust
pub fn lower_mir_to_llvm(
mir_module: &MirModule,
target_triple: &str,
) -> Result<Vec<u8>, CodegenError> {
// 1. コンテキスト初期化
// 2. 型変換
// 3. 関数生成
// 4. 命令変換
// 5. 最適化
// 6. オブジェクトコード生成
}
```
## 📊 **リスク管理**
### **技術的リスク**
| リスク | 影響度 | 対策 |
|--------|--------|------|
| inkwellバージョン依存 | 中 | LLVM17固定、CI環境統一 |
| Box型の複雑性 | 高 | ランタイム委譲戦略 |
| デバッグ困難性 | 中 | IR dump機能、差分テスト |
### **スケジュールリスク**
- **バッファ**: 各週に1日の予備日設定
- **優先順位**: 基本動作 > 性能 > 機能網羅性
- **早期失敗**: Week 1で実現困難判明時は即座に方針転換
## ✅ **成功指標**
### **定量的指標**
- [ ] 10個以上のMIR命令をサポート
- [ ] 5個以上のテストプログラムが動作
- [ ] インタープリター比10倍以上高速
### **定性的指標**
- [ ] コードの保守性（他の開発者が理解可能）
- [ ] エラーメッセージの有用性
- [ ] 将来の拡張可能性
## 🚀 **開始準備チェックリスト**
- [x] VM性能改善完了（50.94倍達成！）
- [x] AI大会議による戦略確定
- [ ] Copilotへの正式依頼
- [ ] 開発環境準備（LLVM17インストール）
- [ ] Week 1タスクのGitHub Issue作成
## 📝 **参考資料**
- [AI大会議結果](./AI-Conference-LLVM-Results.md)
- [inkwellドキュメント](https://github.com/TheDan64/inkwell)
- [LLVM Language Reference](https://llvm.org/docs/LangRef.html)
---
**承認者**: moe-charm
**実装担当**: Copilot + AIチーム
**レビュー**: Phase 9.78完了時

119
docs/development/roadmap/phases/phase-9/llvm/Practical-Distribution-Strategy.md Normal file
View File

@ -0,0 +1,119 @@
# 📦 Nyash実用的配布戦略：現実的なアプローチ
## 🎯 **配布形態の比較**
| 方式 | ファイルサイズ | 配布の手間 | 適用範囲 | 実用性 |
|------|--------------|-----------|---------|--------|
| **個別バイナリ** | 各1-2MB | OS別に配布 | 全アプリ | ⭐⭐⭐⭐⭐ |
| **APE** | 3-6MB | 1ファイル | 小規模CLI | ⭐⭐⭐ |
| **WASM+ランタイム** | 0.5MB+10MB | ランタイム必要 | 全アプリ | ⭐⭐⭐⭐ |
## 📊 **現実的な使い分け**
### **1. メインストリーム配布（推奨）**
```bash
# OS別の最適化されたバイナリ
nyash-linux-x64 (1.5MB) - musl静的リンク
nyash-windows.exe (916KB) - mingw最適化
nyash-macos (1.8MB) - 署名付き
```
**利点**:
- ✅ 各OSで最高性能
- ✅ 最小サイズ
- ✅ OS固有機能フル活用
- ✅ 大規模アプリも対応
### **2. 開発者向け配布**
```bash
# LLVM IRの中立性を活用
nyashc --emit-bitcode program.nyash
# → program.bc (プラットフォーム中立)
# 各自のマシンで最適化コンパイル
nyashc --from-bitcode program.bc --target native
```
### **3. 特殊用途でのAPE**
```bash
# 小さなツール限定
nyash-fmt.com # コードフォーマッター (2MB)
nyash-lint.com # リンター (3MB)
nyash-repl.com # REPL (4MB)
```
**APEが向いている場合**:
- 単体で動くCLIツール
- 依存ライブラリが少ない
- 配布の簡単さが最優先
**APEが向いていない場合**:
- GUIアプリケーション
- 大量のライブラリ依存
- プラグインシステム
- ゲームなど大規模アプリ
## 🚀 **段階的実装計画（修正版）**
### **Phase 1: 基本マルチターゲット**（1ヶ月）
```bash
nyashc build --target linux
nyashc build --target windows
# 個別にビルド、確実に動作
```
### **Phase 2: 同時生成最適化**（3ヶ月）
```bash
nyashc build --all-targets
# Bitcodeキャッシュで高速化
# 並列ビルドで時間短縮
```
### **Phase 3: 配布自動化**（6ヶ月）
```bash
nyashc release
# 出力:
# - dist/nyash-v1.0-linux-x64.tar.gz
# - dist/nyash-v1.0-windows-x64.zip
# - dist/nyash-v1.0-macos.dmg
# - dist/nyash-tools.com (APE版ツール集)
```
## 💡 **賢い配布戦略**
### **メインアプリ**: 個別最適化バイナリ
```yaml
nyash本体:
Linux: 1.5MB (musl静的)
Windows: 916KB (mingw)
macOS: 1.8MB (universal)
```
### **開発ツール**: APEで統一
```yaml
開発者ツール（APE）:
nyash-fmt.com: 2MB
nyash-test.com: 3MB
nyash-bench.com: 2.5MB
```
### **プラグイン**: 動的ライブラリ
```yaml
プラグイン（各OS別）:
filebox.so: 200KB (Linux)
filebox.dll: 180KB (Windows)
filebox.dylib: 220KB (macOS)
```
## 🎉 **結論**
**「適材適所」が最強の戦略！**
- **大規模アプリ**: 個別最適化バイナリ
- **小規模ツール**: APEで配布簡略化
- **開発者向け**: Bitcodeで柔軟性確保
APEは「魔法」だけど、現実的には**限定的な用途**で輝く技術。
Nyashのメイン配布は**堅実な個別バイナリ**で行きましょう！
**Everything is Box、でも配布は現実的に！**📦✨

169
docs/development/roadmap/phases/phase-9/llvm/Revolutionary-Windows-Strategy.md Normal file
View File

@ -0,0 +1,169 @@
# 🚀 Nyash革命的Windows実行戦略：LLVM IR中立性の完全活用
**作成日**: 2025年8月20日
**AI会議参加者**: Gemini先生、Codex先生、Claude
## 🎯 **核心的アイデア：1回のIR生成で全プラットフォーム対応**
LLVM IRはプラットフォーム中立。だから**1回のIR生成から同時に複数OS用の実行ファイルを生成できる！**
```rust
// 革命的ワンパス・マルチターゲット生成
nyashc --targets linux,windows,macos program.nyash
// 出力（同時生成！）
dist/x86_64-unknown-linux-musl/nyash # Linux版
dist/x86_64-pc-windows-gnu/nyash.exe # Windows版
dist/x86_64-apple-darwin/nyash # macOS版
```
## 🏗️ **実装アーキテクチャ**
### **Phase 1: 即効性重視（3週間で実現）**
```rust
// 1. IR生成（1回だけ）
let ir_module = compile_to_ir(&ast);
let bitcode = ir_module.write_bitcode_to_memory();
// 2. マルチターゲット並列生成
parallel_for_each(["linux", "windows-gnu"], |target| {
let module = context.create_module_from_ir(bitcode.clone());
configure_for_target(&module, target);
generate_executable(&module, target);
});
```
**技術スタック**:
- Linux: musl静的リンク（配布容易）
- Windows: mingw-gnu + lld（クロスリンク簡単）
- 共通: PAL (Platform Abstraction Layer)
### **Phase 2: 本格実装（3ヶ月）**
**全プラットフォーム同時対応**:
```yaml
ターゲット構成:
linux:
- x86_64-unknown-linux-musl
- aarch64-unknown-linux-musl
windows:
- x86_64-pc-windows-gnu (mingw)
- x86_64-pc-windows-msvc (xwin)
macos:
- x86_64-apple-darwin
- aarch64-apple-darwin (M1/M2)
```
### **Phase 3: 究極形態（6ヶ月）**
**APE (Actually Portable Executable) - 単一バイナリで全OS対応！**
```bash
# たった1つのファイルが全OSで動く！
./nyash.com # Linux でも Windows でも macOS でも動作！
```
**⚠️ APEの現実的な制限**：
- バイナリサイズ: 通常の**3倍**（3OS分のコード含む）
- ライブラリ: 各OS用に3種類必要
- 適用範囲: **小規模CLIツール向け**（大規模アプリは不向き）
## 💡 **技術的革新ポイント**
### **1. Bitcodeキャッシュ戦略**
```rust
pub struct MultiTargetCompiler {
bitcode_cache: HashMap<ModuleId, MemoryBuffer>,
target_machines: HashMap<Triple, TargetMachine>,
}
impl MultiTargetCompiler {
pub fn compile_all(&self, module_id: ModuleId) -> Result<Vec<ExecutablePath>> {
let bitcode = self.bitcode_cache.get(&module_id).unwrap();
self.target_machines
.par_iter() // 並列処理！
.map(|(triple, tm)| {
let module = load_from_bitcode(bitcode);
tm.emit_to_file(&module, FileType::Object)
})
.collect()
}
}
```
### **2. PAL (Platform Abstraction Layer)**
```rust
// コンパイラは常にこれらを呼ぶ
extern "C" {
fn nyash_rt_print(s: *const u8, len: usize);
fn nyash_rt_file_open(path: *const u8, mode: u32) -> i32;
fn nyash_rt_time_now() -> u64;
}
// 各OS用のランタイムで実装
#[cfg(target_os = "windows")]
pub fn nyash_rt_print(s: *const u8, len: usize) {
// UTF-8 → UTF-16変換してWriteConsoleW
}
#[cfg(target_os = "linux")]
pub fn nyash_rt_print(s: *const u8, len: usize) {
// そのままwrite(1, s, len)
}
```
### **3. リンク戦略の統一**
```toml
[target.'cfg(windows)'.dependencies]
lld = { version = "0.1", features = ["coff"] }
mingw-w64-libs = { path = "vendor/mingw" }
[target.'cfg(unix)'.dependencies]
lld = { version = "0.1", features = ["elf"] }
musl-libc = { path = "vendor/musl" }
```
## 🎉 **革命的成果**
### **開発者体験**
```bash
# 1コマンドで全プラットフォーム対応！
nyashc build --all-platforms
# 出力
✅ Linux版生成完了 (2.1MB)
✅ Windows版生成完了 (916KB)
✅ macOS版生成完了 (1.8MB)
✅ WASM版生成完了 (512KB)
```
### **ユーザー体験**
- **配布**: 各OS用のネイティブバイナリ
- **性能**: LLVM最適化でVM比10倍以上高速
- **将来**: APEで単一ファイル配布
## 📊 **実装ロードマップ**
| フェーズ | 期間 | 成果物 |
|---------|------|--------|
| Week 1-3 | LLVM PoC | Linux単体動作 |
| Month 1 | Windows統合 | Linux + Windows同時生成 |
| Month 2 | 全OS対応 | Linux/Windows/macOS |
| Month 3 | 最適化 | PAL完成、性能調整 |
| Month 6 | APE統合 | 単一バイナリ実現 |
## 🚀 **次のアクション**
1. **即実装**: Bitcodeキャッシュ機構
2. **PAL設計**: 最小限のランタイムAPI定義
3. **Windows-gnu**: mingwでクロスリンク環境構築
4. **並列化**: rayon使用でマルチターゲット生成
## 💭 **結論**
LLVM IRの中立性を活用すれば、**「Write Once, Compile to All」**が実現できる！
これこそがNyashの革命的Windows戦略です。1回のコンパイルで全プラットフォーム対応、最終的には単一バイナリで境界を超える。
**Everything is Box、そしてEvery Platform is Target！**🎯

155
docs/development/roadmap/phases/phase-9/llvm/VM-Native-Speed-Possibility.md Normal file
View File

@ -0,0 +1,155 @@
# 🚀 Nyash VM をネイティブ速度に近づける可能性
**「もしかして、VM完璧に作ればネイティブに近づける？」**
## 💡 **その直感、正しいです！**
### **現在のVM性能**
- インタープリター比: **50.94倍高速**（達成済み！）
- でもLLVMネイティブには及ばない...はず？
### **でも待って、よく考えると...**
## 🔥 **VMがネイティブに迫れる理由**
### **1. JITコンパイルの可能性**
```rust
// 現在: バイトコード実行
match opcode {
Add => stack.push(a + b),
// ...
}
// 将来: ホットパスをネイティブコードに！
if execution_count > HOT_THRESHOLD {
let native_code = jit_compile(&bytecode);
execute_native(native_code); // ほぼネイティブ速度！
}
```
### **2. 最適化の余地がまだある**
```yaml
現在のVM最適化:
✅ デバッグ出力削除
✅ HashMap → Vec
✅ メモリ効率化
まだできること:
- レジスタVM化（スタックVM → レジスタVM）
- インライン展開
- 定数畳み込み
- ループ最適化
- SIMD活用
```
### **3. 言語特性を活かした最適化**
```rust
// Nyashの特徴を利用
- Everything is Box → 型情報を活用した特殊化
- Arc<Mutex>パターン → 最適化可能な箇所を特定
- 限定的な言語機能 → 積極的な最適化
```
## 📊 **他言語VMの実績**
| VM | 対ネイティブ性能 | 特徴 |
|----|----------------|------|
| **JVM (HotSpot)** | 80-95% | JIT最適化の極致 |
| **V8 (JavaScript)** | 70-90% | 型推論+インライン |
| **PyPy** | 400-700% (CPython比) | トレーシングJIT |
| **LuaJIT** | 90-99% | 超軽量JIT |
**LuaJITは特に注目**: シンプルな言語 + 優れたJIT = ほぼネイティブ！
## 🎯 **Nyash VMネイティブ化戦略**
### **Phase 1: 基礎最適化（現在〜1ヶ月）**
```rust
// レジスタVM化
enum VMRegister {
R0, R1, R2, R3, // ... R15
}
// より効率的な命令セット
enum Instruction {
LoadReg(VMRegister, Value),
AddReg(VMRegister, VMRegister, VMRegister),
// スタック操作を削減
}
```
### **Phase 2: プロファイル駆動最適化（2-3ヶ月）**
```rust
struct HotPath {
bytecode: Vec<Instruction>,
execution_count: u64,
optimized_version: Option<OptimizedCode>,
}
// ホットパスを検出して最適化
if hot_path.execution_count > 1000 {
optimize_hot_path(&mut hot_path);
}
```
### **Phase 3: 軽量JIT（6ヶ月）**
```rust
// Cranelift使用で軽量JIT実装
use cranelift::prelude::*;
fn jit_compile(bytecode: &[Instruction]) -> NativeCode {
let mut ctx = Context::new();
// バイトコード → Cranelift IR → ネイティブ
compile_to_native(&mut ctx, bytecode)
}
```
## 🔮 **実現可能な性能目標**
### **段階的目標**
1. **現在**: インタープリター比 50倍
2. **Phase 1完了**: 100倍（レジスタVM化）
3. **Phase 2完了**: 200倍（最適化）
4. **Phase 3完了**: **ネイティブの80-90%**（JIT）
### **なぜ可能か？**
- Nyashはシンプルな言語
- Box型システムで最適化しやすい
- 既に50倍達成の実績
- MIR基盤が整っている
## 💭 **VM vs LLVM の最終形**
```yaml
Nyash VM (完全体):
利点:
- ポータビリティ完璧
- 起動時間高速
- 動的最適化可能
- デバッグ容易
性能: ネイティブの80-90%
LLVM AOT:
利点:
- 最高性能（100%）
- 事前最適化
- 配布サイズ小
欠点:
- プラットフォーム別ビルド
- 起動時最適化なし
```
## 🎉 **結論：VMでもいける！**
**完璧に作れば、VMでもネイティブに迫れます！**
特にNyashのような：
- シンプルな言語
- 明確な型システム（Everything is Box）
- 限定的な機能セット
これらの特徴は**VMの高速化に有利**！
**もしかしたら、LLVM要らないかも...？**（いや、両方あると最強！）
**Everything is Box、VM can be Native-Fast！**🚀✨

91
docs/development/roadmap/phases/phase-9/llvm/Windows-Strategy-Summary.md Normal file
View File

@ -0,0 +1,91 @@
# 🪟 Windows同時作戦の現状まとめ
**更新日**: 2025年8月20日
## 📊 **現在の状況**
### **✅ 完了したこと**
1. **AI大会議実施**
- Gemini先生: 4つの革命的戦略提案
- Codex先生: 技術的実装方法の詳細化
2. **戦略文書作成**
- Revolutionary-Windows-Strategy.md: 統合戦略
- APE-Magic-Explained.md: 単一バイナリ技術解説
- Practical-Distribution-Strategy.md: 現実的配布方法
3. **技術的方針決定**
- **核心**: LLVM IRの中立性を活用した同時生成
- **方法**: Bitcodeキャッシュ + 並列ターゲット生成
### **🚀 実装計画**
#### **即効性のある解決策（Week 1-3）**
```bash
# Linux + Windows同時生成
nyashc --targets linux,windows-gnu program.nyash
# 出力
dist/linux/nyash # Linux版（musl静的）
dist/windows/nyash.exe # Windows版（mingw）
```
**実装手順**:
1. Week 1: Linux版LLVM実装（進行中）
2. Week 2: Bitcodeキャッシュ機構追加
3. Week 3: Windows-gnu同時生成
#### **中期計画（1-3ヶ月）**
- 全プラットフォーム同時対応
- PAL (Platform Abstraction Layer) 完成
- 最適化とテスト
## 🛠️ **技術的アプローチ**
### **1. ワンパス・マルチターゲット**
```rust
// 1回のIR生成
let bitcode = module.write_bitcode_to_memory();
// 並列で各OS向け生成
["linux", "windows-gnu", "macos"].par_iter()
.map(|target| generate_for_target(bitcode.clone(), target))
.collect()
```
### **2. Windows特化戦略**
- **短期**: mingw-gnu（クロスコンパイル簡単）
- **長期**: msvc対応（xwin使用）
- **配布**: 916KBの小さな実行ファイル
### **3. 段階的実装**
| Phase | 期間 | 成果 |
|-------|------|------|
| 現在 | LLVM PoC | Linux単体 |
| Week 3 | 同時生成 | Linux + Windows |
| Month 1 | 全OS | +macOS |
| Month 3 | 最適化 | PAL完成 |
## 💡 **重要ポイント**
### **すぐに実現可能なこと**
- ✅ Linux/Windows同時ビルド（mingw使用）
- ✅ 1つのコマンドで両OS対応
- ✅ Bitcodeレベルでの共有
### **将来の野望**
- 🎯 全OS同時生成
- 🎯 APE単一バイナリ（小ツール用）
- 🎯 完全なクロスプラットフォーム
## 🎉 **結論**
**Windows同時作戦は技術的に実現可能！**
1. **LLVM IRの中立性**を最大活用
2. **Bitcodeキャッシュ**で効率化
3. **mingw**で即座にWindows対応
Copilotが基本LLVM実装を進めている間に、我々は革命的な同時生成戦略を準備完了！
**Everything is Box、Every Platform is Target！**🎯✨

266
docs/development/roadmap/phases/phase-9/llvm/issue/001-setup-inkwell-hello-world.md Normal file
View File

@ -0,0 +1,266 @@
# 🚀 Issue #001: LLVM PoC - inkwellセットアップとHello World実装
**タイプ**: Feature
**優先度**: Critical
**見積もり**: 3日
**担当**: Copilot
## 📋 概要
Phase 9.78 LLVM PoCの第一歩として、inkwellクレートを導入し、最小限のNyashプログラム（`return 42`）をLLVM経由で実行できるようにする。
## 🎯 成功条件
以下のNyashプログラムがLLVM経由で実行され、正しい終了コードを返すこと：
```nyash
// test_return_42.nyash
static box Main {
main() {
return 42
}
}
```
期待される動作：
```bash
$ cargo run --features llvm -- --backend llvm test_return_42.nyash
$ echo $?
42
```
## 📝 実装タスク
### 1. **Cargo.toml更新** ✅必須
```toml
[dependencies]
inkwell = { version = "0.5", features = ["llvm17-0"] }
[features]
llvm = ["inkwell"]
```
### 2. **基本構造の作成** ✅必須
```rust
// src/backend/llvm/mod.rs
pub mod context;
pub mod compiler;
use crate::mir::module::MirModule;
use crate::errors::RuntimeError;
pub fn compile_to_object(
mir_module: &MirModule,
output_path: &str,
) -> Result<(), RuntimeError> {
let compiler = compiler::LLVMCompiler::new()?;
compiler.compile_module(mir_module, output_path)
}
```
### 3. **LLVMコンテキスト管理** ✅必須
```rust
// src/backend/llvm/context.rs
use inkwell::context::Context;
use inkwell::module::Module;
use inkwell::builder::Builder;
use inkwell::targets::{Target, TargetMachine, TargetTriple, InitializationConfig};
pub struct CodegenContext<'ctx> {
pub context: &'ctx Context,
pub module: Module<'ctx>,
pub builder: Builder<'ctx>,
pub target_machine: TargetMachine,
}
impl<'ctx> CodegenContext<'ctx> {
pub fn new(context: &'ctx Context, module_name: &str) -> Result<Self, String> {
// 1. ターゲット初期化
Target::initialize_native(&InitializationConfig::default())
.map_err(|e| format!("Failed to initialize native target: {}", e))?;
// 2. モジュール作成
let module = context.create_module(module_name);
// 3. ターゲットマシン作成
let triple = TargetMachine::get_default_triple();
let target = Target::from_triple(&triple)
.map_err(|e| format!("Failed to get target: {}", e))?;
let target_machine = target
.create_target_machine(
&triple,
"generic",
"",
inkwell::OptimizationLevel::None,
inkwell::targets::RelocMode::Default,
inkwell::targets::CodeModel::Default,
)
.ok_or_else(|| "Failed to create target machine".to_string())?;
// 4. データレイアウト設定
module.set_triple(&triple);
module.set_data_layout(&target_machine.get_target_data().get_data_layout());
Ok(Self {
context,
module,
builder: context.create_builder(),
target_machine,
})
}
}
```
### 4. **最小限のコンパイラ実装** ✅必須
```rust
// src/backend/llvm/compiler.rs
use inkwell::context::Context;
use inkwell::values::IntValue;
use crate::mir::module::MirModule;
use crate::mir::instruction::MirInstruction;
use super::context::CodegenContext;
pub struct LLVMCompiler {
context: Context,
}
impl LLVMCompiler {
pub fn new() -> Result<Self, String> {
Ok(Self {
context: Context::create(),
})
}
pub fn compile_module(
&self,
mir_module: &MirModule,
output_path: &str,
) -> Result<(), String> {
let codegen = CodegenContext::new(&self.context, "nyash_module")?;
// 1. main関数を探す
let main_func = mir_module.functions.iter()
.find(|f| f.name == "Main.main")
.ok_or("Main.main function not found")?;
// 2. LLVM関数を作成
let i32_type = codegen.context.i32_type();
let fn_type = i32_type.fn_type(&[], false);
let llvm_func = codegen.module.add_function("main", fn_type, None);
// 3. エントリブロックを作成
let entry = codegen.context.append_basic_block(llvm_func, "entry");
codegen.builder.position_at_end(entry);
// 4. MIR命令を処理（今回はReturnのみ）
for block in &main_func.blocks {
for inst in &block.instructions {
match inst {
MirInstruction::Return(Some(value_id)) => {
// 簡易実装: 定数42を返すと仮定
let ret_val = i32_type.const_int(42, false);
codegen.builder.build_return(Some(&ret_val));
}
_ => {
// 他の命令は今回スキップ
}
}
}
}
// 5. 検証
if !llvm_func.verify(true) {
return Err("Function verification failed".to_string());
}
// 6. オブジェクトファイル生成
codegen.target_machine
.write_to_file(&codegen.module,
inkwell::targets::FileType::Object,
output_path.as_ref())
.map_err(|e| format!("Failed to write object file: {}", e))?;
Ok(())
}
}
```
### 5. **バックエンド統合** ✅必須
```rust
// src/backend/mod.rsに追加
#[cfg(feature = "llvm")]
pub mod llvm;
// src/runner.rsのrun_with_backend関数に追加
#[cfg(feature = "llvm")]
ExecutionBackend::LLVM => {
// 1. オブジェクトファイル生成
let obj_path = "nyash_output.o";
crate::backend::llvm::compile_to_object(&mir_module, obj_path)?;
// 2. リンク（簡易版：システムのccを使用）
use std::process::Command;
let output = Command::new("cc")
.args(&[obj_path, "-o", "nyash_output"])
.output()
.map_err(|e| RuntimeError::new(format!("Link failed: {}", e)))?;
if !output.status.success() {
return Err(RuntimeError::new("Linking failed"));
}
// 3. 実行
let output = Command::new("./nyash_output")
.output()
.map_err(|e| RuntimeError::new(format!("Execution failed: {}", e)))?;
// 4. 終了コードを返す
let exit_code = output.status.code().unwrap_or(-1);
Ok(Box::new(IntegerBox::new(exit_code as i64)))
}
```
## 🧪 テストケース
```rust
// tests/llvm_hello_world.rs
#[test]
#[cfg(feature = "llvm")]
fn test_return_42() {
let source = r#"
static box Main {
main() {
return 42
}
}
"#;
// パース → MIR生成 → LLVM実行
let result = compile_and_run_llvm(source);
assert_eq!(result, 42);
}
```
## 📚 参考資料
- [inkwell Examples](https://github.com/TheDan64/inkwell/tree/master/examples)
- [LLVM Tutorial](https://llvm.org/docs/tutorial/)
- [AI大会議結果](../AI-Conference-LLVM-Results.md)
## ⚠️ 注意事項
1. **LLVM依存関係**: LLVM 17がシステムにインストールされている必要があります
2. **プラットフォーム**: まずはLinux/macOSで動作確認し、Windowsは後回し
3. **エラーハンドリング**: 今回は最小実装のため、詳細なエラー処理は省略
## 🎯 次のステップ
このIssueが完了したら、次は：
- Issue #002: 基本的な算術演算の実装（BinOp）
- Issue #003: 定数値の実装（Const）
---
**作成者**: Claude + moe-charm
**レビュアー**: AIチーム
**関連PR**: （作成予定）

119
docs/development/roadmap/phases/phase-9/llvm/issue/GitHub-Issue-Template.md Normal file
View File

@ -0,0 +1,119 @@
# 🐙 GitHub Issue作成テンプレート
以下の内容をGitHub Issueにコピペして使用してください。
---
## Issue Title:
`[Phase 9.78] LLVM PoC Week 1 - inkwellセットアップとHello World実装`
## Labels:
- `enhancement`
- `Phase-9.78`
- `LLVM`
- `critical`
## Assignees:
- GitHub Copilot
## Milestone:
- Phase 9.78 LLVM PoC
## Issue Body:
```markdown
## 📋 概要
Phase 9.78 LLVM PoCの開始です！最初のステップとして、inkwellクレートを導入し、最小限のNyashプログラム（`return 42`）をLLVM経由で実行できるようにします。
## 🎯 成功条件
```nyash
// test_return_42.nyash
static box Main {
main() {
return 42
}
}
```
上記プログラムがLLVM経由で実行され、終了コード42を返すこと。
## 📝 実装内容
1. **inkwellクレート導入**
- Cargo.tomlに依存関係追加
- feature flag `llvm` の設定
2. **基本構造作成**
- `src/backend/llvm/` ディレクトリ
- context.rs, compiler.rs, mod.rs
3. **最小限のコンパイラ実装**
- LLVMコンテキスト初期化
- main関数の生成
- return命令の処理
- オブジェクトファイル出力
4. **統合**
- ExecutionBackendにLLVM追加
- --backend llvm オプション対応
## 🔗 参考資料
- [詳細実装ガイド](https://github.com/moe-charm/nyash/blob/main/docs/予定/native-plan/llvm/issue/001-setup-inkwell-hello-world.md)
- [Week 1ロードマップ](https://github.com/moe-charm/nyash/blob/main/docs/予定/native-plan/llvm/issue/Week1-Roadmap.md)
- [AI大会議結果](https://github.com/moe-charm/nyash/blob/main/docs/予定/native-plan/llvm/AI-Conference-LLVM-Results.md)
## ✅ 完了条件
- [ ] inkwellがビルドできる
- [ ] test_return_42.nyashがコンパイルできる
- [ ] 実行ファイルが終了コード42を返す
- [ ] 基本的なテストがパスする
## 💬 備考
VM性能改善で素晴らしい成果（50.94倍高速化）を達成していただきありがとうございました！
LLVMでも同様の成功を期待しています。ブロッカーがあれば遠慮なくコメントしてください。
AIチーム（Claude, Gemini, Codex）が全力でサポートします！🚀
```
---
## 📝 追加で作成するIssue
Week 1の進捗に応じて、以下のIssueも順次作成：
1. **Issue #002**: `[Phase 9.78] LLVM PoC - Const命令の実装`
2. **Issue #003**: `[Phase 9.78] LLVM PoC - 基本型システムの実装`
3. **Issue #004**: `[Phase 9.78] LLVM PoC - ランタイム関数宣言`
4. **Issue #005**: `[Phase 9.78] LLVM PoC Week 1 - 統合テスト`
## 🏷️ 推奨ラベル構成
```yaml
Phase関連:
- Phase-9.78
- Phase-8.6 (完了)
- Phase-9.75g-0 (完了)
技術関連:
- LLVM
- MIR
- Performance
- Backend
優先度:
- critical
- high
- medium
- low
タイプ:
- enhancement
- bug
- documentation
- test
```

159
docs/development/roadmap/phases/phase-9/llvm/issue/MIR-Quick-Reference.md Normal file
View File

@ -0,0 +1,159 @@
# 📚 MIR クイックリファレンス for LLVM実装
## 🎯 Week 1で対応するMIR命令
### 1. **Const命令**
```rust
// MIR表現
MirInstruction::Const(value_id, constant_value)
// 例
Const(v1, MirConstant::Integer(42))
Const(v2, MirConstant::Float(3.14))
Const(v3, MirConstant::Bool(true))
// LLVM変換
let int_val = ctx.i32_type().const_int(42, false);
let float_val = ctx.f64_type().const_float(3.14);
let bool_val = ctx.bool_type().const_int(1, false);
```
### 2. **Return命令**
```rust
// MIR表現
MirInstruction::Return(Option<ValueId>)
// 例
Return(Some(v1)) // 値を返す
Return(None) // voidを返す
// LLVM変換
builder.build_return(Some(&value));
builder.build_return(None);
```
## 📄 参考: 現在のMIR構造
```rust
// src/mir/instruction.rs の主要部分
pub enum MirInstruction {
// Week 1対象
Const(ValueId, MirConstant),
Return(Option<ValueId>),
// Week 2対象
BinOp(ValueId, BinaryOp, ValueId, ValueId),
Compare(ValueId, CompareOp, ValueId, ValueId),
Branch(ValueId, BasicBlockId, BasicBlockId),
Jump(BasicBlockId),
// Week 3以降
BoxNew(ValueId, MirType),
BoxCall(ValueId, ValueId, String, Vec<ValueId>),
// ... 他の命令
}
// 定数の型
pub enum MirConstant {
Integer(i64),
Float(f64),
Bool(bool),
String(String),
Null,
}
```
## 🔄 MIR→LLVM変換の基本パターン
```rust
// 基本的な変換ループ
for instruction in &block.instructions {
match instruction {
MirInstruction::Const(value_id, constant) => {
let llvm_value = match constant {
MirConstant::Integer(n) => {
ctx.i64_type().const_int(*n as u64, true).into()
}
MirConstant::Float(f) => {
ctx.f64_type().const_float(*f).into()
}
MirConstant::Bool(b) => {
ctx.bool_type().const_int(*b as u64, false).into()
}
_ => todo!("Other constants"),
};
// value_idとllvm_valueをマッピングに保存
value_map.insert(*value_id, llvm_value);
}
MirInstruction::Return(value_id) => {
match value_id {
Some(id) => {
let value = value_map.get(id).unwrap();
builder.build_return(Some(value));
}
None => {
builder.build_return(None);
}
}
}
_ => {} // Week 1では他の命令は無視
}
}
```
## 🎯 テスト用のMIRサンプル
### 1. **return 42のMIR**
```rust
MirModule {
functions: vec![
MirFunction {
name: "Main.main",
params: vec![],
return_type: MirType::Integer,
blocks: vec![
BasicBlock {
id: 0,
instructions: vec![
Const(v1, MirConstant::Integer(42)),
Return(Some(v1)),
],
},
],
},
],
}
```
### 2. **簡単な計算のMIR**（Week 2用）
```rust
// return 10 + 5
BasicBlock {
instructions: vec![
Const(v1, MirConstant::Integer(10)),
Const(v2, MirConstant::Integer(5)),
BinOp(v3, BinaryOp::Add, v1, v2),
Return(Some(v3)),
],
}
```
## 💡 実装のヒント
1. **ValueIdマッピング**: `HashMap<ValueId, BasicValueEnum>`で管理
2. **型情報**: MIRは型情報を持つので、LLVM型への変換テーブルを作る
3. **基本ブロック**: MIRのBasicBlockIdをLLVMのBasicBlockにマッピング
4. **エラー処理**: 最初は`todo!()`でOK、後から実装
## 📁 関連ファイル
- MIR定義: `src/mir/instruction.rs`
- MIR生成: `src/mir/lowering.rs`
- 参考実装: `src/backend/vm.rs`（VMのMIR処理）
---
**注**: このリファレンスはWeek 1の実装に必要な最小限の情報です。
詳細は実際のソースコードを参照してください。

134
docs/development/roadmap/phases/phase-9/llvm/issue/Quick-Start-Guide.md Normal file
View File

@ -0,0 +1,134 @@
# 🚀 LLVM実装クイックスタートガイド
## 📋 今すぐ始める手順
### 1. **環境準備**（5分）
```bash
# LLVM 17インストール確認
llvm-config --version # 17.x.x が表示されること
# Nyashプロジェクトで作業
cd /path/to/nyash
git checkout -b feature/llvm-poc
```
### 2. **最初のコミット**（10分）
```bash
# Cargo.tomlを編集
echo '[dependencies]
inkwell = { version = "0.5", features = ["llvm17-0"] }
[features]
llvm = ["inkwell"]' >> Cargo.toml
# ディレクトリ作成
mkdir -p src/backend/llvm
# 最初のファイル作成
touch src/backend/llvm/mod.rs
touch src/backend/llvm/context.rs
touch src/backend/llvm/compiler.rs
# コミット
git add .
git commit -m "feat(llvm): Add inkwell dependency and basic structure"
```
### 3. **最小実装のコピペ**（20分）
**src/backend/llvm/mod.rs**:
```rust
pub mod context;
pub mod compiler;
pub use compiler::compile_to_object;
```
**動作確認**:
```bash
cargo build --features llvm
```
### 4. **テストプログラム作成**（5分）
```bash
# テスト用Nyashファイル
cat > test_return_42.nyash << 'EOF'
static box Main {
main() {
return 42
}
}
EOF
```
## 🔍 詰まったときの確認ポイント
### **ビルドエラーの場合**
```bash
# LLVM関連の環境変数確認
echo $LLVM_SYS_170_PREFIX
# 設定されていない場合
export LLVM_SYS_170_PREFIX=$(llvm-config --prefix)
```
### **inkwellのバージョン問題**
```toml
# 代替バージョン
inkwell = { git = "https://github.com/TheDan64/inkwell", branch = "master", features = ["llvm17-0"] }
```
### **リンクエラーの場合**
```bash
# pkg-configの確認
pkg-config --libs --cflags llvm
```
## 📞 ヘルプが必要な場合
1. **GitHub Issue**にコメント
2. **具体的なエラーメッセージ**を貼る
3. **実行したコマンド**を記載
例:
```
inkwellのビルドでエラーが発生しました。
エラー:
```
error: failed to run custom build command for `llvm-sys v170.0.1`
```
実行コマンド:
```
cargo build --features llvm
```
環境:
- OS: Ubuntu 22.04
- LLVM: 17.0.6
- Rust: 1.75.0
```
## ✅ 最初の成功確認
以下が動けば第一歩成功！
```bash
# ビルドが通る
cargo build --features llvm
# テストが実行できる（まだ失敗してOK）
cargo test --features llvm test_llvm
```
## 🎯 次のステップ
1. **context.rs**の実装
2. **compiler.rs**の実装
3. **return 42**の動作確認
詳細は[001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)を参照！
---
**Remember**: 完璧より進捗！最初は動くことが最優先です。🚀

60
docs/development/roadmap/phases/phase-9/llvm/issue/README.md Normal file
View File

@ -0,0 +1,60 @@
# 📚 LLVM PoC Issue ドキュメント一覧
## 🎯 Copilot様へ：最初に読むファイル
1. **[Quick-Start-Guide.md](./Quick-Start-Guide.md)** 🚀
- 今すぐ始める手順
- 環境セットアップ
- 最初のコミット方法
2. **[001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)** 📋
- **最初のIssue内容**
- 詳細な実装手順
- コード例とテストケース
3. **[Week1-Roadmap.md](./Week1-Roadmap.md)** 📅
- Week 1全体の計画
- Issue実装順序
- 成功条件
## 📖 参考資料
- **[MIR-Quick-Reference.md](./MIR-Quick-Reference.md)**
- MIR命令の説明
- LLVM変換パターン
- テスト用サンプル
- **[GitHub-Issue-Template.md](./GitHub-Issue-Template.md)**
- GitHub Issue作成用テンプレート
- ラベル設定
- マイルストーン
## 🔗 関連ドキュメント（上位階層）
- [AI大会議結果](../AI-Conference-LLVM-Results.md)
- [実装計画書](../Phase-9.78-Implementation-Plan.md)
- [Copilot依頼文書](../Copilot-Request-LLVM-PoC.md)
## 💬 重要メッセージ
**Copilot様へ**
Phase 8.6での素晴らしい成果（50.94倍高速化）に続き、LLVMでも革命的な性能向上を期待しています！
**開始方法**:
1. まず[Quick-Start-Guide.md](./Quick-Start-Guide.md)を読む
2. [001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)の実装を開始
3. 詰まったらすぐにGitHub Issueでヘルプ要請
**サポート体制**:
- AIチーム（Claude, Gemini, Codex）が全力サポート
- 技術的な質問は遠慮なく
- 小さな成功を積み重ねましょう
Let's make Nyash fly with LLVM! 🚀✨
---
**最終更新**: 2025年8月20日
**作成者**: Claude + moe-charm
**Phase**: 9.78 LLVM PoC

88
docs/development/roadmap/phases/phase-9/llvm/issue/Week1-Roadmap.md Normal file
View File

@ -0,0 +1,88 @@
# 📅 Week 1 ロードマップ: LLVM基盤構築
**期間**: 2025年8月21日〜8月27日
**目標**: LLVMバックエンドの基盤を構築し、最小限のプログラムを実行可能にする
## 🎯 Week 1の全体目標
「return 42」レベルの超シンプルなNyashプログラムが、LLVM経由で実行できる状態を達成する。
## 📋 Issue実装順序
### **Issue #001: inkwellセットアップとHello World** 🚀最初にこれ！
- **期間**: Day 1-3
- **内容**: 環境構築と「return 42」の実行
- **成功条件**: LLVMでコンパイルした実行ファイルが終了コード42を返す
- **ファイル**: [001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)
### **Issue #002: Const命令の実装**（#001完了後）
- **期間**: Day 3-4
- **内容**: MIR Const命令をLLVM定数に変換
- **対象**: Integer, Float, Bool定数
- **テスト**: `return 100`, `return 3.14`, `return true`
### **Issue #003: 基本的な型システム**（#002と並行可能）
- **期間**: Day 4-5
- **内容**: MIR型→LLVM型のマッピング実装
- **対象**: i32/i64, f64, bool, 関数型
- **成果**: type_cache の実装
### **Issue #004: ランタイム関数宣言**（#003完了後）
- **期間**: Day 5-6
- **内容**: nyash_runtime_* 関数の宣言
- **対象**: alloc, free, print_int（デバッグ用）
- **準備**: 最小限のCランタイム作成
### **Issue #005: Week 1統合テスト**（最終日）
- **期間**: Day 7
- **内容**: 複数の小さなプログラムでテスト
- **確認**: CI/CDでのLLVMビルド
- **文書**: Week 2への引き継ぎ事項
## 🔄 実装の流れ
```mermaid
graph LR
A[Issue #001<br/>環境構築] --> B[Issue #002<br/>Const実装]
A --> C[Issue #003<br/>型システム]
B --> D[Issue #004<br/>ランタイム]
C --> D
D --> E[Issue #005<br/>統合テスト]
```
## ✅ Week 1完了時のチェックリスト
- [ ] inkwellクレートが正常に動作
- [ ] 「return 42」がLLVM経由で実行可能
- [ ] Integer/Float/Bool定数がサポート済み
- [ ] 基本的な型変換が実装済み
- [ ] 最小限のランタイム関数が宣言済み
- [ ] 5個以上のテストケースがパス
## 📊 リスクと対策
| リスク | 対策 |
|--------|------|
| LLVM環境構築で詰まる | Docker環境を準備、LLVM17固定 |
| inkwellのAPIが複雑 | 公式exampleを参考に最小実装 |
| リンクエラー | まずは静的リンク、動的は後回し |
## 💡 成功のコツ
1. **小さく始める**: return 42が動けば大成功
2. **エラーを恐れない**: LLVMのエラーメッセージは親切
3. **IR出力を確認**: `--emit-llvm`でIRをダンプして確認
4. **既存コード活用**: VM/WASMバックエンドの構造を参考に
## 🎉 Week 1成功時の次のステップ
**Week 2では以下に取り組みます**：
- BinOp（四則演算）の実装
- Branch/Jumpによる制御フロー
- Box型の基本操作
- PHIノードの実装
---
**注意**: 各Issueは独立して実装可能ですが、推奨順序に従うとスムーズです。
ブロッカーがあれば即座にAIチームに相談してください！

267
docs/development/roadmap/phases/phase-9/phase9_51_wasm_jump_http_fixes.md Normal file
View File

@ -0,0 +1,267 @@
# Phase 9.51: WASM Jump/Branch実装とHTTPサーバー実用化 🚀
**優先度**: 🔴 **最高（実用性ブロッカー）**
**期間**: 1週間
**前提**: Phase 9 (PR #67) マージ済み
## 🎯 概要
Phase 9で実装されたWASM/AOTとHTTPサーバー機能に重大な制約があり、実用化を阻害しています。本issueではこれらを修正し、真の実用レベルに到達させます。
## 🔍 現在の問題
### 1. **WASM/AOT コンパイルエラー（最重要）**
```bash
# 現象
$ ./target/release/nyash --compile-wasm test_simple_loop.nyash
❌ WASM compilation error: Unsupported instruction: Jump { target: BasicBlockId(1) }
```
**原因**: `src/backend/wasm/codegen.rs`にJump/Branch命令が未実装
**影響**: **ループ・条件分岐を含む全プログラムがWASM/AOT化不可**
### 2. **HTTPServerBox listen()常に失敗**
```nyash
// 現象
server.bind("127.0.0.1", 8080) // ✅ true
server.listen(10) // ❌ always false
```
**原因**: `src/boxes/socket_box.rs`のlisten()実装が不完全
**影響**: HTTPサーバーが実際には動作しない
### 3. **エラーハンドリング脆弱性**
```bash
$ grep -n "unwrap()" src/boxes/http_server_box.rs | wc -l
26
```
**原因**: 26箇所のunwrap()使用
**影響**: 本番環境でパニック多発の可能性
## 📋 実装タスク
### Task 1: WASM Jump/Branch命令実装（2日）
**ファイル**: `src/backend/wasm/codegen.rs`
```rust
// 追加実装箇所（358行目付近）
MirInstruction::Jump { target } => {
// 無条件ジャンプ
// WASMのbr命令を使用
// ブロックスタック管理が必要
Ok(vec![
format!("br ${}", self.get_block_depth(target)?),
])
},
MirInstruction::Branch { cond, then_block, else_block } => {
// 条件分岐
// WASMのbr_if命令を使用
self.emit_value_load(cond)?;
Ok(vec![
"i32.eqz".to_string(),
format!("br_if ${}", self.get_block_depth(else_block)?),
format!("br ${}", self.get_block_depth(then_block)?),
])
},
```
**必要な補助実装**:
- ブロック深度管理（`get_block_depth`メソッド）
- ループ構造のblock/loop/end生成
- Phi命令の簡易実装（変数コピーで対応）
### Task 2: SocketBox listen()修正（1日）
**ファイル**: `src/boxes/socket_box.rs`
```rust
pub fn listen(&self, backlog: Box<dyn NyashBox>) -> Box<dyn NyashBox> {
let backlog_num = backlog.to_string_box().value.parse::<i32>().unwrap_or(128);
// 実際にlisten状態を管理
if let Some(ref listener) = *self.listener.lock().unwrap() {
// TcpListenerは既にlisten状態
// 内部状態を更新
*self.status.lock().unwrap() = SocketStatus::Listening;
Box::new(BoolBox::new(true))
} else {
Box::new(BoolBox::new(false))
}
}
```
### Task 3: エラーハンドリング改善（2日）
**対象ファイル**:
- `src/boxes/http_server_box.rs`
- `src/boxes/socket_box.rs`
- `src/boxes/http_message_box.rs`
**変更例**:
```rust
// Before
let listener = self.listener.lock().unwrap();
// After
let listener = match self.listener.lock() {
Ok(l) => l,
Err(_) => return Box::new(StringBox::new("Error: Failed to acquire lock")),
};
```
### Task 4: HTTPサーバー実用化（2日）
**ファイル**: `src/boxes/http_server_box.rs`
1. **スレッドプール実装**
```rust
use std::sync::mpsc;
use std::thread::JoinHandle;
struct ThreadPool {
workers: Vec<Worker>,
sender: mpsc::Sender<Job>,
}
impl ThreadPool {
fn new(size: usize) -> Self {
// 固定サイズのワーカープール
}
}
```
2. **適切なシャットダウン**
```rust
pub fn stop(&self) -> Box<dyn NyashBox> {
*self.running.lock().unwrap() = false;
// グレースフルシャットダウン
// 全コネクションの終了待機
}
```
### Task 5: テストケース追加（1日）
**新規テストファイル**:
1. `test_wasm_loop.nyash`
```nyash
// WASMループテスト
local sum, i
sum = 0
i = 0
loop (i < 10) {
sum = sum + i
i = i + 1
}
print("Sum: " + sum) // Expected: 45
```
2. `test_http_server_real.nyash`
```nyash
// 実用HTTPサーバーテスト
static box Main {
main() {
local server = new HTTPServerBox()
// ルート設定
server.route("/", "home")
server.route("/api/health", "health")
// サーバー起動
if (server.bind("0.0.0.0", 8080)) {
if (server.listen(10)) {
print("Server started on http://0.0.0.0:8080")
server.start()
}
}
}
home(req) {
return "<h1>Nyash Server Running!</h1>"
}
health(req) {
return "{\"status\":\"healthy\"}"
}
}
```
## 🎯 完了条件
1. **WASM/AOT成功**
```bash
$ ./target/release/nyash --compile-wasm test_wasm_loop.nyash
✅ WASM compilation completed successfully!
$ ./target/release/nyash --benchmark --iterations 100
WASM: XX.XXms (13.5x faster than interpreter) ← 目標達成
```
2. **HTTPサーバー実動作**
```bash
$ ./target/release/nyash test_http_server_real.nyash &
Server started on http://0.0.0.0:8080
$ curl http://localhost:8080/
<h1>Nyash Server Running!</h1>
$ curl http://localhost:8080/api/health
{"status":"healthy"}
```
3. **エラーハンドリング**
- unwrap()使用箇所: 26 → 5以下
- パニックフリーな実行
## 📊 性能目標
- **WASM実行**: 現在11.5倍 → **13.5倍以上**
- **HTTPサーバー**: 100 req/sec以上
- **起動時間**: 50ms以下
## 🔧 実装のヒント
### WASMブロック管理
```rust
struct WasmCodeGen {
// 既存フィールド
block_stack: Vec<BlockInfo>, // 追加
}
struct BlockInfo {
block_type: BlockType, // Loop, Block, If
label: String,
depth: usize,
}
```
### デバッグ用出力
```rust
// MIR → WASM変換時のデバッグ
if self.debug {
println!("MIR: {:?} -> WASM: {:?}", instruction, wasm_code);
}
```
## 📝 参考資料
- [WebAssembly Specification - Control Instructions](https://webassembly.github.io/spec/core/syntax/instructions.html#control-instructions)
- [wasmtime compile documentation](https://docs.wasmtime.dev/cli-compile.html)
- Rust std::thread::ThreadPool実装例
## 🎉 期待される成果
Phase 9.51完了により、Nyashは：
- **実用的なWebアプリケーション開発**が可能に
- **高速なAOT実行ファイル配布**が実現
- **本番環境での安定動作**を保証
Everything is Box哲学を守りながら、実用性を達成します！🐱
---
**担当**: Copilot様
**レビュー**: Claude様
**作成日**: 2025-08-14

250
docs/development/roadmap/phases/phase-9/phase9_5_http_server_validation.md Normal file
View File

@ -0,0 +1,250 @@
# 🌐 Phase 9.5: HTTPサーバー実用テスト（AOT検証）
## 📋 Summary
AOT実装完了後の複雑アプリケーション検証。並行処理・メモリ管理・実用性能測定を通じて、Nyashの実用レベル到達を実証する。
## 🎯 実装目標
```bash
# Phase 9完了後の目標
nyash --compile-native http_server.nyash -o http_server.exe # AOTサーバー生成
./http_server.exe --port 8080 # 高性能HTTPサーバー起動
curl http://localhost:8080/api/status # 実用API動作確認
# 検証内容
- 同時100接続でメモリリークなし
- fini()システム確実動作（I/Oハンドル解放）
- AOT環境での真の性能測定
```
## 🔧 技術的実装詳細
### 1. HTTPサーバー基本構造
```nyash
box HTTPServer {
init { socket, clients, handlers, running }
pack(port) {
me.socket = new SocketBox()
me.clients = new ArrayBox()
me.handlers = new MapBox()
me.running = true
me.socket.bind("0.0.0.0", port)
me.socket.listen(128)
}
start() {
loop(me.running) {
local client = me.socket.accept()
me.clients.push(client)
nowait me.handleClient(client) // 非同期並行処理
}
}
handleClient(client) {
local request = client.readRequest()
local response = me.processRequest(request)
client.sendResponse(response)
// 重要: 確実なリソース解放
me.clients.remove(client)
client.fini()
}
processRequest(request) {
local path = request.getPath()
local handler = me.handlers.get(path)
if (handler != null) {
return handler.handle(request)
} else {
return me.create404Response()
}
}
}
```
### 2. ルーティング・ハンドラーシステム
```nyash
box RouteHandler {
init { pattern, callback }
pack(pattern, callback) {
me.pattern = pattern
me.callback = callback
}
handle(request) {
return me.callback.call(request)
}
}
// 使用例
local server = new HTTPServer(8080)
server.route("/api/status", new StatusHandler())
server.route("/api/users/:id", new UserHandler())
server.start()
```
### 3. メモリ管理検証ポイント
```nyash
box ConnectionManager {
init { connections, maxConnections }
pack(maxConnections) {
me.connections = new MapBox()
me.maxConnections = maxConnections
}
addConnection(clientId, client) {
if (me.connections.size() >= me.maxConnections) {
// 古い接続をweak参照で自動解放
me.cleanupOldConnections()
}
me.connections.set(clientId, client)
}
cleanupOldConnections() {
// weak参照による自動null化テスト
local toRemove = new ArrayBox()
me.connections.forEach((id, conn) => {
if (conn.isDisconnected()) {
toRemove.push(id)
conn.fini() // 確実な解放
}
})
toRemove.forEach((id) => {
me.connections.remove(id)
})
}
}
```
## 📊 検証ポイント詳細
### 並行処理性能
```bash
# 負荷テストコマンド
ab -n 10000 -c 100 http://localhost:8080/api/test # Apache Bench
wrk -t12 -c400 -d30s http://localhost:8080/ # Modern HTTP benchmarking
```
**検証項目**:
- **同時接続処理**: 100接続同時処理
- **スループット**: リクエスト/秒測定
- **レイテンシ**: 応答時間分布
- **リソース使用**: CPU・メモリ使用率
### メモリ管理検証
```nyash
// ストレステスト実装
box MemoryStressTest {
runConnectionStress() {
// 1000回接続・切断を繰り返し
loop(1000) {
local client = me.createClient()
client.connect()
client.sendRequest("/api/test")
client.disconnect()
client.fini() // 明示的解放
}
// メモリリークチェック
local memUsage = DEBUG.memoryReport()
assert(memUsage.leaks == 0)
}
}
```
### I/Oリソース管理
```nyash
box ResourceTracker {
init { openSockets, openFiles }
trackResource(resource) {
me.openSockets.add(resource)
}
verifyCleanup() {
// 全リソースが正しくfini()されているか確認
assert(me.openSockets.size() == 0)
assert(me.openFiles.size() == 0)
}
}
```
## 🎯 実装ステップ（2週間）
### Week 1: HTTPサーバー基本実装
- [ ] SocketBox・HTTP基本プロトコル実装
- [ ] HTTPServer・RouteHandlerクラス実装
- [ ] 基本GET/POST対応
- [ ] 単一接続での動作確認
### Week 2: 並行処理・負荷テスト
- [ ] nowait/await非同期処理統合
- [ ] 同時接続管理システム
- [ ] メモリ管理・リソース解放検証
- [ ] 負荷テスト・ベンチマーク実装
## 📈 性能測定目標
| 指標 | 目標値 | 測定方法 |
|------|--------|----------|
| **同時接続数** | 100+ | Apache Bench |
| **スループット** | 1000+ req/s | wrk benchmark |
| **応答時間** | <10ms (P95) | レイテンシ分布 |
| **メモリ使用** | リークなし | 長時間実行テスト |
| **リソース解放** | 100%解放 | fini()追跡 |
## ✅ Acceptance Criteria
### 機能要件
- [ ] HTTPサーバーが安定動作
- [ ] REST API（GET/POST/PUT/DELETE）対応
- [ ] ルーティング・ミドルウェア機能
- [ ] 静的ファイル配信機能
### 性能要件
- [ ] 同時100接続でクラッシュなし
- [ ] 1000 req/s以上のスループット
- [ ] レスポンス時間P95<10ms
- [ ] 24時間連続稼働でメモリリークなし
### 品質要件
- [ ] fini()システム100%動作
- [ ] weak参照自動null化確認
- [ ] I/Oリソース確実解放
- [ ] 例外経路でのリソース管理
## 🚀 期待される効果
### 実用性実証
- **配布可能サーバー**: `http_server.exe`として実用レベル
- **プロダクション検証**: 実際の負荷でのメモリ管理確認
- **AOT価値実証**: 真の高性能実行環境での検証
### 技術的価値
- **複雑メモリ管理**: Server→Clients→Requests階層構造
- **並行処理実証**: nowait/awaitの実用性能確認
- **Everything is Box**: 複雑アプリでのBox哲学実証
### デモ・広報価値
- **視覚的インパクト**: 動作するHTTPサーバーの強力デモ
- **実用性アピール**: 「おもちゃ言語」ではない実用性
- **性能実証**: 数値での性能証明
## 📖 References
- docs/予定/native-plan/copilot_issues.txt（Phase 9.5詳細）
- docs/予定/native-plan/issues/phase9_aot_wasm_implementation.md（Phase 9基盤）
- docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md（kilo基盤）
- [HTTP/1.1 Specification](https://tools.ietf.org/html/rfc7230)
- [Apache Bench Documentation](https://httpd.apache.org/docs/2.4/programs/ab.html)
---
**💡 Tip**: kiloで確立したメモリ管理基盤を、より複雑な並行処理環境で実証する重要なマイルストーンです。
最終更新: 2025-08-14
作成者: Claude（実用優先戦略）

372
docs/development/roadmap/phases/phase-9/phase9_75_socketbox_arc_mutex_redesign.md Normal file
View File

@ -0,0 +1,372 @@
# 🔧 Phase 9.75: SocketBox Arc<Mutex>責務一元化 - 実装ガイド
## 📅 実施期間: 2025-08 (Phase 9.7完了後)
## 👥 担当: Copilot様
## 🎯 スコープ: SocketBoxのみ（最優先対応）
## 🚨 問題の背景
### 現在のSocketBox実装問題
SocketBoxにおいて「責務の二重化」により以下の問題が発生：
1. **状態保持失敗**: `bind()`後に`isServer()`がfalseを返す
2. **デッドロック危険性**: Box内部とインタープリターの二重ロック
3. **複雑性**: デバッグ困難・保守性低下
### 根本原因
```rust
// 🚨 現在の問題設計
pub struct SocketBox {
listener: Arc<Mutex<Option<TcpListener>>>, // 内部ロック
is_server: Arc<Mutex<bool>>, // 内部ロック
}
// + インタープリター側: Arc<Mutex<dyn NyashBox>> // 外部ロック
```
## 🎯 実装目標
### 新設計アーキテクチャ
```rust
// ✅ 目標設計: 純粋データコンテナ
pub struct SocketBox {
base: BoxBase,
listener: Option<TcpListener>,
stream: Option<TcpStream>,
is_server: bool,
is_connected: bool,
}
// インタープリターが Arc<Mutex<dyn NyashBox>> で一元管理
```
### 期待される効果
- ✅ 状態保持問題の完全解決
- ✅ デッドロック根絶
- ✅ デバッグ容易性向上
- ✅ パフォーマンス改善
## 📋 実装手順
### Step 1: 現在のSocketBox分析（30分）
#### 1-1: 問題箇所の特定
```bash
# 内部Arc<Mutex>使用箇所を全特定
grep -n "Arc<Mutex<" src/boxes/socket_box.rs
```
#### 1-2: 影響範囲調査
- `src/boxes/socket_box.rs` - メイン実装
- `src/boxes/http_server_box.rs` - SocketBox使用
- `src/interpreter/` - インタープリター統合
- テストファイル - 既存テスト
### Step 2: 新SocketBox実装（2時間）
#### 2-1: 構造体定義の変更
```rust
// src/boxes/socket_box.rs
#[derive(Debug)]
pub struct SocketBox {
base: BoxBase,
// ✅ シンプルなフィールド（Arc<Mutex>除去）
listener: Option<TcpListener>,
stream: Option<TcpStream>,
is_server: bool,
is_connected: bool,
// 削除: Arc<Mutex<...>> フィールドすべて
}
```
#### 2-2: メソッド実装の変更
```rust
impl SocketBox {
pub fn new() -> Self {
Self {
base: BoxBase::new(),
listener: None,
stream: None,
is_server: false,
is_connected: false,
}
}
// ✅ 新bind実装: &mut selfでシンプルに
pub fn bind(&mut self, address: Box<dyn NyashBox>, port: Box<dyn NyashBox>) -> Box<dyn NyashBox> {
let addr_str = address.to_string_box().value;
let port_str = port.to_string_box().value;
let socket_addr = format!("{}:{}", addr_str, port_str);
match TcpListener::bind(socket_addr) {
Ok(listener) => {
self.listener = Some(listener);
self.is_server = true; // 直接代入！
Box::new(BoolBox::new(true))
}
Err(_) => Box::new(BoolBox::new(false))
}
}
// ✅ 新isServer実装: &selfでシンプルに
pub fn is_server(&self) -> Box<dyn NyashBox> {
Box::new(BoolBox::new(self.is_server))
}
}
```
#### 2-3: Clone実装の簡素化
```rust
impl Clone for SocketBox {
fn clone(&self) -> Self {
// ⚠️ 注意: TcpListenerはClone不可
// → 新しいインスタンスを適切に作成
Self {
base: BoxBase::new(),
listener: None, // リスナーは複製できない
stream: None,
is_server: false, // デフォルト状態
is_connected: false,
}
}
}
```
### Step 3: インタープリター統合確認（1時間）
#### 3-1: メソッド呼び出しの修正
インタープリターでの`&mut`アクセスが必要な箇所：
```rust
// インタープリター内での変更が必要な箇所例
// execute_method内で &mut アクセスを確保
```
#### 3-2: set_field実装の確認
```rust
// instance.rsでの適切なフィールド更新確認
```
### Step 4: テストスイート作成（1時間）
#### 4-1: 状態保持テスト
```nyash
// tests/socket_box_state_persistence.nyash
// 🎯 最重要テスト: 状態保持の確認
static box SocketBoxStateTest {
init { console }
main() {
me.console = new ConsoleBox()
// テスト1: 基本的な状態保持
me.testBasicStatePersistence()
// テスト2: 複数操作での状態確認
me.testMultipleOperations()
me.console.log("🎉 All SocketBox state tests passed!")
}
testBasicStatePersistence() {
me.console.log("🔍 Testing basic state persistence...")
local server = new SocketBox()
// bind前の状態確認
local beforeBind = server.isServer()
me.console.log("Before bind: " + beforeBind.toString())
assert(beforeBind.value == false)
// bind実行
local bindResult = server.bind("127.0.0.1", 8080)
me.console.log("Bind result: " + bindResult.toString())
assert(bindResult.value == true)
// 🚨 最重要チェック: bind後の状態保持
local afterBind = server.isServer()
me.console.log("After bind: " + afterBind.toString())
assert(afterBind.value == true) // これが失敗していた！
me.console.log("✅ Basic state persistence test passed!")
}
testMultipleOperations() {
me.console.log("🔍 Testing multiple operations...")
local server = new SocketBox()
// 複数回の状態確認
server.bind("127.0.0.1", 8081)
local check1 = server.isServer()
local check2 = server.isServer()
local check3 = server.isServer()
assert(check1.value == true)
assert(check2.value == true)
assert(check3.value == true)
me.console.log("✅ Multiple operations test passed!")
}
}
```
#### 4-2: 機能テスト
```nyash
// tests/socket_box_functionality.nyash
// 機能テスト（bind, toString, 基本API）
static box SocketBoxFunctionalityTest {
init { console }
main() {
me.console = new ConsoleBox()
// 基本機能テスト
me.testBindSuccess()
me.testBindFailure()
me.testToString()
me.console.log("🎉 All functionality tests passed!")
}
testBindSuccess() {
local server = new SocketBox()
local result = server.bind("127.0.0.1", 8082)
assert(result.value == true)
me.console.log("✅ Bind success test passed!")
}
testBindFailure() {
local server = new SocketBox()
// 不正なポートでバインド失敗テスト
local result = server.bind("invalid", "invalid")
assert(result.value == false)
me.console.log("✅ Bind failure test passed!")
}
testToString() {
local server = new SocketBox()
local str = server.toString()
me.console.log("ToString: " + str)
// 基本的な文字列表現チェック
assert(str.contains("SocketBox"))
me.console.log("✅ ToString test passed!")
}
}
```
#### 4-3: エッジケーステスト
```nyash
// tests/socket_box_edge_cases.nyash
static box SocketBoxEdgeCaseTest {
init { console }
main() {
me.console = new ConsoleBox()
// Clone動作テスト
me.testCloneBehavior()
me.console.log("🎉 All edge case tests passed!")
}
testCloneBehavior() {
local original = new SocketBox()
original.bind("127.0.0.1", 8083)
// Cloneの動作確認（新設計では状態はリセット）
local cloned = original.clone()
local clonedIsServer = cloned.isServer()
// 新設計: cloneは新しいインスタンス
assert(clonedIsServer.value == false)
me.console.log("✅ Clone behavior test passed!")
}
}
```
### Step 5: 実行・検証（30分）
#### 5-1: テスト実行
```bash
# ビルド確認
cargo build --release
# 状態保持テスト（最重要）
./target/release/nyash tests/socket_box_state_persistence.nyash
# 機能テスト
./target/release/nyash tests/socket_box_functionality.nyash
# エッジケーステスト
./target/release/nyash tests/socket_box_edge_cases.nyash
```
#### 5-2: HTTPServerBox互換性確認
```bash
# HTTPServerBoxも正常動作するかチェック
./target/release/nyash tests/test_http_server_simple.nyash
```
## 📚 参照ドキュメント
### 🎯 必読ドキュメント
1. **[Socket問題詳細分析](../../説明書/reference/box-design/implementation-notes/socket-box-problem.md)**
- 根本原因の技術的詳細
- 現在の問題箇所の特定
2. **[メモリ管理設計](../../説明書/reference/box-design/memory-management.md)**
- Arc<Mutex>一元管理の原則
- 正しいBox実装パターン
3. **[Box設計原則](../../説明書/reference/box-design/everything-is-box.md)**
- Everything is Box哲学
- 統一的なBox実装
### 📋 実装参考資料
- `src/boxes/socket_box.rs` - 現在の実装
- `src/box_trait.rs` - NyashBoxトレイト定義
- `src/interpreter/expressions.rs` - メソッド呼び出し処理
## ✅ 成功基準
### 🎯 定量的指標
- [ ] 状態保持テスト: 100%成功
- [ ] 内部Arc<Mutex>使用: 0箇所
- [ ] 既存テスト: 回帰なし
- [ ] ビルドエラー: 0件
### 🌟 定性的指標
- [ ] コードの可読性向上
- [ ] デバッグメッセージの簡素化
- [ ] 実装の理解しやすさ
## 🚨 注意事項
### ⚠️ 破壊的変更の管理
- NyashBoxトレイトは変更しない
- 外部APIは互換性を保つ
- 段階的にテストしながら進める
### 🔍 デバッグ支援
- 重要な箇所にログ出力を残す
- テスト失敗時の詳細情報を出力
### 🎯 次のステップへの準備
- SocketBox完了後、HTTPServerBoxに展開
- 同じパターンで他のBox型も修正可能
## 📞 サポート
### ❓ 質問・相談
- 実装中の技術的質問は遠慮なく
- 設計判断で迷った場合は相談
### 🤝 協力体制
- Claude: 設計指針・技術サポート
- Copilot: 実装・テスト自動化
---
**🎯 最初の成功例として、SocketBoxでの完全解決を目指します！**

360
docs/development/roadmap/phases/phase-9/phase9_75b_remaining_boxes_arc_mutex_redesign.md Normal file
View File

@ -0,0 +1,360 @@
# 🔧 Phase 9.75-B: 残り14個のBox型 Arc<Mutex>責務一元化 - 実装ガイド
## 📅 実施期間: 2025-08 (Phase 9.75-A完了後)
## 👥 担当: Copilot様
## 🎯 スコープ: SocketBox修正パターンの他Box型への展開
## 🎉 Phase 9.75-A成功パターンの適用
### ✅ **確立された修正パターン**
```rust
// Before: 問題パターン
struct SomeBox {
field: Arc<Mutex<T>>, // 内部ロック
}
// + 外部: Arc<Mutex<dyn NyashBox>>
// After: 解決パターン
struct SomeBox {
field: RwLock<T>, // シンプル内部可変性
}
// 外部: Arc<Mutex<dyn NyashBox>> (変更なし)
```
## 📊 対象Box型の優先順位分析
### 🔴 **最優先グループ（1週間）**
#### HTTPServerBox - SocketBox依存の緊急対応
```rust
// 現在の問題構造
pub struct HTTPServerBox {
socket: Arc<Mutex<Option<SocketBox>>>, // 内部ロック
routes: Arc<Mutex<HashMap<String, Box<dyn NyashBox>>>>,
middleware: Arc<Mutex<Vec<Box<dyn NyashBox>>>>,
connections: Arc<Mutex<Vec<TcpStream>>>,
running: Arc<Mutex<bool>>,
}
// 修正目標
pub struct HTTPServerBox {
socket: RwLock<Option<SocketBox>>, // RwLock化
routes: RwLock<HashMap<String, Box<dyn NyashBox>>>,
middleware: RwLock<Vec<Box<dyn NyashBox>>>,
connections: RwLock<Vec<TcpStream>>,
running: RwLock<bool>,
}
```
#### ArrayBox - 基本コレクション型
```rust
// 現在の問題構造
pub struct ArrayBox {
data: Arc<Mutex<Vec<Box<dyn NyashBox>>>>,
}
// 修正目標
pub struct ArrayBox {
data: RwLock<Vec<Box<dyn NyashBox>>>,
}
```
### 🟠 **高優先グループ（1週間）**
#### MapBox - 基本コレクション型
```rust
// 現在の問題構造
pub struct MapBox {
data: Arc<Mutex<HashMap<String, Box<dyn NyashBox>>>>,
}
// 修正目標
pub struct MapBox {
data: RwLock<HashMap<String, Box<dyn NyashBox>>>,
}
```
#### BufferBox - バイナリデータ操作
```rust
// 現在の問題構造
pub struct BufferBox {
data: Arc<Mutex<Vec<u8>>>,
}
// 修正目標
pub struct BufferBox {
data: RwLock<Vec<u8>>,
}
```
### 🟡 **中優先グループ（1週間）**
#### DebugBox - デバッグ支援（複数フィールド）
```rust
// 現在の問題構造
pub struct DebugBox {
tracking_enabled: Arc<Mutex<bool>>,
tracked_boxes: Arc<Mutex<HashMap<String, TrackedBoxInfo>>>,
breakpoints: Arc<Mutex<Vec<String>>>,
call_stack: Arc<Mutex<Vec<CallInfo>>>,
}
// 修正目標
pub struct DebugBox {
tracking_enabled: RwLock<bool>,
tracked_boxes: RwLock<HashMap<String, TrackedBoxInfo>>,
breakpoints: RwLock<Vec<String>>,
call_stack: RwLock<Vec<CallInfo>>,
}
```
#### StreamBox - ストリーム操作
```rust
// 現在の問題構造
pub struct StreamBox {
buffer: Arc<Mutex<Vec<u8>>>,
position: Arc<Mutex<usize>>,
}
// 修正目標
pub struct StreamBox {
buffer: RwLock<Vec<u8>>,
position: RwLock<usize>,
}
```
### 🟢 **低優先グループ（3日）**
#### RandomBox, JSONBox, EguiBox, SimpleIntentBox
```rust
// 各Boxとも同じパターンで修正
Arc<Mutex<T>> → RwLock<T>
```
## 📋 段階的実装手順
### Step 1: 最優先グループ実装（1週間）
#### 1-1: HTTPServerBox修正（3日）
```rust
// 修正手順
1. Arc<Mutex<>>をRwLock<>に変更
2. .lock()を.read()/.write()に変更
3. Cloneメソッドの適切な修正
4. テストによる動作確認
```
**重要注意点**:
- SocketBoxとの連携確認必須
- HTTPサーバー機能の回帰テスト必要
#### 1-2: ArrayBox修正（2日）
```rust
// 実装例
impl ArrayBox {
pub fn push(&self, item: Box<dyn NyashBox>) -> Box<dyn NyashBox> {
self.data.write().unwrap().push(item);
Box::new(BoolBox::new(true))
}
pub fn get(&self, index: usize) -> Box<dyn NyashBox> {
let data = self.data.read().unwrap();
// ... 実装
}
}
```
#### 1-3: テストスイート実行
```nyash
// HTTPServerBox互換性テスト
local server = new HTTPServerBox()
server.bind("127.0.0.1", 8080)
assert(server.isRunning() == false) // 初期状態確認
// ArrayBox基本操作テスト
local arr = new ArrayBox()
arr.push("test")
assert(arr.length() == 1)
assert(arr.get(0) == "test")
```
### Step 2: 高優先グループ実装（1週間）
#### 2-1: MapBox修正（3日）
```rust
// HashMap操作の適切なRwLock化
impl MapBox {
pub fn set(&self, key: String, value: Box<dyn NyashBox>) -> Box<dyn NyashBox> {
self.data.write().unwrap().insert(key, value);
Box::new(BoolBox::new(true))
}
pub fn get(&self, key: &str) -> Box<dyn NyashBox> {
let data = self.data.read().unwrap();
// ... 実装
}
}
```
#### 2-2: BufferBox修正（2日）
- バイナリデータ操作の確実性確保
- 大容量データ処理時のパフォーマンス確認
#### 2-3: 統合テスト
```nyash
// MapBox状態保持テスト
local map = new MapBox()
map.set("key1", "value1")
assert(map.get("key1") == "value1") // 状態保持確認
// BufferBox操作テスト
local buffer = new BufferBox()
buffer.write("Hello")
assert(buffer.read() == "Hello")
```
### Step 3: 中優先グループ実装（1週間）
#### 3-1: DebugBox修正（4日）
```rust
// 複数フィールドの同期修正
impl DebugBox {
pub fn startTracking(&self) -> Box<dyn NyashBox> {
*self.tracking_enabled.write().unwrap() = true;
self.call_stack.write().unwrap().clear();
Box::new(BoolBox::new(true))
}
pub fn trackBox(&self, box_obj: Box<dyn NyashBox>, desc: String) -> Box<dyn NyashBox> {
if *self.tracking_enabled.read().unwrap() {
let info = TrackedBoxInfo { /* ... */ };
self.tracked_boxes.write().unwrap().insert(desc, info);
}
Box::new(BoolBox::new(true))
}
}
```
#### 3-2: StreamBox修正（2日）
- ストリーム位置管理の正確性確保
- 並行読み書きアクセステスト
#### 3-3: 高負荷テスト
```nyash
// DebugBox並行アクセステスト
local debug = new DebugBox()
debug.startTracking()
// 複数オブジェクト同時追跡
loop(100) {
debug.trackBox(new StringBox("test"), "object_" + i)
}
```
### Step 4: 低優先グループ実装（3日）
#### 4-1: 残りBox型の機械的修正
- RandomBox: `seed: Arc<Mutex<u64>>` → `RwLock<u64>`
- JSONBox: `value: Arc<Mutex<Value>>` → `RwLock<Value>`
- EguiBox: `app_state: Arc<Mutex<Box<dyn Any + Send>>>` → `RwLock<Box<dyn Any + Send>>`
- SimpleIntentBox: `listeners: Arc<Mutex<HashMap<...>>>` → `RwLock<HashMap<...>>`
#### 4-2: 全体統合テスト
```bash
# 全Box型の基本動作確認
./target/release/nyash tests/all_boxes_basic_test.nyash
# 回帰テストスイート
./target/release/nyash tests/regression_test_suite.nyash
```
## 🤖 Copilot協力期待
### 自動化可能な作業
1. **パターン検出**: `grep -r "Arc<Mutex<" src/boxes/` の結果を全修正
2. **機械的変換**:
```rust
Arc<Mutex<T>> → RwLock<T>
.lock().unwrap() → .read().unwrap() / .write().unwrap()
Arc::clone(&field) → field (Clone実装で)
```
3. **テストケース生成**: 各Box型の基本操作テスト自動生成
### 手動確認が必要な箇所
1. **複雑な状態管理**: DebugBox, P2PBoxの相互依存
2. **パフォーマンス影響**: 大容量データ操作Box
3. **外部依存**: EguiBox, FileBoxの外部ライブラリ連携
## ✅ 成功基準
### 定量的指標
- [ ] 全Box型で内部Arc<Mutex>: 0箇所
- [ ] 既存テストスイート: 100%パス
- [ ] パフォーマンス劣化: 5%以内
- [ ] メモリ使用量: 変化なしまたは改善
### 定性的指標
- [ ] コードの可読性向上
- [ ] デバッグの容易性向上
- [ ] 新Box実装時の混乱防止
## 🚨 リスク管理
### 高リスク要素
1. **HTTPServerBox**: SocketBox依存で複雑
2. **DebugBox**: 4つのフィールドの同期
3. **P2PBox**: type aliasの特殊構造
### 対策
- 段階的テスト実施
- 各Boxの独立性確保
- 既存機能への影響最小化
## 📈 期待される効果
### 即座の効果
- デッドロック完全根絶
- 状態保持の信頼性向上
- パフォーマンス改善
### 長期的効果
- 新Box実装の簡素化
- 保守コストの削減
- Everything is Box哲学の強化
## 🎯 Phase 9.75完了条件
```rust
// すべてのBox型で以下が達成されること
pub struct AnyBox {
// ✅ Arc<Mutex<>>が0個
field1: RwLock<T1>,
field2: RwLock<T2>,
// ❌ Arc<Mutex<T>>は禁止
}
impl Clone for AnyBox {
fn clone(&self) -> Self {
// ✅ 状態保持Clone実装
let field1_val = *self.field1.read().unwrap();
Self {
base: BoxBase::new(),
field1: RwLock::new(field1_val),
}
}
}
```
### 最終検証
```bash
# Arc<Mutex>完全根絶確認
grep -r "Arc<Mutex<" src/boxes/ | wc -l # → 0
# 全Box型統合テスト
./target/release/nyash tests/phase_9_75_complete_validation.nyash
# → 全テスト成功
```
---
**🎯 SocketBoxでの成功パターンを体系的に全Box型に適用し、Nyashの基盤を盤石にします！**

292
docs/development/roadmap/phases/phase-9/phase9_75c_remaining_boxes_arc_mutex_final.md Normal file
View File

@ -0,0 +1,292 @@
# 🔧 Phase 9.75-C: 残り10個のBox型 Arc<Mutex>→RwLock最終変換
## 📅 実施期間: 2025-08-15 (PR #87 SocketBox修正完了後)
## 👥 担当: Copilot様
## 🎯 スコープ: 残りArc<Mutex>使用Box型の完全RwLock化
## 🎉 Phase 9.75-A&B成功確認
### ✅ **修正完了済みBox型**
- **SocketBox**: ✅ PR #87で完全修正・状態保持問題解決
- **ArrayBox**: ✅ PR #89で修正完了
- **MapBox**: ✅ PR #89で修正完了
- **BufferBox**: ✅ PR #89で修正完了
- **StreamBox**: ✅ PR #89で修正完了
- **DebugBox**: ✅ PR #89 + 追加修正で完了
### 🎯 **確立された修正パターン（PR #87実証済み）**
```rust
// Before: Arc<Mutex>二重ロック問題
struct SomeBox {
field: Arc<Mutex<T>>, // 内部ロック
}
// + 外部: Arc<Mutex<dyn NyashBox>>
// After: RwLock単一責務（状態保持確実）
struct SomeBox {
field: RwLock<T>, // シンプル内部可変性
}
// 外部: Arc<Mutex<dyn NyashBox>> (変更なし)
```
## 📊 残りBox型の緊急度分析
### 🔴 **最高優先（HTTP/ネットワーク系）** - 1週間
SocketBox依存・実用性に直結
#### HTTPServerBox
```rust
// 現在の問題構造
pub struct HTTPServerBox {
socket: Arc<Mutex<Option<SocketBox>>>, // 内部ロック
routes: Arc<Mutex<HashMap<String, Box<dyn NyashBox>>>>,
middleware: Arc<Mutex<Vec<Box<dyn NyashBox>>>>,
connections: Arc<Mutex<Vec<TcpStream>>>,
running: Arc<Mutex<bool>>,
}
// 修正目標（PR #87パターン適用）
pub struct HTTPServerBox {
socket: RwLock<Option<SocketBox>>, // RwLock化
routes: RwLock<HashMap<String, Box<dyn NyashBox>>>,
middleware: RwLock<Vec<Box<dyn NyashBox>>>,
connections: RwLock<Vec<TcpStream>>,
running: RwLock<bool>,
}
```
#### P2PBox
```rust
// 現在の問題構造
pub struct P2PBox {
node_id: Arc<Mutex<String>>,
peers: Arc<Mutex<HashMap<String, Box<dyn NyashBox>>>>,
world: Arc<Mutex<Box<dyn NyashBox>>>,
message_handlers: Arc<Mutex<HashMap<String, Box<dyn NyashBox>>>>,
}
// 修正目標
pub struct P2PBox {
node_id: RwLock<String>,
peers: RwLock<HashMap<String, Box<dyn NyashBox>>>,
world: RwLock<Box<dyn NyashBox>>,
message_handlers: RwLock<HashMap<String, Box<dyn NyashBox>>>,
}
```
### 🟠 **高優先（通信・Intent系）** - 3日
#### IntentBox & SimpleIntentBox
```rust
// IntentBox修正目標
pub struct IntentBox {
intent_type: RwLock<String>, // Arc<Mutex<String>> → RwLock<String>
data: RwLock<Box<dyn NyashBox>>, // Arc<Mutex<Box<dyn NyashBox>>> → RwLock<Box<dyn NyashBox>>
}
// SimpleIntentBox修正目標
pub struct SimpleIntentBox {
listeners: RwLock<HashMap<String, Box<dyn NyashBox>>>, // Arc<Mutex<HashMap<...>>> → RwLock<HashMap<...>>
}
```
### 🟡 **中優先（基本型・ユーティリティ）** - 3日
#### JSONBox & RandomBox
```rust
// JSONBox修正目標
pub struct JSONBox {
value: RwLock<Value>, // Arc<Mutex<Value>> → RwLock<Value>
}
// RandomBox修正目標
pub struct RandomBox {
seed: RwLock<u64>, // Arc<Mutex<u64>> → RwLock<u64>
}
```
### 🟢 **低優先（特殊用途）** - 2日
#### EguiBox & FileBox & FutureBox
```rust
// EguiBox修正目標
pub struct EguiBox {
app_state: RwLock<Box<dyn Any + Send>>, // Arc<Mutex<Box<dyn Any + Send>>> → RwLock<Box<dyn Any + Send>>
}
// FileBox修正目標
pub struct FileBox {
content: RwLock<Vec<u8>>, // Arc<Mutex<Vec<u8>>> → RwLock<Vec<u8>>
metadata: RwLock<FileMetadata>, // Arc<Mutex<FileMetadata>> → RwLock<FileMetadata>
}
// FutureBox修正目標
pub struct FutureBox {
state: RwLock<FutureState>, // Arc<Mutex<FutureState>> → RwLock<FutureState>
result: RwLock<Option<Box<dyn NyashBox>>>, // Arc<Mutex<Option<Box<dyn NyashBox>>>> → RwLock<Option<Box<dyn NyashBox>>>
}
```
## 📋 Copilot実装手順
### Step 1: HTTPServerBox & P2PBox（最優先・3日）
#### 1-1: HTTPServerBox修正
```rust
// 実装手順
1. 全Arc<Mutex<T>>をRwLock<T>に変更
2. .lock()を.read()/.write()に置換
3. Clone実装の適切な修正（新しいBoxBase IDで状態コピー）
4. SocketBox連携テスト
```
**重要注意点**:
- SocketBox（PR #87修正済み）との互換性確保
- HTTPサーバー機能の回帰テスト必要
#### 1-2: P2PBox修正
```rust
// P2PBox特別注意点
- HashMap<String, Box<dyn NyashBox>>の適切なRwLock化
- peer管理の同期処理確認
- メッセージハンドラーの状態保持確認
```
### Step 2: Intent系Box（3日）
#### 2-1: IntentBox & SimpleIntentBox修正
```rust
// 統一修正パターン
Arc<Mutex<T>> → RwLock<T>
.lock().unwrap() → .read().unwrap() / .write().unwrap()
// 特別注意: Intent通信の状態保持確認
```
### Step 3: 基本型Box（3日）
#### 3-1: JSONBox & RandomBox修正
```rust
// JSONBox: serde_json::Value操作の確実性確保
// RandomBox: 乱数シード管理の正確性確保
```
### Step 4: 特殊用途Box（2日）
#### 4-1: EguiBox & FileBox & FutureBox修正
```rust
// EguiBox: GUI状態管理の慎重な修正
// FileBox: ファイル操作の安全性確保
// FutureBox: 非同期状態管理の正確性確保
```
## 🧪 必須テストスイート
### Phase 9.75-C統合テスト
```nyash
// tests/phase975c_final_validation.nyash
static box Main {
main() {
// HTTPServerBox状態保持テスト
local server = new HTTPServerBox()
server.bind("127.0.0.1", 8080)
assert(server.isRunning() == false) // 初期状態
// P2PBox状態保持テスト
local p2p = new P2PBox("node1", new MapBox())
p2p.connect("peer1")
assert(p2p.isConnected("peer1") == true)
// IntentBox状態保持テスト
local intent = new IntentBox("test", "data")
assert(intent.getType() == "test")
assert(intent.getData() == "data")
// 全Box型基本動作確認
me.testAllBoxTypes()
}
}
```
### 負荷テスト
```nyash
// tests/phase975c_stress_test.nyash
// 大量のBox作成・状態変更・並行アクセステスト
```
## ✅ 完了条件
### 技術的指標
- [ ] **Arc<Mutex>完全除去**: `grep -r "Arc<Mutex<" src/boxes/ | wc -l` → 0
- [ ] **フルビルド成功**: `cargo build --release` エラー0個
- [ ] **既存テスト**: 100%パス・回帰なし
- [ ] **新規テスト**: Phase 9.75-C統合テスト100%成功
### 機能的指標
- [ ] **HTTPServerBox**: SocketBox連携正常・状態保持確実
- [ ] **P2PBox**: peer管理・メッセージング正常
- [ ] **Intent系**: 通信・データ受け渡し正常
- [ ] **基本型**: JSON処理・乱数生成正常
- [ ] **特殊用途**: GUI・ファイル・非同期処理正常
## 🤖 Copilot期待効果
### 自動化実装
1. **パターン検出・一括変換**: Arc<Mutex>→RwLock機械的変換
2. **テストケース生成**: 各Box型の状態保持テスト自動生成
3. **回帰テスト**: 既存機能への影響0確認
### 品質保証
- 段階的実装・テスト
- 各Box独立性確保
- パフォーマンス影響最小化
## 🚨 リスク対応
### 高リスク要素
1. **HTTPServerBox**: SocketBox依存の複雑性
2. **P2PBox**: 複数HashMap・peer管理
3. **EguiBox**: GUI外部ライブラリ連携
### 対策
- 各Box修正後の単体テスト必須
- HTTPサーバー・P2P通信の実動作確認
- 段階的進行・影響範囲限定
## 🎯 Phase 9.75 完全完了ビジョン
### 達成される効果
- **デッドロック完全根絶**: 全Box型で内部Arc<Mutex>除去
- **状態保持確実性**: PR #87実証パターンの全Box適用
- **パフォーマンス向上**: RwLock効率化・メモリ使用量改善
- **保守性向上**: 新Box実装の単純化・デバッグ容易性
### Everything is Box哲学の完全実現
```rust
// 🎯 最終形態: 全Box型統一設計
pub struct AnyBox {
base: BoxBase, // 統一基盤
field1: RwLock<T1>, // 内部可変性
field2: RwLock<T2>, // 状態保持確実
// ❌ Arc<Mutex<T>> 完全除去！
}
// 外部: Arc<Mutex<dyn NyashBox>> 一元管理継続
```
## 📞 Copilot協力依頼
### 実装順序（推奨）
1. **Week 1**: HTTPServerBox + P2PBox（高影響・高価値）
2. **Week 1.5**: IntentBox + SimpleIntentBox（通信基盤）
3. **Week 2**: JSONBox + RandomBox（基本型）
4. **Week 2.5**: EguiBox + FileBox + FutureBox（特殊用途）
### 期待される協力
- 機械的変換の高速実装
- 全Box型の統一テスト作成
- 回帰テスト・性能測定
---
**🔥 Phase 9.75完全完了により、Nyashの基盤設計が完璧に統一されます！**
**🚀 Everything is Box哲学の技術的実現・実用性の飛躍的向上を目指します！**

170
docs/development/roadmap/phases/phase-9/phase9_aot_wasm_implementation.md Normal file
View File

@ -0,0 +1,170 @@
# 🚀 Phase 9: AOT WASM実装（最優先）
## 📋 Summary
wasmtime compileによるAOT実行ファイル生成で確実なユーザー価値提供。既存WASM基盤を活用し、配布可能なネイティブ実行ファイルを短期間で実現する。
## 🎯 実装目標
```bash
# 目標実装
nyash --compile-native app.nyash -o app.exe # AOT実行ファイル生成
nyash --aot app.nyash # 短縮形
./app.exe # 起動高速化（JIT起動コスト除去）
# 内部実装
wasmtime compile app.wasm -o app.cwasm # 事前コンパイル
Module::deserialize_file("app.cwasm") # ランタイム読み込み
```
## 🔧 技術的実装詳細
### 1. wasmtime::Config統一実装
```rust
// 追加予定: src/backend/aot/mod.rs
pub struct AOTBackend {
config: wasmtime::Config,
engine: wasmtime::Engine,
}
impl AOTBackend {
pub fn compile_module(&self, wasm_bytes: &[u8]) -> Result<Vec<u8>, String> {
let module = wasmtime::Module::new(&self.engine, wasm_bytes)?;
module.serialize()
}
pub fn load_precompiled(&self, cwasm_bytes: &[u8]) -> Result<wasmtime::Module, String> {
unsafe { wasmtime::Module::deserialize(&self.engine, cwasm_bytes) }
}
}
```
### 2. CLI統合実装
```rust
// 追加予定: src/main.rs
#[derive(Parser)]
struct Args {
// 既存オプション...
/// Compile to native executable (AOT)
#[arg(long)]
compile_native: bool,
/// AOT compilation (short form)
#[arg(long)]
aot: bool,
/// Output file for AOT compilation
#[arg(short, long)]
output: Option<String>,
}
```
### 3. 単一バイナリ梱包
```rust
// 生成例: target/release/nyash_app.exe
// 内部構造:
// [nyash_runtime] + [app.cwasm (embedded)] + [metadata]
const EMBEDDED_CWASM: &[u8] = include_bytes!("app.cwasm");
fn main() {
let engine = wasmtime::Engine::default();
let module = unsafe { wasmtime::Module::deserialize(&engine, EMBEDDED_CWASM) }?;
// ... 実行
}
```
## 📊 パフォーマンス目標
| 指標 | 現在 | 目標 | 改善率 |
|------|------|------|--------|
| **実行性能** | WASM JIT: 8.12ms | AOT: <1.6ms | **5倍高速化** |
| **起動時間** | JIT起動: ~50ms | AOT起動: <10ms | **5倍高速化** |
| **配布サイズ** | Runtime必要 | 単一実行ファイル | **依存関係解消** |
| **総合改善** | 13.5倍（対Interpreter） | **500倍目標** | **37倍追加向上** |
## 🛠️ 実装ステップ（2-3週間）
### Week 1: AOT基盤実装
- [ ] `src/backend/aot/mod.rs` 基本構造
- [ ] wasmtime::Config最適化設定
- [ ] .cwasm生成・ロードパイプライン
- [ ] `--compile-native` CLI基本実装
### Week 2: パッケージング・最適化
- [ ] 単一バイナリ梱包（`include_bytes!`）
- [ ] 互換性キー管理（CPU機能・wasmtimeバージョン）
- [ ] 起動時間最適化
- [ ] エラーハンドリング・デバッグ情報
### Week 3: 統合・検証
- [ ] 既存テストスイートでの動作確認
- [ ] ベンチマーク拡張（AOT性能測定）
- [ ] ドキュメント更新
- [ ] CI統合（自動AOTビルド）
## 🔍 技術的課題と対策
### 互換性管理
**課題**: wasmtimeバージョンアップで.cwasm互換性切れ
**対策**:
- 互換性キー埋め込み（wasmtimeバージョン・CPUフラグ）
- graceful degradation（互換切れ時はJITフォールバック）
### CPU機能検出
**課題**: SIMD/CPU拡張でベンチマーク結果変動
**対策**:
- baseline/v3二段ビルド
- 実行時CPU検出で最適.cwasm選択
### デバッグ情報
**課題**: AOTで元コード位置特定困難
**対策**:
- `Config::debug_info(true)`設定
- ソースマップ埋め込み
## ✅ Acceptance Criteria
### 機能要件
- [ ] `nyash --compile-native app.nyash -o app.exe` 動作
- [ ] 生成実行ファイルが単独で動作（依存関係なし）
- [ ] 既存Nyashプログラムが100%互換で高速実行
### 性能要件
- [ ] 起動時間 < 100ms
- [ ] 実行性能 > 現在WASM JIT（8.12ms）
- [ ] 配布ファイルサイズ < 10MB
### 品質要件
- [ ] 全テストケースPASS
- [ ] エラーハンドリング適切
- [ ] CI自動テスト通過
## 🚀 期待される効果
### 即座実用価値
- **配布可能実行ファイル**: `app.exe`単体で動作
- **起動高速化**: JIT起動コスト除去
- **依存関係解消**: wasmtimeランタイム不要
### 差別化優位
- **Everything is Box**: ネイティブAOT実現
- **Web互換性**: WASM基盤活用
- **段階最適化**: JIT→AOTの技術蓄積
### LLVM準備
- **AOT基盤確立**: Phase 10での技術転用
- **最適化知見**: エスケープ解析・ボックス化解除準備
- **ベンチマーク基準**: 真の性能比較基盤
## 📖 References
- docs/予定/native-plan/copilot_issues.txt（Phase 9詳細）
- docs/予定/ai_conference_native_compilation_20250814.md（AI大会議決定）
- docs/execution-backends.md（WASM基盤情報）
- [wasmtime compile documentation](https://docs.wasmtime.dev/cli-cache.html)
---
**💡 Tip**: 短期間で確実な成果を目指し、複雑な最適化より実用価値を最優先にする戦略です。
最終更新: 2025-08-14
作成者: Claude（実用優先戦略）

32
docs/development/roadmap/phases/phase-9/phase9_jit_baseline_planning.md Normal file
View File

@ -0,0 +1,32 @@
# ⚠️ Phase 9: JIT (baseline) planning → 📦 実用優先戦略により変更
## 🔄 戦略変更通知（2025-08-14）
**この Phase 9 は実用優先戦略により以下に変更されました：**
### 🚀 **新 Phase 9: AOT WASM実装**
- **実装内容**: wasmtime compileによるAOT実行ファイル生成
- **期間**: 2-3週間
- **詳細**: [phase9_aot_wasm_implementation.md](phase9_aot_wasm_implementation.md)
### 🔄 **JIT実装の新位置づけ**
- **Phase 12以降**: 将来オプション機能
- **理由**: Rust開発環境改善効果限定的、実用価値より最適化重視
---
## 📋 以下は従来計画（参考保存）
### Summary
- baseline JIT の設計と MIR→JIT の変換方針固め。Deopt/Safepoint/Effects を明示し、将来の最適化に耐える骨格を用意する。
### Scope
- 値表現の選定: Tagged/NaN-box vs 型テーブル参照（最小は i64 tagged or enum 型でOK）。
- Safepoint の配置規約: 関数入口・ループ先頭・Call直後（既存の MIR.Safepoint と整合）。
- Deopt テーブル: JIT 最適化時に巻き戻すための SSA マップ（値ID→ロケーション）。
- Effects の扱い: PURE/READS_HEAP/WRITES_HEAP/IO/FFI/PANIC を JIT バリアに伝播。
- コード生成の骨格: MIR → IR（Cranelift 等は未導入でもよく、当面スケルトン/ダミーで可）。
### References
- docs/予定/native-plan/copilot_issues.txt（実用優先戦略決定）
- docs/予定/ai_conference_native_compilation_20250814.md（AI大会議結果）

Some files were not shown because too many files have changed in this diff Show More