ResultBox migration (stage 0): suppress legacy deprecation warnings in box_trait impls; keep dual handling in VM. Fix verifier Display for SuspiciousBarrierContext. Expose VM stats fields to vm_stats module. CLI core_ci guide and script in place.

2025-08-26 01:42:18 +09:00
parent 7705508b99
commit 9c94e88b86
13 changed files with 408 additions and 36 deletions
--- a/ideas/README.md
+++ b/ideas/README.md
@ -0,0 +1,80 @@
+# 📁 Ideas フォルダ - 80/20ルールの「残り20%」管理
+
+このフォルダは、80/20ルールに基づいて「まず動くものを作る」方針で開発した後の、
+残り20%の改善案や新機能アイデアを整理して管理する場所です。
+
+## 📂 フォルダ構造
+
+```
+ideas/
+├── improvements/     # 80%実装の残り20%改善候補
+│   ├── *.md         # 各改善案
+│   └── archived/    # 実装済みor却下
+│
+├── new-features/    # 新機能アイデア  
+│   ├── *.md         # 各新機能案
+│   └── archived/    # 実装済みor却下
+│
+└── other/          # その他すべて
+    ├── *.md        # 調査、メモ、設計案など
+    └── archived/   # 完了済み
+```
+
+## 📝 ファイル形式
+
+### improvements/ 用テンプレート
+```markdown
+# [機能名] の改善
+Status: Pending (80%実装済み)
+Created: YYYY-MM-DD
+Priority: High/Medium/Low
+Related-Code: src/path/to/file.rs::function_name()
+
+## 現状（80%実装）
+- 現在の実装内容
+- 動作状況
+
+## 改善案（残り20%）
+### 1. 改善項目1
+- 詳細
+- 効果
+
+### 2. 改善項目2
+- 詳細
+- 効果
+
+## 実装タイミング
+- [ ] 条件1が満たされたら
+- [ ] 条件2が発生したら
+- [ ] Phase Xで一括対応
+```
+
+## 🏷️ ファイル命名規則
+
+`YYYY-MM-DD-feature-name.md`
+
+例：
+- `2025-08-25-vm-andor-shortcircuit.md`
+- `2025-08-26-mir-builder-cleanup.md`
+
+## 📊 優先度
+
+- **High**: ユーザーから要望があった、または性能に大きく影響
+- **Medium**: 改善すると良いが、現状でも問題ない
+- **Low**: Nice to have、時間があれば
+
+## 🔄 ワークフロー
+
+1. アイデアが生まれる → 適切なフォルダに`.md`作成
+2. 実装タイミングが来る → 実装
+3. 実装完了 → `archived/`へ移動（削除せず記録として残す）
+
+## 💡 なぜこの管理方法？
+
+- **80/20ルール遵守**: 完璧主義を防ぎ、進捗を優先
+- **アイデアの可視化**: 良いアイデアを忘れない
+- **優先順位明確化**: 本当に必要な20%だけを後で実装
+- **変化への対応**: 要件変更時も80%実装なら修正が楽
+
+---
+Created: 2025-08-25
--- a/ideas/improvements/2025-08-25-vm-andor-shortcircuit.md
+++ b/ideas/improvements/2025-08-25-vm-andor-shortcircuit.md
@ -0,0 +1,52 @@
+# VM and/or 短絡評価の実装
+Status: Pending (80%実装済み)
+Created: 2025-08-25
+Priority: Low
+Related-Code: src/backend/vm_instructions.rs::execute_binop()
+
+## 現状（80%実装）
+- `as_bool()`で両オペランドを評価してから論理演算を実行
+- 基本動作は完全に正常、テストもすべて通過
+- コード：
+  ```rust
+  BinOp::And => {
+      let left_bool = left_val.as_bool();
+      let right_bool = right_val.as_bool();
+      Ok(self.allocate_value(VMValue::Bool(left_bool && right_bool)))
+  }
+  ```
+
+## 改善案（残り20%）
+### 1. 短絡評価の実装
+- `And`: 左辺がfalseなら右辺の評価をスキップ
+- `Or`: 左辺がtrueなら右辺の評価をスキップ
+- 効果: 不要な計算の削減、副作用のある式での正しい動作
+
+### 2. 実装スケッチ
+```rust
+BinOp::And => {
+    let left_val = self.get_value(left)?;
+    if !left_val.as_bool() {
+        // 左辺がfalseなら即座にfalseを返す
+        return Ok(self.allocate_value(VMValue::Bool(false)));
+    }
+    // 左辺がtrueの場合のみ右辺を評価
+    let right_val = self.get_value(right)?;
+    Ok(self.allocate_value(VMValue::Bool(right_val.as_bool())))
+}
+```
+
+### 3. 考慮事項
+- MIRレベルでの最適化との整合性
+- デバッグ時のステップ実行への影響
+- パフォーマンステストの必要性
+
+## 実装タイミング
+- [ ] パフォーマンス問題が報告されたら
+- [ ] 副作用のある式（関数呼び出し等）で問題が発生したら
+- [ ] Phase 10（最適化フェーズ）で一括対応
+
+## メモ
+- 現在の実装でも機能的には問題ない
+- Pythonも初期は短絡評価なしだった（後から追加）
+- まずは動くことを優先する80/20ルールの良い例
--- a/ideas/new-features/2025-08-25-repl-mode.md
+++ b/ideas/new-features/2025-08-25-repl-mode.md
@ -0,0 +1,56 @@
+# REPL (Read-Eval-Print Loop) モード
+Status: Idea
+Created: 2025-08-25
+Priority: Medium
+Related: CLI機能拡張
+
+## 概要
+Nyashの対話的実行環境。Pythonのような即座にコードを試せる環境を提供。
+
+## 想定される使用例
+```bash
+$ nyash --repl
+Nyash REPL v1.0.0
+>>> local x = 42
+>>> print(x + 8)
+50
+>>> box Point { init { x, y } }
+>>> local p = new Point()
+>>> p.x = 10
+>>> p.y = 20
+>>> print(p)
+Point { x: 10, y: 20 }
+>>> exit()
+```
+
+## 実装案
+### Phase 1: 基本REPL
+- 単一行の評価と実行
+- 変数の永続化
+- 基本的なエラーハンドリング
+
+### Phase 2: 高度な機能
+- 複数行入力（継続行）のサポート
+- ヒストリー機能（上下キーで履歴）
+- タブ補完（変数名、メソッド名）
+- `.help`、`.clear`などのメタコマンド
+
+### Phase 3: デバッグ統合
+- ブレークポイント設定
+- 変数の詳細表示
+- メモリ使用状況の確認
+
+## 技術的考慮事項
+- 現在のインタープリター構造との統合
+- 状態管理（グローバルスコープの扱い）
+- rustyline等のREPLライブラリの活用
+
+## 実装タイミング
+- [ ] 基本的な開発ツールが整った後
+- [ ] ユーザーからの要望が多い場合
+- [ ] 教育用途での需要が高まった場合
+
+## 参考
+- Python REPL
+- Node.js REPL
+- Rust playground（Web版も検討）
--- a/ideas/other/2025-08-25-cranelift-research.md
+++ b/ideas/other/2025-08-25-cranelift-research.md
@ -0,0 +1,77 @@
+# Cranelift JIT 調査メモ
+Status: Research
+Created: 2025-08-25
+Priority: High (Phase 10関連)
+Related: Phase 10 - Cranelift JIT実装
+
+## 調査内容
+
+### Craneliftとは
+- Wasmtime/Firefoxで使用されているコード生成器
+- LLVMより軽量で高速なコンパイル
+- Rustで書かれており、Nyashとの統合が容易
+
+### 基本的な使用方法
+```rust
+use cranelift::prelude::*;
+use cranelift_module::{Module, Linkage};
+
+// 関数シグネチャ定義
+let mut sig = module.make_signature();
+sig.params.push(AbiParam::new(types::I64));
+sig.returns.push(AbiParam::new(types::I64));
+
+// 関数生成
+let func_id = module.declare_function("add_one", Linkage::Export, &sig)?;
+```
+
+### MIR → Cranelift IR変換の検討
+- MIR命令とCranelift命令の対応関係
+- Box型の表現方法（ポインタ vs 値）
+- GCとの統合方法
+
+### パフォーマンス予測
+- コンパイル時間: LLVM比 10x高速
+- 実行速度: インタープリター比 10-100x高速
+- メモリ使用量: 中程度
+
+## 実装スケッチ
+```rust
+// MIR → Cranelift変換器
+struct MirToCranelift {
+    builder: FunctionBuilder<'static>,
+    module: Module<SimpleJITBackend>,
+}
+
+impl MirToCranelift {
+    fn translate_instruction(&mut self, inst: &MirInstruction) {
+        match inst {
+            MirInstruction::Const { dst, value } => {
+                // Cranelift IRへの変換
+            }
+            // ...
+        }
+    }
+}
+```
+
+## 課題と検討事項
+1. **Box型の扱い**: ヒープ割り当てとGCの統合
+2. **動的ディスパッチ**: BoxCallの効率的な実装
+3. **例外処理**: Nyashのエラーハンドリングとの統合
+4. **デバッグ情報**: ソース位置の保持
+
+## 次のステップ
+- [ ] 最小限のPoC実装（整数演算のみ）
+- [ ] ベンチマーク環境の構築
+- [ ] VM実装との性能比較
+
+## 参考資料
+- [Cranelift公式ドキュメント](https://github.com/bytecodealliance/wasmtime/tree/main/cranelift)
+- [Cranelift IR Reference](https://github.com/bytecodealliance/wasmtime/blob/main/cranelift/docs/ir.md)
+- wasmtimeのJIT実装
+
+## メモ
+- Phase 10での実装が決定
+- まずはホットパスの特定から
+- 段階的な移行が重要（全部一度には無理）