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

docs: restore docs/private/roadmap from 7b4908f9 (Phase 20.31)

Browse Source
This commit is contained in:
nyash-codex
2025-10-31 18:00:10 +09:00
parent 1d49e24bf0
commit 8fd3a2b509
433 changed files with 108935 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
docs/private/roadmap/README.md Normal file
View File

@ -0,0 +1,68 @@
# 🗺️ Nyash 予定（ロードマップ・タスク）
## 📋 現在進行中
### 🎯 最重要タスク
- **現在のタスク**: [../../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様への依頼・課題整理
- **協調戦略**: [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最適化基盤
- エスケープ解析実装
- MIR/Builder/Optimizer簡略化計画（責務分離・効果正規化・可視化）
- [Phase 8.x: MIRパイプライン簡略化計画](phases/phase-8/phase_8_x_mir_pipeline_simplification.md)
## 📚 関連ドキュメント
### 📖 技術資料
- **[実行バックエンドガイド](../../reference/architecture/execution-backends.md)** - 3バックエンド使い分け
- **Self‑Hosting / Mini‑VM ロードマップ**
- [Phase 17: LoopForm Self‑Hosting（計画）](phases/phase-17-loopform-selfhost/README.md)
- [Mini‑VM 構築ロードマップ（足場）](phases/phase-17-loopform-selfhost/MINI_VM_ROADMAP.md)
- 最新の短期タスクは [CURRENT_TASK.md](../../CURRENT_TASK.md) を参照
- **[コアコンセプト](../nyash_core_concepts.md)** - Everything is Box哲学
### 🔄 進捗管理
- **定期更新**: 毎週金曜日に進捗反映
- **AI会議**: 重要決定事項は3AI大会議で検討
- **ベンチマーク**: 性能回帰チェック自動実行
---
**最終更新**: 2025-08-14 - AI大会議によるネイティブコンパイル戦略確定

453
docs/private/roadmap/architecture-strategy.md Normal file
View File

@ -0,0 +1,453 @@
# 🎯 Hakorune アーキテクチャ戦略
**作成日**: 2025-10-02
**関連**: [言語進化ロードマップ](./language-evolution.md)
**核心の問い**: セルフホスティングが主流になるなら、Rust実装はどこまで作るべきか？
---
## 📖 エグゼクティブサマリー
### **結論: 戦略A（Rust最小化）を採用**
> **「Rustは実行エンジン、セルフホストは言語進化」**
>
> MIR中間言語だからこそできる、理想的な責任分離。
**理由**:
1. **MIR中間言語の本質** - パーサーは交換可能コンポーネント
2. **セルフホストの圧倒的コンパクトさ** - Rust実装の10分の1
3. **開発効率最大化** - 重複実装の悲劇を回避
4. **言語進化の加速** - セルフホストで新機能を素早く試せる
**タイムライン**:
- Phase 17: Rustパーサー機能凍結宣言
- Phase 18: セルフホストがデフォルトパーサーに昇格
- Phase 19+: 新機能はすべてセルフホスト実装
---
## 📊 現状分析
### **実装規模比較**
```
Rustコンパイラ実装:
- src/parser/ 6,699行 (パーサー)
- src/runner/ 10,672行 (パイプライン・MIR生成)
- src/mir/ 17,730行 (MIR定義・最適化)
----------------------------------------
合計: 35,101行
セルフホストコンパイラ:
- parser_box 921行 (パーサー)
- pipeline_v2 1,580行 (パイプライン)
- その他 1,270行
----------------------------------------
合計: 3,771行
圧縮率: 10.7% (約10分の1)
```
### **MIR中間言語の威力**
```
┌─────────────────┐
│ 任意のパーサー │ ← セルフホスト主流 (3,771行)
│ (Rust/Selfhost)│ ← Rustフォールバック (6,699行)
└────────┬────────┘
│
▼
┌─────────┐
│ MIR JSON │ ← 中間言語（交換可能インターフェース）
└────┬────┘
│
┌────┴────┐
▼ ▼
┌──────┐ ┌──────┐
│ VM │ │ LLVM │ ← 実行エンジン（Rust実装）
└──────┘ └──────┘
```
**重要な洞察**:
- パーサーは**交換可能**
- 実行エンジン（VM/LLVM）は**共通**
- **MIRがあれば何とでもなる！**
---
## 🎯 3つの戦略案
### **戦略A: Rust最小化** ✅ 推奨
**方針**: Rustは「実行エンジン」に特化、パーサー・コンパイラはセルフホスト主流
#### **役割分担**
```
Rust層の役割（凍結対象）:
✅ VM実行エンジン (src/runner/vm/)
✅ LLVM実行エンジン (src/llvm_py/)
✅ プラグインシステム (crates/hakorune_kernel/)
✅ MIR定義 (src/mir/)
⚠️ リファレンスパーサー (src/parser/) - Phase 17で機能凍結
セルフホスト層の役割（成長対象）:
🚀 メインパーサー (apps/selfhost-compiler/)
🚀 MIR生成・最適化
🚀 新機能実装
🚀 言語進化
```
#### **タイムライン**
```
Phase 15-17: セルフホストパーサー完成
↓
Phase 17: Rustパーサー機能凍結宣言
↓
Phase 18: セルフホストがメインパーサーに昇格
↓
Phase 19+: Rustパーサーは「フォールバック」のみ
↓
Phase 21+: 新機能はすべてセルフホスト実装
```
#### **メリット**
- ✅ 重複実装を避ける（開発効率最大化）
- ✅ セルフホストに注力できる
- ✅ Rust層は安定・高速実行に専念
- ✅ 言語進化がセルフホストで加速
#### **デメリット**
- ⚠️ Rustパーサーが古くなる（意図的）
- ⚠️ セルフホストパーサーバグ時のフォールバックが限定的
---
### **戦略B: 完全二重実装** ❌ 非推奨
**方針**: RustとセルフホストでフルParity維持
```
Rust層:
✅ 完全なパーサー実装（継続更新）
✅ 完全なMIR生成実装（継続更新）
✅ すべての言語機能をサポート
セルフホスト層:
✅ 完全なパーサー実装（継続更新）
✅ 完全なMIR生成実装（継続更新）
✅ すべての言語機能をサポート
```
**メリット**:
- ✅ どちらも完全に動作
- ✅ 相互検証できる
**デメリット**:
- ❌ **重複実装の悪夢**（2倍の開発負担）
- ❌ 片方だけで十分なのに無駄
- ❌ 新機能を2回実装する必要
- ❌ **MIRの利点を殺している**
**結論**: **非推奨**。開発効率が最悪。
---
### **戦略C: Stable/Nightly分離** △ 中間案
**方針**: Rust=Stable Channel、セルフホスト=Nightly Channel
```
Rust層 (Stable):
✅ 実証済み機能のみ
✅ Phase 15完成機能で凍結
✅ 安定性・互換性優先
⏸️ 新機能は追加しない
セルフホスト層 (Nightly):
🚀 実験的新機能
🚀 言語進化の最前線
🚀 破壊的変更OK
```
**メリット**:
- ✅ 安定版が保証される
- ✅ 実験を気軽にできる
**デメリット**:
- ⚠️ 2つのバージョン管理が必要
- ⚠️ ユーザーが混乱する可能性
- ⚠️ Rustに新機能を移植する手間
---
## 💡 推奨戦略の詳細: 戦略A（Rust最小化）
### **採用理由（4つの柱）**
#### **1. MIR中間言語の本質**
- パーサーは交換可能コンポーネント
- 実行エンジンが本体
- **フロントエンド/バックエンド完全分離**が設計思想
#### **2. セルフホストの圧倒的コンパクトさ**
```
Rust実装: 35,101行 (パーサー+MIR生成)
セルフホスト: 3,771行 (同機能)
圧縮率: 10.7% (約10分の1)
```
**10分の1の実装量で同等機能**を実現できる！
#### **3. 開発効率の最大化**
- 1つの実装に集中できる
- 重複コードの悲劇を回避
- バグフィックスも1箇所のみ
#### **4. 言語進化の加速**
- セルフホストで新機能を素早く試せる
- 実験的機能の実装が容易
- Rustで安定実行を保証
---
## 📅 具体的な移行計画
### **Phase 17: Rustパーサー機能凍結宣言**
**凍結内容**:
```rust
src/parser/ の機能凍結（6,699行を固定）:
✅ 基本構文
- box/flow/static
- loop/if/match
- return/break/continue
✅ 高度な機能
- プロパティシステム（stored/computed/once/birth_once）
- 例外処理（try/catch/cleanup）
- 非同期（nowait/await）
- using/namespace基本
✅ 演算子・式
- 算術/比較/論理演算子
- Lambda式
- ?演算子（Result伝播）
「これで十分」宣言 🎯
```
**Phase 17でのドキュメント整備**:
- `docs/reference/rust-parser-freeze.md` を作成
- 凍結機能一覧を明記
- 新機能はセルフホストで実装する旨を宣言
---
### **Phase 18: セルフホストパーサー主流化**
**デフォルト切替**:
```bash
# デフォルト: セルフホストパーサー
$ hakorune program.hkr
→ apps/selfhost-compiler/ 使用
# フォールバック: Rustパーサー
$ hakorune --parser rust program.hkr
→ src/parser/ 使用
```
**互換性保証**:
- Phase 17凍結機能セットでは完全互換
- セルフホストパーサーバグ時はRustパーサーにフォールバック
---
### **Phase 19+: セルフホスト一本化**
**新機能開発方針**:
```
新機能開発:
✅ テストフレームワーク → セルフホストのみ実装
✅ ジェネリクス → セルフホストのみ実装
✅ チャネル → セルフホストのみ実装
✅ 型システム強化 → セルフホストのみ実装
Rust実装:
✅ バグフィックスのみ
✅ セキュリティパッチのみ
⏸️ 新機能追加なし
```
**理由**: 重複実装を避け、セルフホストに注力
---
## 🎯 Rust層の最終形態
### **保持すべき部分（コア実行基盤）**
```rust
// 1. 実行エンジン（VM）
src/runner/vm/ // VM実装（約712行）
src/runner/dispatch.rs // ディスパッチャー
src/runner/vm_pipeline.rs // VMパイプライン
// 2. LLVM実行エンジン
src/llvm_py/ // Python llvmlite実装
src/runner/modes/llvm.rs // LLVMモード
// 3. プラグインシステム
crates/hakorune_kernel/ // Kernel実装（約10,000行）
// 4. MIR定義
src/mir/mod.rs // MIR型定義
src/mir/types.rs // MIR基本型
// 5. CLI・エントリポイント
src/main.rs // CLIエントリ
src/cli.rs // CLI引数処理
推定合計: 約25,000行（Phase 30時点）
```
---
### **凍結すべき部分（Phase 17）**
```rust
// Phase 17で機能凍結・保守モードへ
src/parser/ // パーサー実装（6,699行）
src/runner/pipeline.rs // MIR生成パイプライン
// 理由: セルフホストに譲る
// 方針: バグフィックス・セキュリティパッチのみ
```
---
### **削減・削除候補**
```rust
// Phase 20+で削除検討
src/runner/modes/common_util/legacy/ // レガシーコード
src/runner/entry_resolve.rs // 既に削除済み
// 削減により: 48,344行 → 30,000行（Phase 20）
// → 25,000行（Phase 30、安定）
```
---
## 📊 コード行数の未来予測
### **Phase 17時点（現在）**
```
Rust実装: 48,344行
- parser: 6,699行
- runner: 10,672行
- mir: 17,730行
- boxes: 13,243行
セルフホスト: 3,771行
- parser: 921行
- pipeline: 1,580行
- その他: 1,270行
```
---
### **Phase 20予測（凍結・削減後）**
```
Rust実装: 30,000行 (-18,344行)
- VM/LLVM実行エンジン: 15,000行
- プラグイン: 10,000行
- CLI/ユーティリティ: 5,000行
セルフホスト: 10,000行 (+6,229行)
- パーサー: 2,000行
- MIR生成: 3,000行
- 最適化: 2,000行
- テスト: 3,000行
```
---
### **Phase 30予測（Parity到達）**
```
Rust実装: 25,000行 (安定・最小化)
- 実行エンジン: 15,000行
- プラグイン: 10,000行
セルフホスト: 25,000行 (Parity到達)
- パーサー: 5,000行
- MIR生成: 8,000行
- 最適化: 5,000行
- テスト: 7,000行
合計: 50,000行（現在の48,344行から微増）
```
**重要**: セルフホストがParityに到達しても、**合計行数はほぼ変わらない**！
→ 重複実装を避けることで、無駄な肥大化を防止
---
## 🎊 結論と次のアクション
### **戦略A（Rust最小化）採用を推奨**
**理由の再確認**:
1. ✅ MIR中間言語の本質に忠実
2. ✅ 開発効率最大化（重複回避）
3. ✅ セルフホストの圧倒的コンパクトさ活用
4. ✅ 言語進化の加速
---
### **具体的アクション**
**Phase 15（現在）**:
- [x] セルフホストパーサー実装中
- [x] Pipeline v2設計・実装
- [ ] テスト充実化
**Phase 17（次の大目標）**:
- [ ] **Rustパーサー機能凍結宣言**
- [ ] `docs/reference/rust-parser-freeze.md` 作成
- [ ] セルフホストパーサー完全Parity確認
- [ ] フォールバック機構実装
**Phase 18（主流化）**:
- [ ] セルフホストがデフォルトパーサーに昇格
- [ ] `--parser rust` フォールバックオプション実装
- [ ] ドキュメント・チュートリアル更新
**Phase 19+（一本化）**:
- [ ] 新機能はセルフホストのみ実装
- [ ] [言語進化ロードマップ](./language-evolution.md)に沿った開発
- [ ] Rust層は保守モード
---
### **名言化（再掲）**
> **「Rustは実行エンジン、セルフホストは言語進化」**
>
> MIR中間言語だからこそできる、理想的な責任分離。
>
> これがHakoruneアーキテクチャの真髄。
---
## 📚 関連ドキュメント
- [言語進化ロードマップ](./language-evolution.md) - Phase 16-30の言語機能進化計画
- [00_MASTER_ROADMAP.md](./phases/00_MASTER_ROADMAP.md) - 全体ロードマップ
- [Phase 15](./phases/phase-15/) - セルフホスティング実装詳細
- [Pipeline v2設計](../../selfhosting/pipeline_v2.md) - セルフホストパイプライン設計
---
**作成者**: Claude Sonnet 4.5（深層思考モード）
**作成日**: 2025-10-02
**ベース**: セルフホスティング進捗分析・アーキテクチャ戦略深層考察

76
docs/private/roadmap/idea/README.md Normal file
View File

@ -0,0 +1,76 @@
Nyash Dev Ideas / Roadmap Scratchpad
Purpose
- Quick scratchpad to capture ideas before they get shaped into tasks/PRs.
- Keep entries short and action-oriented; promote to RFC/docs when stable.
Near-Term (High Impact)
- Strengthen plugin ABI tester:
- Parse `nyash.toml` and verify method_id wiring with minimal invokes (birth + no-arg methods).
- Add contract tests for net plugin boxes (HttpRequest/Response/Client/Server).
- Fail fast with clear diffs when IDs drift.
- Make debug logs opt-in (done):
- `NYASH_DEBUG_PLUGIN=1` gates VM→Plugin bridge logs.
- `NYASH_NET_LOG=1` gates net plugin logs.
- Regression tests:
- Minimal end-to-end for HTTP: get→accept→respond→readBody (body non-empty).
- ABI sanity tests per box type (already added for HttpRequestBox).
Identity & Copy Semantics
- Enforce `is_identity()` and `clone_or_share()` usage across interpreter paths.
- Audit remaining `clone_box()` callsites; switch to `clone_or_share()` where identity is required.
- Optional: add dev assertions when PluginBoxV2 instance_id changes unexpectedly in a single flow.
Single Source of Truth for Method IDs
- Avoid hand-edit drift between plugin code and `nyash.toml`:
- Option A: Generate `nyash.toml` from Rust consts (build.rs or small generator).
- Option B: Generate Rust method_id consts from `nyash.toml`.
- Start with a checker that diffs the two (cheap safety net).
CI / Tooling
- Add `plugin_contract_*` tests to default CI.
- Add a `--ci-quiet` profile to suppress debug logs; emit logs only on failure.
- Introduce a small utility to reserve/randomize test ports to avoid collisions.
Net Plugin Polishing
- Keep TCP-only path; prefer accepted TCP requests in server.accept (done).
- Mirror response body into client handle using X-Nyash-Resp-Id (done); document behavior.
- Add timeouts and clearer error messages for readBody stalls.
Docs
- Expand `docs/development/box_identity_and_copy_semantics.md` with examples and anti-patterns.
- Add a quickstart: “How to debug the net plugin” (env flags, key logs, typical pitfalls).
Future Ideas
- Lightweight codegen for plugin schemas (IDs, arg signatures, returns_result) → toml + Rust.
- Lint/pass that forbids `clone_box()` on identity boxes in critical paths.
- Structured logging with categories and levels (trace/info/warn) pluggable to CI.
Notes
- Keep this file as a living list; prune as items graduate to tracked issues/PRs.
---
2025-08-23 Updates (VM × Plugins focus)
- VM Stats frontdoor (done): CLI flags `--vm-stats`, `--vm-stats-json`; JSON schema includes total/counts/top20/elapsed_ms.
- Next: integrate with `--benchmark` to emit per-backend stats; add `NYASH_VM_STATS_FORMAT=json` docs.
- ResultBox in VM (done): dispatch for `isOk/getValue/getError`; generic `toString()` fallback for any Box.
- Impact: HTTP Result paths now work end-to-end in VM.
- MIR if-merge bug (done): bind merged variable to Phi result across Program blocks (ret now returns phi dst).
- Next: add verifier check for "use-before-def across merge"; snapshot a failing MIR pattern as a test.
- Net plugin error mapping (done): on TCP connect failure, return TLV string; loader maps to Result.Err(ErrorBox).
- Next: formalize `returns_result` ok-type in nyash.toml (e.g., ok_returns = "HttpResponseBox"); tighten loader.
- E2E coverage (done):
- FileBox: open/write/read, copyFrom(handle)
- Net: GET/POST/status/header/body; 204 empty body; client error (unreachable port) → Err
- Next: 404/5xx reply from server side; timeouts; large bodies; header casing behavior.
Short-Term TODOs
- Add vm-stats samples for normal/error HTTP flows; feed into 26-instruction diet discussion.
- CI: run `--features plugins` E2E on a dedicated job; gate on Linux only; quiet logs unless failed.
- Docs: append "VM→Plugin TLV debugging" quick tips (env flags, TLV preview).
26-Instruction Diet Hooks
- Candidate demotions: Debug/Nop/Safepoint → meta; TypeCheck/Cast → fold or verify-time.
- Keep hot path: BoxCall/NewBox/Branch/Jump/Phi/BinOp/Compare/Return.
- Track Weak*/Barrier usage; keep as extended-set unless surfaced in vm-stats.

142
docs/private/roadmap/language-evolution/INDEX.md Normal file
View File

@ -0,0 +1,142 @@
# 📚 言語進化ロードマップ - ドキュメント索引
**作成日**: 2025-10-02
**対象**: Phase 16-30（言語機能・標準ライブラリの進化）
---
## 🎯 **メインドキュメント**
### **[README.md](./README.md)** - 言語進化ロードマップ v2.0 🌟
**Phase 16-30の完全な実装計画**
- **「コアは最小・糖衣は最強」** 方針に基づく設計
- **9の柱 + 糖衣5つ** - 全機能デシュガリング
- **実装タイムライン** - 優先順位付き
- **デシュガリング規則一覧** - 全16種
**こんな人向け**:
- Phase 16-30で何を実装するか知りたい
- 言語機能の全体像を把握したい
- 実装優先順位を確認したい
---
## 📖 **設計原則**
### **[desugaring-contract.md](./desugaring-contract.md)** - デシュガリング契約 📜
**Hakoruneの最も重要な設計原則**
- **5つの不変ルール（赤線）** - 絶対に守るべき原則
- **デシュガリング実例集** - 型システム、並行処理、糖衣構文、マクロ
- **全16種のデシュガリング規則表** - すべてMIR命令増加なし
- **契約違反の例** - やってはいけないこと
**こんな人向け**:
- 新機能を実装する開発者
- MIR14凍結の理由を知りたい
- デシュガリングの具体例を見たい
---
## 🔍 **問題分析**
### **[discoverability-analysis.md](./discoverability-analysis.md)** - 発見性問題分析 🔎
**なぜChatGPTが冗長なコードを書いてしまったのか**
- **問題の発見** - if連鎖 vs match式
- **5つの根本原因** - ドキュメント導線、サンプル不足、AI学習データ不足、Linter不足等
- **5つの解決策** - Cookbook/Recipe集、Linter、Quick Reference拡充等
- **Phase 17で即座に着手** - 発見性問題の根本解決
**こんな人向け**:
- なぜ「つよつよ機能」が使われないのか知りたい
- Cookbook/Linter実装の背景を知りたい
- 言語機能の発見性向上に興味がある
---
## 📚 **関連ドキュメント**
### **外部リンク**
- [アーキテクチャ戦略](../architecture-strategy.md) - Rust vs セルフホスト実装戦略
- [Phase 16 Macro Revolution](../phases/phase-16-macro-revolution/README.md) - マクロシステム詳細
- [MIR Instruction Set](../../../reference/mir/INSTRUCTION_SET.md) - MIR14命令セット詳細
### **歴史的資料**
- [v1-original.md](./v1-original.md) - Claude初版（参考資料）
---
## 🗺️ **ドキュメント構造**
```
docs/private/roadmap/language-evolution/
├── INDEX.md # このファイル（索引）
├── README.md # メインドキュメント（v2.0）⭐
├── desugaring-contract.md # デシュガリング契約（設計原則）
├── discoverability-analysis.md # 発見性問題分析
└── v1-original.md # Claude初版（参考資料）
```
---
## 🎯 **読む順番（推奨）**
### **初めての人**
1. **README.md** - 全体像を把握
2. **desugaring-contract.md** - 設計原則を理解
3. **discoverability-analysis.md** - 発見性問題を知る
### **新機能を実装する開発者**
1. **desugaring-contract.md** - 設計原則を確認
2. **README.md** - 実装計画を確認
3. **Phase 16-30のタイムライン** - 優先順位を確認
### **Cookbook/Linter実装者**
1. **discoverability-analysis.md** - 問題の本質を理解
2. **README.md（Phase 17）** - Cookbook/Linter計画を確認
3. **desugaring-contract.md** - デシュガリング規則を確認
---
## 💡 **重要な原則**
### **De-sugaring Contract（デシュガリング契約）**
> **新構文は既存構文・既存Boxへ有限段で必ず落ちること。IR命令の追加は最後の手段。**
### **「コアは最小・糖衣は最強」**
```
MIR14命令セット（凍結）
↓
すべての新機能をデシュガリング
↓
Box/マクロ/標準ライブラリで実現
↓
VM/LLVM/WASM すべて恩恵！
```
### **Everything is Box の真髄**
- **型システム**: OptionBox, SumBox
- **並行処理**: TaskGroupBox, SelectBox, ChannelBox
- **テスト**: TestRunnerBox, BenchmarkBox
- **プロファイル**: ProfileBox
---
## 🎊 **まとめ**
このフォルダには、**Hakorune言語進化の完全な設計図**が含まれています。
**3つのドキュメント**で、Phase 16-30の全体像を把握できます：
1. **README.md** - 実装計画（9の柱 + 糖衣5つ）
2. **desugaring-contract.md** - 設計原則（5つの不変ルール）
3. **discoverability-analysis.md** - 発見性問題と解決策
**これで、Hakoruneは次世代言語の標準を打ち立てる準備が整っています！** 🚀
---
**作成者**: Claude Sonnet 4.5
**作成日**: 2025-10-02
**関連**: [言語進化ロードマップ v2.0](./README.md)

861
docs/private/roadmap/language-evolution/README.md Normal file
View File

@ -0,0 +1,861 @@
# 🚀 Nyash/Hakorune 言語進化ロードマップ v2.0
**作成日**: 2025-10-02
**更新日**: 2025-10-02 - ChatGPT Pro + Claude 統合改良版
**対象**: Phase 16-30（言語機能・標準ライブラリの進化）
**関連**: [アーキテクチャ戦略](../architecture-strategy.md) - Rust vs セルフホスト実装戦略
---
## 📖 概要
Phase 15までの実装により、Nyash/Hakoruneは強力な基礎を確立しました。
このドキュメントは、**「コアは最小・糖衣は最強」**方針に基づく体系的な言語機能進化を定義します。
**実装方針**: [アーキテクチャ戦略](../architecture-strategy.md)に従い、Phase 19以降の新機能は**セルフホストのみ**で実装します。
---
## 🎯 **不変の設計原則（赤線）**
### **De-sugaring Contract**（最重要原則）
> **新構文は既存構文・既存Boxへ有限段で必ず落ちること。IR命令の追加は最後の手段。**
**具体的ルール**:
1. **MIR14は増やさない** - すべてデシュガリング/静的パス/標準ライブラリで実現
2. **Everything is Box/flow Main.main を維持** - Pulse は下限として利用
3. **Effects/Capabilities/Contracts は meta 側** - 言語仕様には持ち込まない
4. **例外は導入しない** - panicはVM/実装バグ用、通常はResultBoxで伝播
5. **dev→prod の挙動差は policy のみ** - warn/audit/enforce で制御
📖 **詳細**: [De-sugaring Contract](./desugaring-contract.md) に別途明記
---
## 📊 現在の強み（Phase 15-16時点）
### ✅ **言語機能の充実度**
1. **プロパティシステム** (stored/computed/once/birth_once) - **業界最先端レベル**
2. **🚀 マクロシステム (Phase 16実装中)** - @derive/@test等、Box-Based Macro革命
3. **postfix catch/cleanup** - 非常にモダン（Swift/Kotlin風）
4. **Result伝播 (? 演算子)** - Rust風エラー処理
5. **match式** - パターンマッチング
6. **Lambda式** - 高階関数サポート
7. **using/namespace** - モジュールシステム基礎
8. **flow** - stateless namespace（静的関数グループ化）
9. **非同期** (nowait/await/FutureBox) - 並行処理基礎
10. **演算子オーバーロード** - トレイトベース
11. **変数宣言厳密化** - メモリ・非同期安全性保証
### ✅ **Box型ライブラリ充実度**
30種類以上のBox（String/Integer/Array/Map/JSON/Regex/HTTP/GUI等）
### ✅ **コンパクトな実装**
- セルフホスティングコンパイラ: **3,771行**
- Rust実装: 48,344行
- **圧縮率: 約10.7%（約10分の1）**
---
## 🎯 進化計画（9の柱 + 糖衣5つ）
**注**: マクロシステム（旧🔟）はPhase 16で既に実装中のため、残り9項目 + 糖衣構文5つを進化計画とします。
---
### **1️⃣ 型システムの段階的強化（デシュガリング優先）**
**現状**: 型アノテーションはP0では無視、実行時型エラー
**Phase**: 20-25
**優先度**: 🟡 中
**実装方針**: **完全デシュガリング** - 新しいMIR命令は追加しない
#### **Phase 20: Optional/Union型（純糖衣）**
```nyash
// T? → OptionBox<T> へデシュガリング
box Container {
value: IntegerBox? // 糖衣構文
get(): IntegerBox? { // 戻り値も糖衣
return me.value
}
}
// ↓ デシュガリング後
box Container {
value: OptionBox<IntegerBox>
get(): OptionBox<IntegerBox> {
return me.value
}
}
// Union型: A|B → SumBox<A,B> へデシュガリング
type Result = OkBox | ErrorBox // 糖衣構文
// ↓
type Result = SumBox<OkBox, ErrorBox>
```
**match網羅性チェック**: 静的パス（コンパイラ検査）で提供
**実装**: 既存のOptionBox/SumBoxを活用（新しいBox不要）
#### **Phase 22: ジェネリクス（モノモーフィック展開）**
```nyash
// Phase A: マクロ的モノモーフィック展開から開始
box Container<T> {
items: ArrayBox<T>
add(item: T) {
me.items.push(item)
}
get(index: IntegerBox): T? {
return me.items.get(index)
}
}
// 実体化: 型パラメータごとにコード生成
// Container<IntegerBox> → Container_IntegerBox
// Container<StringBox> → Container_StringBox
```
**制約**: 最初は単純型パラメータのみ（高度な制約は後回し）
#### **Phase 24: Intersection型（型検査のみ）**
```nyash
// Intersection: 型検査側の"特性集合"のみ
type Loggable = ConsoleBox & FileBox // capability の交差
// ランタイム表現は作らない（静的検査のみ）
```
**やらないこと**: HM型推論、row多相（コスト > 便益）
**実装ステップ**:
1. Phase 20: Optional/Union型糖衣 + 網羅性チェック
2. Phase 22: ジェネリクス基礎（モノモーフィック）
3. Phase 24: Intersection型（静的検査のみ）
---
### **2️⃣ エラーハンドリング（現状で十分・糖衣のみ）**
**現状**: ResultBox, postfix catch/cleanup（基礎は良い）
**Phase**: 26-28
**優先度**: 🟢 低（現状で十分実用的）
**追加する糖衣（2つのみ）**:
```nyash
// 1. try-else 糖衣 → Result連鎖へデシュガリング
try {
dangerousOperation()
} else { e ->
handleError(e)
}
// ↓ デシュガリング後
dangerousOperation()
.catch(fn(e) { handleError(e) })
// 2. mapError → 標準ライブラリで提供（構文は増やさない）
result.mapError(fn(e) { new AppError(e) })
```
**やらないこと**:
- カスタムエラー型階層（Boxで実現可能）
- panic/recover（現状のpanicで十分）
---
### **3️⃣ テストフレームワーク統合（最優先！）** 🔴
**現状**: テスト機能なし（**最大の欠落！**）
**Phase**: 16.1-17
**優先度**: 🔴 最高（開発体験向上の鍵！言語採用の決定要因）
**実装方針**: **すべてマクロで実装**（MIR命令増やさない）
#### **Phase 16.1: 基本テストフレームワーク**
```nyash
// @test/@describe/@it マクロ実装
@test
describe("Calculator") {
@test
it("should add numbers") {
local calc = new Calculator()
expect(calc.add(2, 3)).toBe(5)
assert(calc.value == 0)
}
@test
it("should handle errors") {
expectThrow(fn() { calc.divide(1, 0) })
}
}
```
**実体**: TestRunnerBox（標準ライブラリ）
#### **Phase 16.2: アサーション拡張**
```nyash
expect(value).toBe(expected) // 厳密等価
expect(value).toEqual(expected) // 深い等価
expect(value).toThrow() // 例外期待
expect(value).toBeGreaterThan(n) // 比較
expect(value).toContain(item) // 含有
```
#### **Phase 16.3: Benchmark統合** 🎯
```nyash
@bench(iterations: 1000)
benchmark_fibonacci() {
fibonacci(20)
}
// 実行: hako bench
// 出力: 平均実行時間、メモリ使用量等
```
**実体**: BenchmarkBox（標準ライブラリ） + `hako bench` コマンド
#### **Phase 16.4 または 17.1: Property-based testing**
```nyash
@property_test(iterations: 1000)
test_commutative_addition() forall(a: IntegerBox, b: IntegerBox) {
expect(a + b).toBe(b + a)
}
```
**生成器**: GenBox<T>（シード固定可）
#### **Phase 17: Snapshot/Mock**
```nyash
// Snapshot testing
@test
test_output() {
local result = generateReport()
snapshot("report_v1", result) // JSON保存、再現可能
}
// Mock
@mock
box MockHttpClient from HttpClient {
override get(url) {
return new MockResponse(200, "OK")
}
}
```
**重要性**:
- セルフホスティング進行中の**今こそ**導入すべき
- TDD開発体験が言語採用の鍵
- Benchmark統合で性能回帰を防止
---
### **4️⃣ 並行処理の完成度向上（糖衣100%）**
**現状**: nowait/await/FutureBox（基礎のみ）
**Phase**: 21-25
**優先度**: 🟡 中
**実装方針**: **構文は最小、すべて標準ライブラリで実現**
#### **Phase 21: ChannelBox実装**
```nyash
// 標準ライブラリ実装（新構文なし）
using std.sync
local ch = new ChannelBox<IntegerBox>()
nowait producer = loop(true) {
ch.send(randomInt())
}
local value = ch.receive() // await不要
```
#### **Phase 22: 構造化並行性（糖衣）**
```nyash
// async{} → TaskGroupBox へデシュガリング
async {
nowait task1 = longTask1()
nowait task2 = longTask2()
// スコープ終了で自動待機
// エラー時は両方キャンセル
}
// ↓ デシュガリング後
local group = new TaskGroupBox()
group.spawn(fn() { longTask1() })
group.spawn(fn() { longTask2() })
group.await_all() // スコープ終了時自動
```
#### **Phase 23: Select式（API合成）**
```nyash
// select{} → SelectBox へデシュガリング
match select {
ch1.receive() => { handle1() }
ch2.receive() => { handle2() }
timeout(1000) => { handleTimeout() }
}
// ↓ デシュガリング後
local sel = new SelectBox()
sel.on(ch1, fn(v) { handle1() })
sel.on(ch2, fn(v) { handle2() })
sel.on_timeout(1000, fn() { handleTimeout() })
sel.run()
```
#### **Phase 24: CancelTokenBox標準化**
```nyash
// 標準ライブラリ実装
local token = new CancelTokenBox()
nowait task = longTask(token)
token.cancel() // タスク中断
```
**実装ステップ**:
1. Phase 21: ChannelBox実装（標準ライブラリ）
2. Phase 22: TaskGroupBox + `async{}` 糖衣
3. Phase 23: SelectBox + `select{}` 糖衣
4. Phase 24: CancelTokenBox標準化
---
### **5️⃣ メモリ管理の可視性向上（メソッド化）**
**現状**: Arc<Mutex>暗黙共有、outbox/weak未活用
**Phase**: 28-30
**優先度**: 🟢 低（現状で安全）
**実装方針**: **キーワードにしない、メソッドで提供**
```nyash
// ❌ キーワード版（採用しない）
outbox result = expensiveComputation()
weak reference: ChildBox
// ✅ メソッド版（採用）
local result = expensiveComputation()
useResult(result.move()) // 所有権移転
local ref = original.share() // Arc参照増加
local weak = original.weak() // 弱参照取得
local copy = original.clone() // 深いコピー
```
**注釈（meta）**:
```nyash
// unique ヒントはmeta（AOT最適化用）
// 言語機能にはしない
@unique
local exclusive = createResource()
```
---
### **6️⃣ 標準ライブラリの体系化**
**現状**: 豊富だが命名・構造が不統一
**Phase**: 16-20
**優先度**: 🟡 中（早期実施推奨）
**実装方針**: Rust std風階層 + 命名統一
#### **Phase 16: 命名規則統一計画策定**
```nyash
// ❌ Before（不統一）
array.length() // ArrayBox
string.len() // StringBox
map.size() // MapBox
// ✅ After（統一）
array.len() // すべて len() に統一
string.len()
map.len()
```
#### **Phase 17-20: 階層構造実装**
```nyash
// Rust std風階層構造
using std.collections // ArrayBox, MapBox, SetBox, QueueBox
using std.io // FileBox, StreamBox, BufferBox
using std.net // HttpClientBox, TcpBox, UdpBox
using std.sync // MutexBox, ChannelBox, AtomicBox
using std.time // TimeBox, DurationBox, TimerBox
using std.json // JSONBox（parse/stringify/schema）
using std.regex // RegexBox
using std.math // MathBox
using std.console // ConsoleBox
using std.effect // 🆕 効果のNo-op/記録デバイス
using std.profile // 🆕 軽量プロファイルAPI
// Prelude自動インポート（最小限）
// StringBox, IntegerBox, ArrayBox, MapBox, ResultBox, OptionBox
```
**実装ステップ**:
1. Phase 16: 命名規則統一計画策定
2. Phase 17: std.collections体系化 + 命名統一実施
3. Phase 18: std.io/net/sync体系化
4. Phase 19-20: その他標準ライブラリ体系化 + std.effect/profile追加
---
### **7️⃣ デバッグ・診断機能強化**
**現状**: DebugBox、基本的なprint
**Phase**: 18-20
**優先度**: 🟡 中（開発体験向上）
**実装方針**: **すべてマクロまたはBox化**
#### **Phase 18: repr()実装**
```nyash
// repr() → @derive(Debug) マクロと連携
@derive(Debug)
box Person {
name: StringBox
age: IntegerBox
}
print(str(person)) // "Person instance"
print(repr(person)) // "Person { name: "Alice", age: 25 }"
```
**実装**: `@derive(Debug)` マクロ（Phase 16実装済み）と連携
#### **Phase 19: スタックトレース改善**
```nyash
// スタックトレースはBox化
try {
deepFunction()
} catch(e) {
print(e.stack()) // ErrorBox.stack() メソッド
}
```
**実装**: VM側で改善、ErrorBoxにメソッド追加
#### **Phase 20: プロファイラ統合**
```nyash
// @profile マクロ → std.profile API注入
@profile
calculate() {
// 実行時間・メモリ使用量を自動計測
}
// ↓ デシュガリング後
calculate() {
local _prof = ProfileBox::start("calculate")
// 元の処理
_prof.end()
}
```
**実装**: `@profile` マクロ + std.profile（標準ライブラリ）
**アサーション強化**:
```nyash
assert(value > 0, "value must be positive")
debug_assert(internal.isValid()) // devのみ（policy制御）
static_assert(SIZE == 64, "size must be 64") // コンパイル時
```
**実装ステップ**:
1. Phase 18: repr() + @derive(Debug)連携
2. Phase 19: スタックトレース改善（ErrorBox強化）
3. Phase 20: @profile マクロ + アサーション強化
---
### **8️⃣ ドキュメント生成機能**
**現状**: ドキュメント生成機能なし
**Phase**: 25-30
**優先度**: 🟢 低
**実装方針**: **ツール側で処理**（言語拡張は不要）
```nyash
/// Calculator Box provides basic arithmetic operations.
///
/// # Examples
/// ```nyash
/// local calc = new Calculator()
/// calc.add(2, 3) // => 5
/// ```
box Calculator {
/// The current calculation result
result: IntegerBox
/// Adds two numbers
/// # Arguments
/// - `a`: First number
/// - `b`: Second number
/// # Returns
/// Sum of a and b
add(a: IntegerBox, b: IntegerBox): IntegerBox {
return a + b
}
}
```
**コマンド**:
```bash
$ hako doc --generate # JSON IR → HTML 二段階生成
```
**二段階出力の利点**: テーマ差し替えが容易
---
### **9️⃣ パッケージマネージャ完成（段階導入）**
**現状**: using system基礎実装
**Phase**: 18-20
**優先度**: 🟡 中
**実装方針**: **段階導入** - git直参照 → index-less publish → レジストリ
#### **Phase 18: git直参照 + lock.hako**
```toml
# hako.toml（Cargo風）
[package]
name = "my-app"
version = "0.1.0"
authors = ["Me"]
[dependencies]
http-client = { git = "https://github.com/user/http-client", tag = "v1.2.0" }
json-parser = { git = "https://github.com/user/json-parser", branch = "main" }
[dev-dependencies]
test-framework = { git = "https://github.com/hakorune/test-framework", tag = "v0.5.0" }
```
**lock.hako**: deterministic ビルド保証
#### **Phase 19: index-less publish**
```bash
$ hako publish # GitHub Releases等に直接公開
```
**レジストリ不要**: git tag ベースで依存関係解決
#### **Phase 20: レジストリ（必要が生じたら）**
```toml
[dependencies]
http-client = "1.2.0" # レジストリから取得
```
**コマンド**:
```bash
$ hako new my-project
$ hako build
$ hako test
$ hako bench # 🎯 最初から統合！
$ hako run
$ hako publish
```
**実装ステップ**:
1. Phase 18: git直参照 + lock.hako（deterministic）
2. Phase 19: index-less publish（GitHub Releases）
3. Phase 20: レジストリ（必要なら）
---
### **🔟 マクロシステム拡張**
**現状**: ✅ **Phase 16で実装中** - Box-Based Macro革命
**実装済み**:
- @derive(Equals, ToString, Clone, Debug)
- @test マクロ + テストランナー
- AST Pattern Matching基盤
- Quote/Unquote システム
- HIRパッチ式マクロエンジン
📖 **詳細**: [Phase 16 Macro Revolution](../phases/phase-16-macro-revolution/README.md)
**Phase 17-20: 拡張**:
```nyash
// さらなる@deriveトレイト追加
@derive(Hash, Ord, Default, Serialize)
box MyBox { }
// カスタムマクロ定義（限定版）
macro benchmark(iterations) {
// パフォーマンス計測マクロ
}
// comptime計算（限定版・安全領域のみ）
const CONFIG = comptime {
readFile("config.toml").parse() // ビルド時評価
}
```
**制約**: Turing完全にしない（安全領域のみ）
**Phase**: 16（実装中）→ 17-20（拡張）
**優先度**: 🟡 中（コア実装済み、拡張は要望次第）
---
## 🍬 **糖衣構文5つ（追加提案）**
### **A. パイプライン演算子 `|>`** 🎯
**Phase**: 17-18（テストの次）
**優先度**: 🔴 高（発見性問題の解決にも効く！）
```nyash
// 読みやすさ爆増！
value |> f(_) |> g(_, 42) |> h(_)
// ↓ デシュガリング後
h(g(f(value), 42))
// 実用例
[1, 2, 3, 4, 5]
|> map(_, fn(x) { x * 2 })
|> filter(_, fn(x) { x % 3 == 0 })
|> reduce(_, 0, fn(acc, x) { acc + x })
```
**効果**: Cookbook/Recipe集の可読性向上、if連鎖問題の緩和
---
### **B. 名前付き引数**
**Phase**: 18-19
**優先度**: 🟡 中
```nyash
// 可読性UP
download(url: u, timeout: 3.s, retry: 5)
// ↓ デシュガリング後（位置引数 + デフォルト補完）
download(u, 3.s, 5)
// デフォルト引数との相性良い
download(url: u) // timeout, retry はデフォルト値
```
---
### **C. `with capability` スコープ（視覚糖衣）**
**Phase**: 20-22
**優先度**: 🟢 低（開発体験向上）
```nyash
// 効果システムを言語機能にしない賢い方法
with net.out, fs.read {
http.get("https://api.example.com")
file.read("config.txt")
}
// ↓ 実際は何も変えない（ログに印を出すだけ）
// metaレイヤーで処理
```
**効果**: 視覚的な開発体験向上、capability明示
---
### **D. `comptime`（限定版）**
**Phase**: 22-25
**優先度**: 🟡 中
```nyash
// ビルド時評価（限定版）
const CONFIG = comptime {
readFile("config.toml").parse()
}
// 定数埋め込み
const VERSION = comptime { "1.0.0" }
```
**制約**:
- Turing完全にしない
- 読み込みと定数計算のみ
- YAGNI原則遵守
---
### **E. パターン別名（Pattern Synonyms）**
**Phase**: 23-25
**優先度**: 🟢 低
```nyash
// パターン別名で可読性UP
pattern Some(x) = OptionBox::Some(x)
pattern None = OptionBox::None
match value {
Some(x) => process(x)
None => handleError()
}
```
---
## 🎯 **デシュガリング規則一覧**
| 構文 | デシュガリング後 | Phase |
|------|----------------|-------|
| `T?` | `OptionBox<T>` | 20 |
| `A\|B` | `SumBox<A,B>` | 20 |
| `x \|> f(_)` | `f(x)` | 17-18 |
| `f(a:1, b:2)` | `f(1,2)` | 18-19 |
| `async { body }` | `TaskGroupBox::scoped(fn() { ... })` | 22 |
| `select { a=>x; b=>y }` | `SelectBox::new().on(a, fn(v){x}).on(b, fn(v){y}).run()` | 23 |
| `@test it("..."){...}` | `TestRunnerBox::register(fn(){...})` | 16.1 |
| `@bench(iter:N) { ... }` | ベンチハーネス呼び出し | 16.3 |
| `@profile { ... }` | `ProfileBox::start()` + 処理 + `.end()` | 20 |
| `repr(obj)` | `@derive(Debug)` マクロ連携 | 18 |
| `x.move()` | 所有権移転メソッド | 28 |
| `x.share()` | Arc参照増加メソッド | 28 |
| `x.weak()` | 弱参照取得メソッド | 28 |
---
## 📅 実装タイムライン（優先順位付き）
### **Phase 16-17: 基礎固め + 発見性問題解決** 🔴
**Phase 16（現在）**:
1. 🚀 **マクロシステム完成** - @derive/@test完全動作
- 16.1: 基本テストフレームワーク（describe/it/expect）
- 16.2: アサーション拡張（toBe/toEqual/toThrow）
- 16.3: **Benchmark統合** (`@bench`, `hako bench`)
- 16.4: Property-based testing（GenBox）
2. 🟡 **標準ライブラリ命名規則統一計画策定**
**Phase 17（次の大目標）**:
3. 🔴 **Cookbook/Recipe集作成** - [Discoverability問題](./discoverability-analysis.md)解決の要
- `docs/cookbook/patterns/` - ルックアップテーブル、文字列解析等
- `docs/cookbook/anti-patterns/` - if連鎖のアンチパターン等
- `docs/cookbook/refactoring/` - if→match変換等
4. 🔴 **Linter基礎実装** - Anti-Pattern検出開始
5. 🟡 **パイプライン演算子 `|>`** - 可読性向上
6. 🟡 **std.collections体系化 + 命名統一実施** (`len()` 統一)
7. 🟢 **Snapshot/Mock機能** - テスト完成
### **Phase 18-20: 開発体験向上** 🟡
**Phase 18**:
8. 🟡 **名前付き引数**
9. 🟡 **repr() + @derive(Debug)連携**
10. 🟡 **std.io/net/sync体系化**
11. 🟡 **パッケージマネージャ（git直参照 + lock.hako）**
**Phase 19**:
12. 🟡 **スタックトレース改善**（ErrorBox強化）
13. 🟡 **Linter拡充** - 自動リファクタリング提案
14. 🟡 **パッケージマネージャ（index-less publish）**
15. 🟡 **その他標準ライブラリ体系化** + std.effect/profile追加
**Phase 20**:
16. 🟡 **@profile マクロ + アサーション強化**
17. 🟡 **Optional/Union型糖衣** (`T?`, `A|B`)
18. 🟡 **パッケージマネージャ完成**（必要ならレジストリ）
### **Phase 21-25: 高度機能** 🟡
**Phase 21-24**:
19. 🟡 **並行処理完成**
- 21: ChannelBox
- 22: TaskGroupBox + `async{}` 糖衣 + ジェネリクス基礎
- 23: SelectBox + `select{}` 糖衣 + パターン別名
- 24: CancelTokenBox + Intersection型（静的検査のみ）
20. 🟢 **`with capability` スコープ**（視覚糖衣）
21. 🟢 **`comptime`（限定版）**
**Phase 25**:
22. 🟡 **ドキュメント生成** (`hako doc`)
### **Phase 26-30: 洗練** 🟢
23. 🟢 **エラーハンドリング糖衣** (`try-else`, `mapError`)
24. 🟢 **メモリ管理メソッド** (`move()`, `share()`, `weak()`)
25. 🟢 **マクロシステム拡張** (@derive拡充、カスタムマクロ)
---
## 💡 設計原則の再確認
### **1. De-sugaring Contract 遵守**
- 新構文は既存構文・既存Boxへ有限段で必ず落ちる
- MIR14命令セットは増やさない
### **2. Everything is Box哲学の維持**
- すべての新機能はBox化して提供
- 一貫性を最優先
### **3. セルフホスティング優先**
- Rust実装で先行実装 → セルフホストで再実装
- セルフホストでの実装容易性を考慮した設計
### **4. YAGNI原則遵守**
- マクロシステムは実際の要望が出てから拡張
- 型システム強化はopt-in（段階的導入）
- メモリ管理可視性は現状で十分安全
### **5. 後方互換性**
- 既存コードを壊さない
- 新機能はopt-inまたは新構文で提供
---
## 🎊 まとめ
### **Phase 16-17: テスト+発見性問題解決**
✅ **@test/@bench/@derive完全動作** - Box-Based Macro革命完成
✅ **Cookbook/Recipe集 + Linter** - 発見性問題の根本解決
✅ **パイプライン演算子 `|>`** - 可読性爆増
✅ **標準ライブラリ命名統一** - 開発体験の一貫性向上
### **現在の設計の優秀さ**
- **プロパティシステム**（once/birth_once）は**業界最先端レベル**
- **マクロシステム**（Phase 16実装中）はBox-Based設計で革新的
- **postfix catch/cleanup**は非常に直感的
- **Everything is Box哲学**が一貫している
- **コンパクトな実装**（Rust実装の約10分の1）
### **長期ビジョン**
Phase 16-30を通じて、実用的で表現力豊かな言語へと進化。
**マクロシステム・プロパティシステム・型システムの三位一体**で、
**「コアは最小・糖衣は最強」** - 次世代言語の標準を打ち立てる。
---
**作成者**: Claude Sonnet 4.5 + ChatGPT Pro
**ベース**:
- [language-evolution.md v1](./v1-original.md) - Claude初版
- ChatGPT Pro深層分析・改良提案
- [Discoverability問題分析](./discoverability-analysis.md)
- [De-sugaring Contract](./desugaring-contract.md)
**更新履歴**:
- 2025-10-02: Claude初版作成
- 2025-10-02: ChatGPT Pro + Claude 統合改良版作成

555
docs/private/roadmap/language-evolution/desugaring-contract.md Normal file
View File

@ -0,0 +1,555 @@
# 🎯 De-sugaring Contract（デシュガリング契約）
**作成日**: 2025-10-02
**対象**: すべての新機能実装
**関連**: [言語進化ロードマップ v2.0](./README.md)
---
## 📖 概要
**De-sugaring Contract（デシュガリング契約）** は、Hakoruneの**最も重要な設計原則**です。
> **新構文は既存構文・既存Boxへ有限段で必ず落ちること。IR命令の追加は最後の手段。**
この原則により、**「コアは最小・糖衣は最強」** を実現します。
---
## 🎯 5つの不変ルール（赤線）
### **1️⃣ MIR14は増やさない**
**原則**: すべてデシュガリング/静的パス/標準ライブラリで実現
**現状のMIR14命令セット**:
- 基本演算(5): Const, UnaryOp, BinOp, Compare, TypeOp
- メモリ(2): Load, Store
- 制御(4): Branch, Jump, Return, Phi
- 呼び出し(1): MirCall（Callee で Global/Extern/ModuleFunction/Method/Constructor/Closure/Value を表現）
- GC(2): Barrier, Safepoint
- 構造(2): Copy, Nop（最適化/検証用・意味論不変）
📖 **詳細**: [MIR Instruction Set](../../../reference/mir/INSTRUCTION_SET.md)
**なぜ凍結するか**:
- VM/LLVM/WASMすべてのバックエンドで恩恵を受ける
- セルフホストの保守性が維持される
- 実装の複雑度が爆発しない
---
### **2️⃣ Everything is Box/flow Main.main を維持**
**原則**: すべての値はBox、すべての関数はBox/flowのメソッド
```nyash
// ✅ 正しい設計
box OptionBox<T> {
value: T
is_some: BoolBox
birth(v: T) {
me.value = v
me.is_some = true
}
unwrap(): T {
if not me.is_some {
panic("unwrap on None")
}
return me.value
}
}
// T? → OptionBox<T> へデシュガリング
local x: IntegerBox? = getSomeValue()
// ↓
local x: OptionBox<IntegerBox> = getSomeValue()
```
**Pulse は下限**:
- 最小限の型として利用
- 言語機能には持ち込まない
---
### **3️⃣ Effects/Capabilities/Contracts は meta 側**
**原則**: 言語仕様には持ち込まない、metaレイヤーで処理
```nyash
// ❌ 言語機能化（採用しない）
effect IO {
read(path: StringBox): ResultBox<StringBox>
write(path: StringBox, data: StringBox): ResultBox<Unit>
}
fn process() with IO {
// IO効果を要求
}
// ✅ meta側で処理（視覚糖衣のみ）
with net.out, fs.read {
http.get("https://api.example.com")
file.read("config.txt")
}
// ↓ 実際は何も変えない（ログに印を出すだけ）
```
**効果システムの取り扱い**:
- **静的解析ツール**で検出（Linter/型チェッカー）
- **ランタイムは関与しない**
- **視覚的な開発体験向上**のみ
---
### **4️⃣ 例外は導入しない**
**原則**: panicはVM/実装バグ用、通常はResultBoxで伝播
```nyash
// ✅ 正しいエラー処理（ResultBox + ? 演算子）
box FileBox {
read(path: StringBox): ResultBox<StringBox> {
// エラー時はResultBox::Err返却
}
}
flow Main.main() {
local content = FileBox::read("config.txt")? // ? で伝播
processContent(content)
}
// ❌ 例外（採用しない）
try {
let content = FileBox::read("config.txt")
} catch(FileNotFoundError e) {
// ...
}
```
**panic の用途**:
- VM内部エラー（配列境界外アクセス等）
- 実装バグ（unreachable!相当）
- **通常のエラーハンドリングには使わない**
---
### **5️⃣ dev→prod の挙動差は policy のみ**
**原則**: warn/audit/enforce で制御
```nyash
// ✅ policy制御
debug_assert(internal.isValid()) // dev: panic, prod: nop
// ❌ 挙動差を言語機能に（採用しない）
if DEBUG_MODE {
checkInvariant()
}
```
**policy種別**:
- **warn**: 警告のみ
- **audit**: ログ記録
- **enforce**: エラー（dev/prod共通）
---
## 🍬 デシュガリング実例集
### **A. 型システム**
#### **Optional型 `T?`**
```nyash
// 糖衣構文
local x: IntegerBox? = getSomeValue()
// ↓ デシュガリング後
local x: OptionBox<IntegerBox> = getSomeValue()
// OptionBoxは標準ライブラリで実装
box OptionBox<T> {
value: T
is_some: BoolBox
birth(v: T) { me.value = v; me.is_some = true }
birth_none() { me.is_some = false }
unwrap(): T { /* ... */ }
is_some(): BoolBox { return me.is_some }
is_none(): BoolBox { return not me.is_some }
}
```
**MIR命令増加**: なし（既存のMirCall, Branch, Return等で実現）
#### **Union型 `A|B`**
```nyash
// 糖衣構文
type Result = OkBox | ErrorBox
// ↓ デシュガリング後
type Result = SumBox<OkBox, ErrorBox>
// SumBoxは標準ライブラリで実装
box SumBox<A, B> {
tag: StringBox // "A" or "B"
value_a: A
value_b: B
birth_left(a: A) { me.tag = "A"; me.value_a = a }
birth_right(b: B) { me.tag = "B"; me.value_b = b }
match_sum<R>(on_left: fn(A) -> R, on_right: fn(B) -> R): R {
if me.tag == "A" {
return on_left(me.value_a)
} else {
return on_right(me.value_b)
}
}
}
```
**MIR命令増加**: なし
---
### **B. 並行処理**
#### **`async {}` スコープ**
```nyash
// 糖衣構文
async {
nowait task1 = longTask1()
nowait task2 = longTask2()
// スコープ終了で自動待機
}
// ↓ デシュガリング後
local group = new TaskGroupBox()
group.spawn(fn() { longTask1() })
group.spawn(fn() { longTask2() })
group.await_all() // スコープ終了時自動
// TaskGroupBoxは標準ライブラリで実装
box TaskGroupBox {
tasks: ArrayBox<FutureBox>
spawn(task: fn()) {
local future = nowait task()
me.tasks.push(future)
}
await_all() {
loop(me.tasks.len() > 0) {
local future = me.tasks.pop()
await future
}
}
}
```
**MIR命令増加**: なし（既存のnowait/awaitで実現）
#### **`select {}` 式**
```nyash
// 糖衣構文
match select {
ch1.receive() => { handle1() }
ch2.receive() => { handle2() }
timeout(1000) => { handleTimeout() }
}
// ↓ デシュガリング後
local sel = new SelectBox()
sel.on(ch1, fn(v) { handle1() })
sel.on(ch2, fn(v) { handle2() })
sel.on_timeout(1000, fn() { handleTimeout() })
sel.run()
// SelectBoxは標準ライブラリで実装
box SelectBox {
channels: ArrayBox<ChannelBox>
handlers: ArrayBox<fn(Any)>
on(ch: ChannelBox, handler: fn(Any)) {
me.channels.push(ch)
me.handlers.push(handler)
}
on_timeout(ms: IntegerBox, handler: fn()) { /* ... */ }
run() {
// poll all channels, invoke first ready handler
}
}
```
**MIR命令増加**: なし
---
### **C. 糖衣構文**
#### **パイプライン演算子 `|>`**
```nyash
// 糖衣構文
value |> f(_) |> g(_, 42) |> h(_)
// ↓ デシュガリング後
h(g(f(value), 42))
// 実用例
[1, 2, 3, 4, 5]
|> map(_, fn(x) { x * 2 })
|> filter(_, fn(x) { x % 3 == 0 })
|> reduce(_, 0, fn(acc, x) { acc + x })
// ↓ デシュガリング後
reduce(filter(map([1,2,3,4,5], fn(x){x*2}), fn(x){x%3==0}), 0, fn(acc,x){acc+x})
```
**MIR命令増加**: なし（ただの関数呼び出し順序変更）
#### **名前付き引数**
```nyash
// 糖衣構文
download(url: u, timeout: 3.s, retry: 5)
// ↓ デシュガリング後（位置引数 + デフォルト補完）
download(u, 3.s, 5)
// 欠けた引数はデフォルト補完
download(url: u)
// ↓
download(u, DEFAULT_TIMEOUT, DEFAULT_RETRY)
```
**MIR命令増加**: なし（静的パスで位置引数に変換）
#### **`with capability` スコープ**
```nyash
// 糖衣構文
with net.out, fs.read {
http.get("https://api.example.com")
file.read("config.txt")
}
// ↓ デシュガリング後（何も変えない）
// metaレイヤーでログに印を出すだけ
http.get("https://api.example.com")
file.read("config.txt")
```
**MIR命令増加**: なし（完全に視覚糖衣）
---
### **D. マクロ**
#### **`@test` マクロ**
```nyash
// 糖衣構文
@test
it("should add numbers") {
local calc = new Calculator()
expect(calc.add(2, 3)).toBe(5)
}
// ↓ デシュガリング後（HIRパッチ）
TestRunnerBox::register("should add numbers", fn() {
local calc = new Calculator()
expect(calc.add(2, 3)).toBe(5)
})
// TestRunnerBoxは標準ライブラリ
static box TestRunnerBox {
tests: ArrayBox<TestCase>
register(name: StringBox, test: fn()) {
me.tests.push(new TestCase(name, test))
}
run_all() {
loop(me.tests.len() > 0) {
local test = me.tests.pop()
test.run()
}
}
}
```
**MIR命令増加**: なし（HIRレベルでパッチ）
#### **`@profile` マクロ**
```nyash
// 糖衣構文
@profile
calculate() {
// 処理
}
// ↓ デシュガリング後（HIRパッチ）
calculate() {
local _prof = ProfileBox::start("calculate")
// 処理
_prof.end()
}
// ProfileBoxは標準ライブラリ
box ProfileBox {
name: StringBox
start_time: TimeBox
static start(name: StringBox): ProfileBox {
local prof = new ProfileBox()
prof.name = name
prof.start_time = TimeBox::now()
return prof
}
end() {
local duration = TimeBox::now() - me.start_time
ConsoleBox::log("Profile: " + me.name + " took " + duration.toString())
}
}
```
**MIR命令増加**: なし
---
## 📊 デシュガリング規則一覧表
| 構文 | デシュガリング後 | 実装方法 | MIR命令増加 | Phase |
|------|----------------|---------|------------|-------|
| `T?` | `OptionBox<T>` | 標準ライブラリ | なし | 20 |
| `A\|B` | `SumBox<A,B>` | 標準ライブラリ | なし | 20 |
| `x \|> f(_)` | `f(x)` | 静的パス（AST変換） | なし | 17-18 |
| `f(a:1, b:2)` | `f(1,2)` | 静的パス（引数並び替え） | なし | 18-19 |
| `async { body }` | `TaskGroupBox::scoped(...)` | 標準ライブラリ | なし | 22 |
| `select { ... }` | `SelectBox::new()...run()` | 標準ライブラリ | なし | 23 |
| `@test it(...){...}` | `TestRunnerBox::register(...)` | マクロ（HIRパッチ） | なし | 16.1 |
| `@bench(iter:N) { ... }` | `BenchmarkBox::run(...)` | マクロ（HIRパッチ） | なし | 16.3 |
| `@profile { ... }` | `ProfileBox::start()` + `.end()` | マクロ（HIRパッチ） | なし | 20 |
| `repr(obj)` | `@derive(Debug)` 連携 | マクロ（HIRパッチ） | なし | 18 |
| `x.move()` | 所有権移転メソッド | 標準ライブラリ | なし | 28 |
| `x.share()` | Arc参照増加メソッド | 標準ライブラリ | なし | 28 |
| `x.weak()` | 弱参照取得メソッド | 標準ライブラリ | なし | 28 |
| `with cap { ... }` | （何も変えない） | 視覚糖衣（meta） | なし | 20-22 |
| `comptime { ... }` | 定数埋め込み | 静的パス（ビルド時評価） | なし | 22-25 |
| `pattern Some(x)` | `OptionBox::Some(x)` | 静的パス（パターン別名） | なし | 23-25 |
**重要**: すべてMIR命令増加なし！
---
## 🔍 デシュガリング検証方法
### **1. コンパイラフラグ**
```bash
# デシュガリング前のAST表示
$ hakorune --dump-ast program.hkr
# デシュガリング後のHIR表示
$ hakorune --dump-hir program.hkr
# 最終MIR表示（MIR14のみ）
$ hakorune --dump-mir program.hkr
```
### **2. スモークテスト**
```bash
# デシュガリング検証スイート
$ tools/smokes/v2/run.sh --profile desugaring
```
### **3. Linter検出**
```bash
# レガシー命令検出
$ HAKO_OPT_DIAG=1 hakorune program.hkr
# レガシー命令禁止（Fail-Fast）
$ HAKO_OPT_DIAG_FORBID_LEGACY=1 hakorune program.hkr
```
---
## 🚨 契約違反の例（やってはいけない）
### **❌ 悪い例1: MIR命令を追加**
```rust
// ❌ NG: Optional型のために新命令追加
enum MirInstruction {
// ... 既存14命令 ...
SomeCheck(ValueId), // ← 追加してはいけない！
NoneCheck(ValueId), // ← 追加してはいけない！
}
// ✅ OK: OptionBoxで実現
box OptionBox<T> {
is_some(): BoolBox { return me.is_some }
// MirCall で呼び出し（既存命令）
}
```
### **❌ 悪い例2: 効果システムを言語機能に**
```nyash
// ❌ NG: 効果システムを型システムに統合
effect IO {
read(path: StringBox): ResultBox<StringBox>
}
fn process() with IO {
// VM/コンパイラが効果を追跡
}
// ✅ OK: meta側で処理（視覚糖衣）
with io {
process() // ログに印を出すだけ
}
```
### **❌ 悪い例3: 例外を導入**
```nyash
// ❌ NG: try-catch構文を実装
try {
dangerousOp()
} catch(NetworkError e) {
// ...
}
// ✅ OK: ResultBox + ? 演算子
local result = dangerousOp()? // Err時は早期return
```
---
## 📚 参考資料
- [MIR Instruction Set](../../../reference/mir/INSTRUCTION_SET.md) - MIR14命令セット詳細
- [言語進化ロードマップ v2.0](./README.md) - 実装計画
- [Phase 16 Macro Revolution](../phases/phase-16-macro-revolution/README.md) - マクロシステム詳細
- [Discoverability問題分析](./discoverability-analysis.md) - 発見性問題と解決策
---
## 🎊 まとめ
**De-sugaring Contract（デシュガリング契約）** により、Hakoruneは：
1. ✅ **コアは最小** - MIR14命令セットを凍結
2. ✅ **糖衣は最強** - すべての新機能をデシュガリング/Box/マクロで実現
3. ✅ **保守性最高** - セルフホストの実装容易性維持
4. ✅ **一貫性抜群** - Everything is Box哲学貫徹
5. ✅ **拡張性無限** - Box/マクロでいくらでも拡張可能
この原則により、**次世代言語の標準** を打ち立てます。
---
**作成者**: Claude Sonnet 4.5 + ChatGPT Pro
**作成日**: 2025-10-02
**関連**: [言語進化ロードマップ v2.0](./README.md)

379
docs/private/roadmap/language-evolution/discoverability-analysis.md Normal file
View File

@ -0,0 +1,379 @@
# 🔍 Hakorune 機能発見性（Discoverability）問題の深層分析
**問題**: ChatGPTですら、こんな冗長コードを書いてしまう：
```nyash
hex_digit(ch) {
if ch == "0" { return 0 }
if ch == "1" { return 1 }
if ch == "2" { return 2 }
// ... 続く16行
}
```
**本来あるべき姿**（既に実装済み機能で書ける）：
```nyash
// 方法1: match式（Phase 12.7実装済み）
hex_digit(ch) {
return match ch {
"0" => 0, "1" => 1, "2" => 2, "3" => 3,
"4" => 4, "5" => 5, "6" => 6, "7" => 7,
"8" => 8, "9" => 9, "a" => 10, "b" => 11,
"c" => 12, "d" => 13, "e" => 14, "f" => 15,
_ => 0
}
}
// 方法2: Mapリテラル（実装済み）
static box HexUtils {
hex_map: MapBox
birth() {
me.hex_map = new MapBox()
me.hex_map.set("0", 0)
me.hex_map.set("1", 1)
// ...
}
hex_digit(ch) {
return me.hex_map.get(ch)
}
}
// 方法3: indexOf（StringBox実装済み）
hex_digit(ch) {
local hex_chars = "0123456789abcdef"
return hex_chars.indexOf(ch)
}
```
---
## 📊 根本原因分析（5つの問題）
### **問題1: ドキュメント導線の弱さ**
**現状**:
```
docs/reference/language/LANGUAGE_REFERENCE_2025.md (1,500行)
↓
機能は書いてある
↓
でも「いつ使うか」が分からない
```
**不足している情報**:
- ❌ 「こういう場合はmatch式を使う」
- ❌ 「配列ルックアップ vs Map vs match の使い分け」
- ❌ 「Anti-Pattern（やってはいけない書き方）」
### **問題2: サンプルコード不足**
**現状**:
```
apps/examples/ ← 基本的なサンプルのみ
apps/tests/ ← テストケースはあるが学習用ではない
```
**不足**:
- ❌ Cookbook/Recipe集（「～したい時は？」）
- ❌ Best Practice集
- ❌ イディオム集（慣用句）
### **問題3: AI学習データの不足**
**現状**:
```
ChatGPT/Claudeの学習データ:
- JavaScript: 大量
- Python: 大量
- Rust: 中程度
- Nyash/Hakorune: ほぼゼロ
```
**結果**: JavaScriptパターンで書いてしまう
```javascript
// JavaScript風（冗長）
if (x == "a") return 1
if (x == "b") return 2
```
### **問題4: 糖衣構文の発見性**
**実装済みだが知られていない機能**:
- ✅ match式（Phase 12.7）
- ✅ Lambda式
- ✅ ?演算子（Result伝播）
- ✅ Mapリテラル
- ✅ 配列メソッド（indexOf/find等）
**問題**: 「機能がある」ことは分かっても、「いつ使うべきか」が分からない
### **問題5: Linter/Static Analysis不足**
**現状**: コード品質チェックがない
```nyash
// これを書いても警告が出ない（出るべき）
if ch == "0" { return 0 }
if ch == "1" { return 1 }
// ... 続く
```
**理想**: Linterが検出
```
Warning: Consider using match expression instead of if-else chain
→ Suggested refactoring:
match ch { "0" => 0, "1" => 1, ... }
```
---
## 🎯 解決策（5つの柱）
### **解決策1: Cookbook/Recipe集の作成** 🔴 最優先
**構成案**:
```markdown
docs/cookbook/
├── README.md
├── patterns/
│ ├── lookup-table.md # ルックアップテーブル実装
│ ├── string-parsing.md # 文字列解析
│ ├── error-handling.md # エラー処理パターン
│ └── collections.md # コレクション操作
├── anti-patterns/
│ ├── if-chain.md # if連鎖のアンチパターン
│ ├── manual-loop.md # 手動ループのアンチパターン
│ └── null-check.md # null チェックのアンチパターン
└── refactoring/
├── if-to-match.md # if → match変換
├── loop-to-map.md # ループ → map/filter変換
└── manual-to-builtin.md # 手動実装 → ビルトイン変換
```
**例**: `docs/cookbook/patterns/lookup-table.md`
```markdown
# ルックアップテーブルパターン
## ❌ Anti-Pattern（やってはいけない）
```nyash
hex_digit(ch) {
if ch == "0" { return 0 }
if ch == "1" { return 1 }
// ... 冗長
}
```
## ✅ Pattern 1: match式（推奨、シンプルなルックアップ）
```nyash
hex_digit(ch) {
return match ch {
"0" => 0, "1" => 1, "2" => 2, ...
_ => 0
}
}
```
## ✅ Pattern 2: indexOf（文字列ベース）
```nyash
hex_digit(ch) {
return "0123456789abcdef".indexOf(ch)
}
```
## ✅ Pattern 3: MapBox（複雑な値）
```nyash
static box HexMap {
map: MapBox
birth() {
me.map = new MapBox()
me.map.set("zero", 0)
// ...
}
}
```
## 使い分け
- シンプルなルックアップ → match式
- 連続文字 → indexOf
- 複雑な値/初期化 → MapBox
```
---
### **解決策2: Quick Reference拡充** 🟡
**現状**: 文法中心
**改善**: Use Case中心に再構成
```markdown
# Use Case別 Quick Reference
## 文字列解析
- hex変換 → indexOf/match
- split → string.split()
- 正規表現 → RegexBox
## ルックアップ
- 固定値 → match
- 動的 → MapBox
- 連続 → indexOf
## 繰り返し処理
- 変換 → array.map()
- フィルタ → array.filter()
- 集約 → array.reduce()
```
---
### **解決策3: サンプルコード集の充実** 🟡
**追加すべきサンプル**:
```
apps/examples/
├── cookbook/
│ ├── hex_parser.hkr # hex解析の正しい書き方
│ ├── json_parser.hkr # JSON解析
│ ├── state_machine.hkr # ステートマシン
│ └── validator.hkr # バリデーション
├── best-practices/
│ ├── match_vs_if.hkr # match vs if使い分け
│ ├── map_vs_array.hkr # Map vs Array選択
│ └── error_handling.hkr # エラー処理パターン
└── anti-patterns/
├── if_chain_bad.hkr # ❌ 悪い例
└── if_chain_good.hkr # ✅ 良い例
```
---
### **解決策4: Linter/フォーマッター導入** 🟢
**Phase 18-20で実装検討**:
```bash
# Linter実行
$ hakorune lint my_code.hkr
Warning: Inefficient if-else chain detected
--> my_code.hkr:10:5
|
10 | if ch == "0" { return 0 }
11 | if ch == "1" { return 1 }
| ^^^^^^^^^^^^^^^^^^^^^^^^^ Consider using match expression
|
= help: match ch { "0" => 0, "1" => 1, ... }
```
**検出すべきAnti-Pattern**:
1. If-else連鎖（match式推奨）
2. 手動ループ（map/filter推奨）
3. 未使用変数
4. 型不一致（opt-in型チェック時）
---
### **解決策5: AI学習用データ整備** 🟢
**コンテキスト注入用ファイル**:
```
docs/for-ai/
├── PATTERNS.md # 推奨パターン集
├── ANTI_PATTERNS.md # アンチパターン集
├── IDIOMS.md # 慣用句集
└── COMMON_MISTAKES.md # よくある間違い
```
**CLAUDE.mdに追加**:
```markdown
## 🤖 AI開発者への注意事項
### ❌ やってはいけないパターン
1. If-else連鎖 → match式を使う
2. 手動for文 → map/filter/reduce
3. null手動チェック → ?演算子
### ✅ 推奨パターン
1. ルックアップ → match/indexOf/MapBox
2. 変換 → array.map()
3. エラー処理 → Result + ?演算子
```
---
## 📅 実装優先順位
### **Phase 17（即座）** 🔴
1. **Cookbook/Recipe集作成**
- `docs/cookbook/patterns/lookup-table.md`
- `docs/cookbook/anti-patterns/if-chain.md`
- `docs/cookbook/refactoring/if-to-match.md`
2. **CLAUDE.md拡充**
- AI開発者への注意事項セクション追加
- よくあるアンチパターン明記
### **Phase 18-19** 🟡
3. **サンプルコード集**
- `apps/examples/cookbook/` 作成
- ベストプラクティス実装例
4. **Quick Reference再構成**
- Use Case中心に再編成
### **Phase 20-22** 🟢
5. **Linter/フォーマッター**
- Anti-Pattern検出
- 自動リファクタリング提案
---
## 🎯 期待される効果
### **短期効果（Phase 17）**
- ✅ AI（ChatGPT/Claude）がアンチパターンを避ける
- ✅ 新規開発者が正しい書き方を学べる
- ✅ コードレビュー時の指摘減少
### **中期効果（Phase 18-19）**
- ✅ サンプルコードからコピペで正しいコード
- ✅ 言語機能の利用率向上
- ✅ コード品質の一貫性向上
### **長期効果（Phase 20-22）**
- ✅ Linterが自動で品質保証
- ✅ リファクタリングが容易
- ✅ 技術的負債の削減
---
## 💡 名言化
> **「機能があっても、使われなければ意味がない」**
>
> Hakoruneは強力な機能を持つ。
> しかし、その使い方が伝わらなければ宝の持ち腐れ。
>
> **Cookbook/Recipe集で「発見性」を高める**ことが、
> 次のPhaseの最重要課題。
---
## 🎊 まとめ
ChatGPTが冗長なif連鎖を書いてしまった問題は、
**言語機能の不足ではなく、発見性（Discoverability）の問題**。
**解決策5本柱**:
1. 🔴 Cookbook/Recipe集作成（Phase 17、最優先）
2. 🟡 Quick Reference拡充（Phase 17-18）
3. 🟡 サンプルコード集（Phase 18-19）
4. 🟢 Linter/フォーマッター（Phase 20-22）
5. 🟢 AI学習用データ整備（Phase 17-19）
**Phase 17で即座に着手すべき**:
- `docs/cookbook/` ディレクトリ作成
- Anti-Pattern集の整備
- CLAUDE.mdへのAI開発者向け注意事項追加
これにより、「つよつよ機能」が「実際に使われる」ようになりますにゃ！

509
docs/private/roadmap/language-evolution/v1-original.md Normal file
View File

@ -0,0 +1,509 @@
# 🚀 Nyash/Hakorune 言語進化ロードマップ
**作成日**: 2025-10-02
**対象**: Phase 16-30（言語機能・標準ライブラリの進化）
**関連**: [アーキテクチャ戦略](./architecture-strategy.md) - Rust vs セルフホスト実装戦略
---
## 📖 概要
Phase 15までの実装により、Nyash/Hakoruneは強力な基礎を確立しました。
このドキュメントは、糖衣構文・マクロ以外の体系的な言語機能進化を定義します。
**実装方針**: [アーキテクチャ戦略](./architecture-strategy.md)に従い、Phase 19以降の新機能は**セルフホストのみ**で実装します。
---
## 📊 現在の強み（Phase 15-16時点）
### ✅ **言語機能の充実度**
1. **プロパティシステム** (stored/computed/once/birth_once) - **業界最先端レベル**
2. **🚀 マクロシステム (Phase 16実装中)** - @derive/@test等、Box-Based Macro革命
3. **postfix catch/cleanup** - 非常にモダン（Swift/Kotlin風）
4. **Result伝播 (? 演算子)** - Rust風エラー処理
5. **match式** - パターンマッチング
6. **Lambda式** - 高階関数サポート
7. **using/namespace** - モジュールシステム基礎
8. **flow** - stateless namespace（静的関数グループ化）
9. **非同期** (nowait/await/FutureBox) - 並行処理基礎
10. **演算子オーバーロード** - トレイトベース
11. **変数宣言厳密化** - メモリ・非同期安全性保証
### ✅ **Box型ライブラリ充実度**
30種類以上のBox（String/Integer/Array/Map/JSON/Regex/HTTP/GUI等）
### ✅ **コンパクトな実装**
- セルフホスティングコンパイラ: **3,771行**
- Rust実装: 48,344行
- **圧縮率: 約7.8%（13分の1）**
---
## 🎯 進化計画（9の柱）
**注**: マクロシステム（旧🔟）はPhase 16で既に実装中のため、残り9項目を進化計画とします。
### **1️⃣ 型システムの段階的強化**
**現状**: 型アノテーションはP0では無視、実行時型エラー
**Phase**: 20-25
**優先度**: 🟡 中
**改善案**:
```nyash
// Phase A: 静的型チェック（opt-in）
@strict_types
box Calculator {
value: IntegerBox // 型検査ON
add(a: IntegerBox, b: IntegerBox): IntegerBox {
return a + b // 型不一致はコンパイルエラー
}
}
// Phase B: ジェネリクス/型パラメータ
box Container<T> {
items: ArrayBox<T>
add(item: T) {
me.items.push(item)
}
get(index: IntegerBox): T? { // Optional型
return me.items.get(index)
}
}
// Phase C: Union型・Intersection型
type Result = OkBox | ErrorBox
type Loggable = ConsoleBox & FileBox
```
**実装ステップ**:
1. Phase 20: 基本型チェック（opt-in）
2. Phase 22: ジェネリクス基礎
3. Phase 24: Union/Intersection型
---
### **2️⃣ エラーハンドリングの体系化**
**現状**: ResultBox, postfix catch/cleanup（基礎は良い）
**Phase**: 26-28
**優先度**: 🟢 低（現状で十分実用的）
**改善案**:
```nyash
// カスタムエラー型階層
box NetworkError from ErrorBox {
code: IntegerBox
message: StringBox
}
box TimeoutError from NetworkError { }
box ConnectionError from NetworkError { }
// エラー変換チェーン
fetchData()
.mapError(fn(e) { new AppError(e) })
catch(NetworkError e) {
retry()
}
catch(TimeoutError e) {
useCache()
}
cleanup {
closeConnection()
}
// panic/recover明確化
panic("critical error") // プログラム停止
recover(fn(e) { log(e); return defaultValue() }) // panic回復
```
---
### **3️⃣ テストフレームワーク統合** 🔴
**現状**: テスト機能なし（**最大の欠落！**）
**Phase**: 16-17
**優先度**: 🔴 最高（開発体験向上の鍵！）
**改善案**:
```nyash
// ビルトインテスト構文
@test
describe("Calculator") {
@test
it("should add numbers") {
local calc = new Calculator()
expect(calc.add(2, 3)).toBe(5)
assert(calc.value == 0)
}
@test
it("should handle errors") {
expectThrow(fn() { calc.divide(1, 0) })
}
}
// モック・スタブ
@mock
box MockHttpClient from HttpClient {
override get(url) {
return new MockResponse(200, "OK")
}
}
// プロパティベーステスト
@property_test(iterations: 1000)
it("commutative addition") forall(a: IntegerBox, b: IntegerBox) {
expect(a + b).toBe(b + a)
}
```
**実装ステップ**:
1. Phase 16.1: 基本テストフレームワーク（describe/it/expect）
2. Phase 16.2: アサーション拡張（toBe/toEqual/toThrow等）
3. Phase 16.3: モック・スタブ機能
4. Phase 17: プロパティベーステスト
**重要性**:
- セルフホスティング進行中の**今こそ**導入すべき
- Rust実装で先行実装 → セルフホストで再実装が理想
- TDD開発体験が言語採用の鍵
---
### **4️⃣ 並行処理の完成度向上**
**現状**: nowait/await/FutureBox（基礎のみ）
**Phase**: 21-25
**優先度**: 🟡 中
**改善案**:
```nyash
// チャネル/メッセージパッシング
local ch = new ChannelBox<IntegerBox>()
nowait producer = loop() {
ch.send(randomInt())
}
local value = ch.receive() // await不要
// 構造化並行性（Structured Concurrency）
async {
nowait task1 = longTask1()
nowait task2 = longTask2()
// すべて完了するまで待機（スコープ終了で自動）
// task1/task2のどちらかがエラー → 両方キャンセル
}
// Select式（複数Future待機）
match select {
ch1.receive() => { handle1() }
ch2.receive() => { handle2() }
timeout(1000) => { handleTimeout() }
}
// キャンセルトークン標準化
local token = new CancelTokenBox()
nowait task = longTask(token)
token.cancel() // タスク中断
```
**実装ステップ**:
1. Phase 21: ChannelBox実装
2. Phase 22: 構造化並行性（async block）
3. Phase 23: Select式
4. Phase 24: キャンセルトークン標準化
---
### **5️⃣ メモリ管理の可視性向上**
**現状**: Arc<Mutex>暗黙共有、outbox/weak未活用
**Phase**: 28-30
**優先度**: 🟢 低（現状で安全）
**改善案**:
```nyash
// 所有権移転の明示
outbox result = expensiveComputation() // moveセマンティクス
useResult(result) // resultは無効化
// 弱参照の標準化
box Parent {
weak child: ChildBox // 循環参照防止
}
// ライフタイムヒント（optional）
box Borrower<'a> {
reference: &'a StringBox // 借用明示
}
// クローン明示化
local copy = original.clone() // 深いコピー
local ref = original.share() // Arc参照増加
```
---
### **6️⃣ 標準ライブラリの体系化**
**現状**: 豊富だが命名・構造が不統一
**Phase**: 16-20
**優先度**: 🟡 中
**改善案**:
```nyash
// Rust std風階層構造
using std.collections // ArrayBox, MapBox, SetBox, QueueBox
using std.io // FileBox, StreamBox, BufferBox
using std.net // HttpClientBox, TcpBox, UdpBox
using std.sync // MutexBox, ChannelBox, AtomicBox
using std.time // TimeBox, DurationBox, TimerBox
using std.json // JSONBox（parse/stringify/schema）
using std.regex // RegexBox
using std.math // MathBox
using std.console // ConsoleBox
// 命名規則統一
// ❌ Before: array.length(), string.len(), map.size()
// ✅ After: collection.len() （統一）
// Prelude自動インポート
// StringBox, IntegerBox, ArrayBox等は自動利用可能
```
**実装ステップ**:
1. Phase 16: 命名規則統一計画策定
2. Phase 17: std.collections体系化
3. Phase 18: std.io/net/sync体系化
4. Phase 19-20: その他標準ライブラリ体系化
---
### **7️⃣ デバッグ・診断機能強化**
**現状**: DebugBox、基本的なprint
**Phase**: 18-20
**優先度**: 🟡 中（開発体験向上）
**改善案**:
```nyash
// repr()関数実装（構造的表示）
print(str(obj)) // "MyBox instance"
print(repr(obj)) // "MyBox { field1: 42, field2: "test" }"
// スタックトレース改善
try {
deepFunction()
} catch(e) {
print(e.stackTrace()) // 完全なコールスタック
}
// プロファイラ統合
@profile
calculate() {
// 実行時間・メモリ使用量を自動計測
}
// アサーション強化
assert(value > 0, "value must be positive")
debug_assert(internalState.isValid()) // devのみ
static_assert(SIZE == 64, "size must be 64") // コンパイル時
```
**実装ステップ**:
1. Phase 18: repr()関数実装
2. Phase 19: スタックトレース改善
3. Phase 20: プロファイラ統合・アサーション強化
---
### **8️⃣ ドキュメント生成機能**
**現状**: ドキュメント生成機能なし
**Phase**: 30+
**優先度**: 🟢 低
**改善案**:
```nyash
/// Calculator Box provides basic arithmetic operations.
///
/// # Examples
/// ```nyash
/// local calc = new Calculator()
/// calc.add(2, 3) // => 5
/// ```
box Calculator {
/// The current calculation result
result: IntegerBox
/// Adds two numbers
/// # Arguments
/// - `a`: First number
/// - `b`: Second number
/// # Returns
/// Sum of a and b
add(a: IntegerBox, b: IntegerBox): IntegerBox {
return a + b
}
}
// コマンド
$ hakorune doc --generate # HTML/Markdown生成
```
---
### **9️⃣ パッケージマネージャ完成**
**現状**: using system基礎実装
**Phase**: 18-20
**優先度**: 🟡 中
**改善案**:
```toml
# hako.toml（Cargo風）
[package]
name = "my-app"
version = "0.1.0"
authors = ["Me"]
[dependencies]
http-client = "1.2.0"
json-parser = "2.0.1"
[dev-dependencies]
test-framework = "0.5.0"
```
```bash
# コマンド
$ hako new my-project
$ hako build
$ hako test
$ hako run
$ hako publish
```
**実装ステップ**:
1. Phase 18: hako.toml依存関係解決
2. Phase 19: パッケージレジストリ設計
3. Phase 20: hako CLIコマンド実装
---
### **🔟 マクロシステム拡張**
**現状**: ✅ **Phase 16で実装中** - Box-Based Macro革命
**実装済み**:
- @derive(Equals, ToString, Clone, Debug)
- @test マクロ + テストランナー
- AST Pattern Matching基盤
- Quote/Unquote システム
- HIRパッチ式マクロエンジン
📖 **詳細**: [Phase 16 Macro Revolution](./phases/phase-16-macro-revolution/README.md)
**今後の拡張**:
```nyash
// さらなる@deriveトレイト追加
@derive(Hash, Ord, Default, Serialize)
box MyBox { }
// カスタムマクロ定義
macro benchmark(iterations) {
// パフォーマンス計測マクロ
}
// comptime計算拡張
const CONFIG = comptime {
readFile("config.toml").parse()
}
```
**Phase**: 16（実装中）→ 17-20（拡張）
**優先度**: 🟡 中（コア実装済み、拡張は要望次第）
---
## 📅 実装タイムライン
### **Phase 16-17: 基礎固め**（最優先）
1. 🚀 **マクロシステム完成** - @derive/@test完全動作（Phase 16実装中）
2. 🟡 **標準ライブラリ体系化開始** - 命名規則統一
### **Phase 18-20: 開発体験向上**
3. 🟡 **デバッグ機能強化** - repr/スタックトレース
4. 🟡 **パッケージマネージャ完成** - 依存関係管理
5. 🟡 **標準ライブラリ体系化完成**
### **Phase 21-25: 高度機能**
6. 🟡 **並行処理完成** - チャネル/構造化並行性
7. 🟡 **型システム強化** - 静的型チェック opt-in/ジェネリクス
### **Phase 26-30: 洗練**
8. 🟢 **エラー体系化**
9. 🟢 **メモリ管理可視性**
10. 🟢 **ドキュメント生成**
---
## 💡 重要な設計原則
### **1. YAGNI原則遵守**
- マクロシステムは実際の要望が出てから
- 型システム強化はopt-in（段階的導入）
- メモリ管理可視性は現状で十分安全
### **2. Everything is Box哲学の維持**
- すべての新機能はBox化して提供
- 一貫性を最優先
### **3. セルフホスティング優先**
- Rust実装で先行実装 → セルフホストで再実装
- セルフホストでの実装容易性を考慮した設計
### **4. 後方互換性**
- 既存コードを壊さない
- 新機能はopt-inまたは新構文で提供
---
## 🎊 まとめ
### **Phase 16: マクロシステム実装中**
✅ @derive/@test等のBox-Based Macro革命が進行中！
セルフホスティング進行中の今、言語機能が加速度的に進化している。
### **現在の設計の優秀さ**
- **プロパティシステム**（once/birth_once）は**業界最先端レベル**
- **マクロシステム**（Phase 16実装中）はBox-Based設計で革新的
- **postfix catch/cleanup**は非常に直感的
- **Everything is Box哲学**が一貫している
- **コンパクトな実装**（Rust実装の13分の1）
### **長期ビジョン**
Phase 16-30を通じて、実用的で表現力豊かな言語へと進化。
マクロシステム・プロパティシステム・型システムの三位一体で、
次世代言語の標準を打ち立てる。
---
**作成者**: Claude Sonnet 4.5
**ベース**: ドキュメント深層分析（LANGUAGE_REFERENCE_2025.md, quick-reference.md, using.md）
**修正**: 2025-10-02 - Phase 16マクロシステム実装中の事実を反映

25
docs/private/roadmap/mir/core-13/step-50/README.md Normal file
View File

@ -0,0 +1,25 @@
# MIR step‑50: Final Reference Sync after Core Flip
Status: Done
Purpose: After the Core‑15→Core‑13 flip is complete in code/tests, perform a last wave of documentation alignment across top‑level entry points and user‑facing docs.
## Scope
- Update top‑level docs to reflect Core‑13 as canonical minimal kernel:
- `README.md` / `README.ja.md` (MIR summary snippet)
- `docs/reference/mir/INSTRUCTION_SET.md` (fix counts/maps; remove migration disclaimers)
- `docs/reference/architecture/*` (Core naming and diagrams)
- Add CHANGELOG note for the flip.
- DEV quickstart and contributor docs: link to Core‑13 reference and validation tests.
## Preconditions
- Tests enforce Core‑13 instruction count and legacy‑op forbiddance (see `src/mir/instruction_introspection.rs` and `src/tests/mir_core13_normalize.rs`).
- VM/JIT/AOT backends accept the reduced set (or have shims documented if not yet).
## Validation
- `cargo test` green with Core‑13 enforcement.
- `src/mir/instruction_introspection.rs` asserts exactly 13 in `core13_instruction_count_is_13`.
- `src/tests/mir_core13_normalize.rs` validates Array/Ref normalization to BoxCall.
## Rollback Plan
- Keep the Core‑15 reference/notes in `docs/private/roadmap/` (archive) for historical context.

173
docs/private/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/private/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/private/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/private/roadmap/native-plan/README.md Normal file
View File

@ -0,0 +1,114 @@
# 🚀 Nyash ネイティブビルド計画（Native Plan）
## 🎯 目的
開発者向けに「ビルド計画・段階的タスク・設計上の要点」を集約。
利用者向けの具体的なビルド手順は guides/ 以下の各ガイドを参照。
## 📋 重要リンク
- **現在のタスク**: [../../../CURRENT_TASK.md](../../../CURRENT_TASK.md)
- **コア概念（速習）**: [reference/architecture/nyash_core_concepts.md](../../reference/architecture/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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→あらゆる実行系** が綺麗に繋がるにゃ。

854
docs/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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/private/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チームに相談してください！

34
docs/private/roadmap/phase-31.4-blockbuilder-cleanup.md Normal file
View File

@ -0,0 +1,34 @@
# Phase‑31.4 — Selfhost BlockBuilder ModuleFunction 依存撤退（設計メモ）
Context
- BlockBuilderBox が `Mir.*` と `MirSchemaBox.*` の二系統 API を混在使用（約 60 箇所）。
- 生成フェーズで ModuleFunction 解決に依存し、自己ホスト実行時に name 解決ゆらぎ（Unknown module function）を招く。
- JsonEmitBox は BoxHelpers 経由へ統一済み。StringHelpers の依存は最小（int_to_str/json_quote）で妥当。
Goal（根治）
- BlockBuilderBox から ModuleFunction 依存（`Mir.*`/`MirSchemaBox.*` 呼び出し）を撤退し、Map/Array の直接生成（または MirSchemaBox の単一路）に統一する。
- 以後の自己ホスト系は、BoxAPI（MapBox/ArrayBox）＋ JsonEmitBox だけで MIR(JSON) を構築し、using/探索の影響を受けない。
Plan（小さく段階導入）
1) API統一（P1）
- `Mir.*` を全撤退。`MirSchemaBox.*` に一本化（inst_const/inst_ret/inst_compare/inst_binop/inst_branch/inst_jump/block/fn_main/module）。
- import も `using "selfhost/shared/mir/mir_schema_box.hako" as MirSchemaBox` に統一。
- 未使用の `StringHelpers` import を削除。
2) 直接生成（P2・最小）
- MirSchemaBox 呼び出し自体も Map/Array 直接構築に段階移行（可読性を維持するため mk_inst_* ヘルパを同ファイルに薄く導入）。
- 代表ルート（const_ret/compare_branch/binop/extern_call_ret）から順次適用。
3) 検証（Smokes/Strict）
- `selfhost_mircall_extern_from_builder_vm.sh` が Gate‑C→Mini‑VM で `true`。
- Gate‑C Strict（quick/quick‑lite）を既定ONのまま緑を維持（PARSE_STRICT/VERIFY_CORE_EXTERN）。
Acceptance
- BlockBuilderBox 内の ModuleFunction 呼び出しが 0。未使用 import なし。
- 生成 JSON 形状は現行のバリデータ（validate_shape/Gate‑C Reader）を満たす。
- 自己ホスト quick/selfhost スモークが緑（外部依存なし）。
Notes
- StringHelpers の使用は JsonEmitBox の補助（int_to_str/json_quote）のみ許容。数値正規化は BoxHelpers で担保。
- MirSchemaBox は SSOTとして残すが、将来的に Map 直接生成へ段階移行（設計単純化のため）。

417
docs/private/roadmap/phases/00_MASTER_ROADMAP.md Normal file
View File

@ -0,0 +1,417 @@
# 🚀 Hakorune開発マスタープラン
Status: Active Development
Last Updated: 2025-10-06
Purpose: Claude×Copilot×ChatGPT×Gemini協調開発の総合ロードマップ
## 📍 現在位置
- **現在フェーズ**: Phase 19 - @enum/@match Macros (Choice A'')
- **進捗**: Day 1/14 完了 (7%) ✅ → Day 2 進行中 🔄
- **期間**: 2-3 weeks (9-14 days)
- **次フェーズ**: Phase 19 完了 → Mini-VM Migration (with @match)
- **備考**: Pattern matching for selfhost compiler ("ガチガチ大作戦")
**最新完了**: Day 1 - @enum Parser Extension (2025-10-08)
---
## 🗺️ フェーズ概要
### ✅ **完了済みフェーズ（Phase 1-14）**
| Phase | 状態 | 概要 | 詳細リンク |
|-------|------|------|------------|
| 1-7 | ✅完了 | 言語設計・パーサー・基本機能実装 | - |
| 8.4 | ✅完了 | AST→MIR Lowering完全実装 | [phase_8_4_ast_mir_lowering.md](phase-8/phase_8_4_ast_mir_lowering.md) |
| 8.5 | ✅完了 | MIRダイエット（35→26→15命令） | [phase_8_5_mir_35_to_26_reduction.md](phase-8/phase_8_5_mir_35_to_26_reduction.md) |
| 8.6 | ✅完了 | VM性能改善（0.9倍→2倍以上） | [phase_8_6_vm_performance_improvement.md](phase-8/phase_8_6_vm_performance_improvement.md) |
| 9 | ✅完了 | プラグインシステム基盤 | [phase-9/](phase-9/) |
| 9.75g-0 | ✅完了 | BID-FFI Plugin System | [Phase-9.75g-0-BID-FFI-Developer-Guide.md](phase-9/Phase-9.75g-0-BID-FFI-Developer-Guide.md) |
| 10 | 📋計画 | Cranelift JIT（主経路、将来検討） | [phase_10_cranelift_jit_backend.md](phase-10/phase_10_cranelift_jit_backend.md) |
| 11 | ✅完了 | LLVM統合・AOT実装 | [phase-11/](phase-11/) |
| 11.8 | 📋計画 | MIR整理（Core-15→Core-13） | [phase-11.8_mir_cleanup/](phase-11.8_mir_cleanup/) |
| 12 | ✅完了 | TypeBox統合ABI | [phase-12/](phase-12/) |
| 13 | 📋計画 | Hakoruneブラウザー革命 | [phase-13/](phase-13/) |
| 14 | 📋計画 | パッケージング・CI改善 | [phase-14/](phase-14/) |
---
### 🔥 **Phase 15系: セルフホスティング実現（進行中）**
#### ✅ **Phase 15: セルフホスティング基盤**
- **概要**: Hakoruneコンパイラ・Hakorune VM実装の総合計画
- **詳細**: [phase-15/](phase-15/)
#### ✅ **Phase 15.5: JSON v0中心化・統一Call基盤革命** (2025-09 完了)
- **概要**: セルフホスティング前の基盤アーキテクチャ大改革
- **成果**:
- Core Box統一
- MIR命令安定化
- LLVM PHI安定化
- 型変換統一化
- **詳細**: [phase-15.5/README.md](phase-15.5/README.md)
#### 🔥 **Phase 15.7: セルフホスティング実現への道筋 - Hakoruneコンパイラ完成計画** (進行中)
- **期間**: 2025-09-28 ~ 2025-10-20（予想）
- **進捗**: **85-90%完成**（残り10-15%、1-2週間）
- **目標**: Hakorune言語で Hakorune をコンパイル・実行する
- **詳細**: [phase-15.7/README.md](phase-15.7/README.md)
**First Goal（M1 — Bootstrap）**
- Hakorune コンパイラー（apps/selfhost-compiler/compiler.hako）を Hakorune でビルドし、LLVM で EXE 化
- 受け入れ: build_llvm.sh で EXE 生成 → `-- --min-json` 実行で JSON ヘッダ非空
- スモーク: `selfhost_bootstrap_llvm.sh`（quick/selfhost、既定SKIP）
**完了済み（85-90%）**:
- ✅ P2-A/B/C（Using解決系）完全実装
- UsingResolverBox実装（1日で完了、見積もり7日 → **85%短縮！**）
- NamespaceBox実装（1日で完了、見積もり5日 → **80%短縮！**）
- Pipeline V2統合（1日で完了、見積もり3日 → **67%短縮！**）
- ✅ SignatureVerifier/MethodRegistry（品質強化）
- ✅ Hakorune VM基盤（InstructionScannerBox/OpHandlersBox/ProgramStateBox等）
- ✅ FlowRunner/JsonProgramBox
- ✅ Pipeline V2基礎実装
- ✅ Quick smokes 常緑（172/172 PASS）
- ✅ TimerBox実装完了
- ✅ Hakorune VM への改名完了（Mini-VM → Hakorune VM）
**残り10-15%（1-2週間）**:
- 🔥 **Hakorune VM命令拡張（最後の砦）**
- newbox（2日・最重要）← **今ココ！**
- boxcall（2日・最重要）
- phi（2日）
- load/store（2日）
- externcall（1日）
- 🔲 セルフホストループE2E（1週間）
**教訓（Lessons Learned）**:
1. **Box-First設計の威力**: 新機能追加が予想の**9倍速**
2. **見積もりの精度**: 初期見積もりは慎重すぎた
3. **並行開発の難しさ**: 実際は順次開発が正解
4. **品質ファーストの重要性**: 計画外の成果が大きい
#### ✅ **Phase 15.8: LLVM→WASM実装** (2025-10-01~10-22 完了)
- **概要**: MIR16命令をWASMに変換、ブラウザ/エッジ環境で実行可能に
- **成果**: WebAssembly完全対応
- **詳細**: [phase-15.8/README.md](phase-15.8/README.md)
#### ✅ **Phase 15.9: VmConfig集約化** (2025-10-05 完了)
- **概要**: 環境変数42ファイル散在→1箇所集約
- **成果**: パフォーマンス向上、管理性改善
- **コミット**: `f1874b3b`
#### ✅ **Phase 15.10: Legacy Code大掃除** (2025-10-05 完了)
- **概要**: 2大ファイル→8小ファイル分割
- **成果**: デッドコード470行削除、純削減400行
- **コミット**: `43679766`, `f6cbbf48`, `f1f3b83e`
- **詳細**: legacy.rs分割（calls:617行 + boxes:518行）
#### ✅ **Phase 15.11: StringHelpers共通ライブラリ箱化** (2025-10-05 完了)
- **概要**: セルフホストコード重複削減
- **成果**: 14ファイル統合で335行純削減
- **詳細**:
- Phase 15.11: 319行削減 (380削除 - 61追加)
- Phase 15.11.1: 15行削減 (22削除 - 7追加) - ChatGPT協力
- 合計削減: 335行
- 重複削除: 7種類のヘルパー関数を統合
- **コミット**: `6ba6b026` (本体), `d07f3af3` (追加統合), `0de80fa6` (docs)
#### 📋 **Phase 15.12候補: index_of_from統一**
- **概要**: `index_of_from` → CfgNavigatorBox統合
- **見込み**: 60-100行削減
- **詳細**: `docs/development/proposals/ideas/improvements/phase-15-12-index-of-from-consolidation.md`
---
### 🌟 **Phase 16-20系: マクロシステム（計画・一部完了）**
#### ✅ **Phase 16: マクロ革命（Rust実装版）** (2025-09-19 完了、バグあり)
- **状態**: Rust実装完了、バグ発見により暫定対応中
- **成果**:
- AST Pattern Matching実装
- Quote/Unquote実装
- Match式構文実装
- @derive(Equals, ToString)実装
- @test ランナー実装
- **問題**: フル機能にバグあり
- **暫定対応**: `.hako`で単純置き換えマクロ実装中（`apps/macros/`）
- **詳細**: [phase-16-macro-revolution/README.md](phase-16-macro-revolution/README.md)
#### 🔥 **Phase 19: @enum/@match Macros (Choice A'')** (2025-10-08~ 進行中)
- **状態**: 進行中（Day 1 ✅ → Day 2 🔄）
- **進捗**: Day 1/14 (7% complete)
- **期間**: 2-3 weeks (9-14 days)
- **戦略**: Macro-Only Approach (NO VariantBox Core)
- **目標**: Pattern matching for selfhost compiler
- **Day 1 完了内容** (2025-10-08):
- ✅ TokenType::AT 追加（@ 文字認識）
- ✅ AST拡張（EnumVariant struct + ASTNode::EnumDeclaration）
- ✅ enum_parser.rs 実装（150行）
- ✅ パーサー統合完了
- ✅ テスト実行成功（@enum Result/Option パース成功）
- **Day 2 予定** (2025-10-09):
- 🔄 enum_expander.rs 作成
- 🔄 EnumDeclaration → Box 変換実装
- 🔄 静的コンストラクタ生成
- 🔄 ヘルパーメソッド生成（is_*/as_*）
- **成果目標**:
- @enum macro implementation (Week 1)
- @match macro implementation (Week 2-3)
- Option/Result @enum version
- 3-5 Mini-VM files migrated to @match
- **Out of Scope**: VariantBox Core, EnumSchemaBox, SymbolBox (→ Phase 20+)
- **詳細**: [phase-19-enum-match/README.md](phase-19-enum-match/README.md)
- **ユーザー意図**: "ガチガチ大作戦" - 中途半端（half-baked）回避
#### 📋 **Phase 20: Advanced Enum Features (Post-Selfhost)**
- **状態**: 計画中（Phase 19 完了後）
- **目的**: VariantBox Core + 高度な enum 機能実装
**Phase 20.X: VariantBox + enum/match 完全実装** (18-27人日)
- **Phase 20.6**: VariantBox Core（3-5人日）← Phase 19 から延期
- **Phase 20.7**: @enum マクロ拡張（VariantBox 版）（5-7人日）
- **Phase 20.8**: @match マクロ拡張（高度パターン）（7-10人日）
- **Phase 20.9**: Option/Result 移行（3-5人日）
**延期された機能**（Phase 19 から）:
- ✅ VariantBox Core 実装
- ✅ EnumSchemaBox
- ✅ SymbolBox（タグ最適化）
- ✅ コンパイル時網羅性チェック
- ✅ 高度パターン（ガード、リテラル、ネスト）
**Phase 20.0-20.5: マクロフル機能（Hakorune実装版）**
- **状態**: 計画中（セルフホスティング完了後に開始）
- **目的**: Phase 16のRust実装をHakoruneでセルフホスト実装に書き直す
- **優先機能**:
1. @derive(Equals, ToString) - 最も便利
2. @test ランナー - セルフホストコードのテスト自動化
3. AST Pattern Matching - 複雑なマクロ基盤
4. Quote/Unquote - テンプレート生成
- **詳細**: [phase-20-macro-full-features/README.md](phase-20-macro-full-features/README.md)
- **移行ガイド**: [phase-20-macro-full-features/MIGRATION.md](phase-20-macro-full-features/MIGRATION.md)
**Phase 20 内優先順位**:
```
Phase 20.0-20.3（マクロ基盤＋derive＋test）← 🔴 P1（最優先）
↓
Phase 20.6-20.9（VariantBox）← 🟢 P2（推奨）
↓
Phase 20.4-20.5（Pattern/Quote）← 🟡 P3（必要時）
↓
Python統合（Plan B）← 🔵 P4（長期計画）
```
### 🌟 **Phase 17以降（将来計画）**
| Phase | 状態 | 概要 | 詳細リンク |
|-------|------|------|------------|
| 17 | 🧪計画中 | LoopForm Self‑Hosting＋Hakorune VM | [phase-17-loopform-selfhost/](phase-17-loopform-selfhost/) |
| 17+ | 💡候補 | Rust所有権統合（オプショナル） | [rust-ownership-fusion](../../private/ideas/new-features/2025-09-22-rust-ownership-fusion.md) |
| 22 | 💡構想 | Hakorune LLVM Compiler | [phase-22/README.md](phase-22/README.md) |
---
## 🎯 Hakorune実行モード併用戦略
### 🌟 インタープリター＋コンパイラ併用の価値
#### 実行モード使い分け
```
開発時: Rust VM（デバッグ・即時実行）
本番時: Rust VM（Pythonのように実用的）
OR
WASM/AOT（性能要求時）
配布時: AOT native（最高性能）
Web時: WASM（ブラウザ対応）
```
#### インタープリターの強み
- **即時実行**: コンパイル不要で高速開発
- **デバッグ容易**: 実行時情報の完全把握
- **非同期完全対応**: Rust async/awaitで真の並行処理
- **動的性**: 実行時評価・REPL対応
- **十分な性能**: 多くのユースケースで実用的（Pythonが証明）
---
## 🚀 **Phase 15.7詳細: セルフホスティング実現への道筋**
### 🎯 **Phase 15.7の真の目的**
**「Hakorune で Hakorune をコンパイルする」完全なセルフホスティングの実現**
### 🔄 **セルフホストループの具体的4ステップ**
```
┌──────────────────────────────────────┐
│ Step 1: .hako ソース解析 │
│ ↓ │
│ Step 2: MIR JSON生成（コンパイラ） │
│ ↓ │
│ Step 3: MIR JSON実行（Hakorune VM） │
│ ↓ │
│ Step 4: 出力検証（パリティテスト） │
└──────────────────────────────────────┘
```
### 📅 **推奨実装順序**
#### **Week 1-2: Hakoruneコンパイラ MVP完成（P2優先）** ✅ 完了！
- ~~Day 1-2: branch/jump最小生成~~
- ~~Day 3: LocalSSA.ensure_cond最終化~~
- ~~Day 4-7: UsingResolverBox実装~~
- ~~Day 8-10: NamespaceBox実装~~
- ~~Day 11-14: Pipeline V2統合（using解決）~~
#### **Week 3: Hakorune VM命令拡張（最優先）** 🔥 今ココ！
- Day 1-2: newbox実装（Box生成）
- Day 3-4: boxcall + phi 並行実装
- Day 5-6: load/store + externcall 並行実装
- Day 7: 統合テスト・スモークテスト
#### **Week 4: セルフホストループE2E**
- Day 1-2: .hakoソース→MIR JSON生成確認
- Day 3-4: MIR JSON→Hakorune VM実行確認
- Day 5-6: パリティテスト（Rust VM vs Hakorune VM）
- Day 7: ブートストラップ達成！🎉
### 📊 **実装優先度マトリックス（2025-10-06更新）**
| 項目 | 優先度 | ステータス | 理由 | 見積 | 実績 | 担当領域 |
|----------------------|-------|-------|----------|------|------|------|
| branch/jump生成 | 🔴 P2 | ✅完了 | 制御フロー必須 | 2日 | 2日 | コンパイラ |
| LocalSSA.ensure_cond | 🔴 P2 | ✅完了 | 条件分岐安定化 | 1日 | 1日 | コンパイラ |
| **UsingResolverBox実装** | 🔴 P2-A | ✅**完了** | **using解決の核心** | 1週間 | **1日**✨ | コンパイラ |
| **NamespaceBox実装** | 🔴 P2-B | ✅**完了** | 名前空間解決 | 5日 | **1日**✨ | コンパイラ |
| **Pipeline V2統合（using）** | 🔴 P2-C | ✅**完了** | using→MIR変換 | 3日 | **1日**✨ | コンパイラ |
| **SignatureVerifier** | - | ✅**完了** | **計画外追加** | - | **1日** | コンパイラ |
| **MethodRegistry拡大** | - | ✅**完了** | **計画外追加** | - | **1日** | コンパイラ |
| **JsonCursorBox採用** | - | ✅**完了** | **計画外追加** | - | **1日** | 共通 |
| **Hakorune VM改名** | - | ✅**完了** | **ブランディング統一** | - | **1日** | Hakorune VM |
| **Hakorune VM newbox実装** | 🟡 P1-A | 🔥**最優先** | **Box生成（最重要！）** | 2日 | **未着手** | Hakorune VM |
| **Hakorune VM boxcall実装** | 🟡 P1-B | 🔥未着手 | **メソッド呼び出し** | 2日 | **未着手** | Hakorune VM |
| Hakorune VM phi実装 | 🟡 P1-C | 📝計画 | SSA合流 | 2日 | 未着手 | Hakorune VM |
| Hakorune VM load/store実装 | 🟡 P1-D | 📝計画 | メモリアクセス | 2日 | 未着手 | Hakorune VM |
| Hakorune VM externcall実装 | 🟡 P1-E | 📝計画 | print等外部呼び出し | 1日 | 未着手 | Hakorune VM |
| match式完全対応 | 🟡 P1-F | 📝計画 | 頻繁に使用 | 2日 | 未着手 | コンパイラ |
| Hakorune VM unaryop/typeop | 🟢 P3-A | 📝計画 | 単項演算・型操作 | 2日 | 未着手 | Hakorune VM |
| 最適化パス | 🟢 P3-B | 📝計画 | 性能向上 | 1週間 | 未着手 | コンパイラ |
| エラーハンドリング | 🟢 P3-C | 📝計画 | UX向上 | 3日 | 未着手 | コンパイラ |
**凡例**:
- 🔴 P2: 最優先（セルフホスティング必須）
- 🟡 P1: 高優先度（基本機能実装）
- 🟢 P3: 中優先度（改善・UX向上）
- ✅完了 / 🔥最優先 / 🔥未着手 / 📝計画 / ✨予想より早い達成
**達成状況**:
- ✅ **P2系完全達成**（コンパイラー側：using解決・品質強化）
- 🔥 **P1系が最優先**（Hakorune VM命令拡張：残り10-15%）
### 🎯 **達成基準（明確な終了条件）**
✅ **Phase 15.7完了 = 以下すべて満たす**:
1. UsingResolverBox/NamespaceBox動作
2. Hakorune VM 14命令すべて実装
3. .hakoソース→MIR JSON→Hakorune VM実行成功
4. c0（Rustコンパイラ）→c1（Hakoruneコンパイラ）動作
5. c1→c1'（自己コンパイル）成功
6. Quick smokes 全PASS維持
---
## 📊 Phase 15系の全体進捗
```
Phase 15系全体進捗: ████████████░ 85-90%完成
完了済み：
✅ Phase 15: セルフホスティング基盤設計
✅ Phase 15.5: JSON v0中心化・統一Call基盤革命
✅ Phase 15.8: LLVM→WASM実装
✅ Phase 15.9: VmConfig集約化
✅ Phase 15.10: Legacy Code大掃除
✅ Phase 15.11: StringHelpers共通ライブラリ箱化
🔥 Phase 15.7: セルフホスティング実現（85-90%、残り1-2週間）
次のステップ：
1. Hakorune VM命令拡張（newbox/boxcall/phi/load/store/externcall）
2. セルフホストループE2E検証
3. ブートストラップ達成！🎉
```
---
## 🏗️ 重要な設計原則
### 🧱 Box-First原則: 「箱理論」で足場を積む
Hakoruneは「Everything is Box」。実装・最適化・検証のすべてを「箱」で分離・固定し、いつでも戻せる足場を積み木のように重ねる。
#### 実践テンプレート（開発時の合言葉）
- 「箱にする」: 設定・状態・橋渡しはBox化（例: JitConfigBox, HandleRegistry）
- 「境界を作る」: 変換は境界1箇所で（VMValue↔JitValue, Handle↔Arc）
- 「戻せる」: フラグ・feature・env/Boxで切替。panic→フォールバック経路を常設
- 「見える化」: ダンプ/JSON/DOTで可視化、回帰テストを最小構成で先に入れる
- 「Fail-Fast」: エラーは隠さず即座に失敗。フォールバックより明示的エラー
### 🏗️ Everything is Box
- すべての値がBox（StringBox, IntegerBox, BoolBox等）
- ユーザー定義Box: `box ClassName { field1: TypeBox field2: TypeBox }`
- **MIR凍結セット**: 16命令で全機能実現！
---
## 🎓 重要な教訓（Lessons Learned）
### ✅ **Phase 15.7からの学び**
1. **Box-First設計の威力**
- 新機能追加が予想の**9倍速**で完了
- UsingResolver/Namespace実装は1日ずつで完了（見積もり18日 → 実績2日）
- Pipeline V2の強固な設計が成功の鍵
2. **見積もりの精度**
- 初期見積もりは慎重すぎた
- コンパイラー側: 見積もり18日 → 実績2日
- 基盤の成熟度を過小評価していた
3. **並行開発の難しさ**
- 実際は順次開発が正解
- Using解決がモジュールシステムの基盤
- コンパイラー完成 → Hakorune VM拡張の順が合理的
4. **品質ファーストの重要性**
- 計画外の成果が大きい
- SignatureVerifier/MethodRegistry/JsonCursorBox
- Fail-Fast文化の確立が開発速度を加速
---
## 📞 連絡・相談方法
技術的相談や進捗報告は、以下の方法でお気軽にどうぞ：
1. 📝 GitHub Issues・Pull Request
2. 📋 docs/CURRENT_TASK.md コメント
3. 🤖 AI大会議 (重要な技術決定)
4. 💬 コミットメッセージでの進捗共有
どんな小さなことでも相談大歓迎です！
一緒にHakoruneを最高の言語にしていきましょう🚀
---
**最終更新**: 2025-10-06 (Phase 15.7進捗反映・名前統一)
**作成者**: Claude (全面書き直し・Phase 15系統合)
### 🎯 重要な変更点
- ✅ **Phase 15系全面追加**（15.5/15.7/15.8/15.9/15.10/15.11）
- 🔄 **現在位置更新**（Phase 12 → Phase 15.7）
- 📊 **進捗率明確化**（85-90%完成、残り10-15%）
- 🎯 **セルフホスティング予定明確化**
- 📚 **教訓・Lessons Learned追加**
- 🏗️ **Box-First原則明記**

37
docs/private/roadmap/phases/FROZEN_TOOLCHAIN_STRATEGY.md Normal file
View File

@ -0,0 +1,37 @@
# Frozen Toolchain Strategy — Balanced Plan (Freeze‑First + Dual‑Run)
Purpose
- 捨てる（削減％）ではなく「契約を凍結」して自立へ前進する。Rust は発射台と保険、Hakorune は既定へ段階移行。
Principles
- Freeze the contracts first: JSON v0 MIR の形状と Core VM 最小意味論（const/binop/compare/branch/jump/phi/call代表）を先に固定。
- Dual‑Run migration: 同一契約に Rust 実装と Hakorune 実装を並走（プロファイル/ENVで切替）。パリティはスモークと Fail‑Fast で担保。
- Metrics shift: 「削減％」ではなく「契約準拠カバレッジ％」「自己ビルド再現率」を主要指標にする。
Phases (20.15 → 20.17)
- 20.15 Selfhost α（契約の骨格と計測）
- 固定: JSON v0 スキーマ、Core 最小意味論、診断タグ（Fail‑Fast）。
- 並走: emit→Core canary（既定OFF）、Rust/LLVM は parity 検証。
- 受け入れ: 契約準拠 canary 全緑・used‑before‑def 検出が安定。
- 20.16 Frozen v1（Stage 0→1→2）
- Stage 0: Rust で frozen‑v1 をビルド
- Stage 1: frozen‑v1 で同一ソースを再ビルド
- Stage 2: ハッシュ/正規化 diff 合意（再現性）
- ツールチェーン最小一式（compiler/core, runtime/minimal‑vm, stdlib/minimal）
- 20.17 自立化（既定切替・TTL整理）
- dev/quick 既定を Selfhost へ切替。Rust は fallback/検証。
- Runner 側の診断整形は TTL 撤去・Core に集約。ENV は HAKO_* 優先。
Acceptance Metrics
- 契約準拠カバレッジ: JSON v0 項目・Core ops の準拠率を canary/スモークで可視化。
- 自己ビルド再現性: Stage1→Stage2 の再現度（hash/size/正規化）。
- パリティ: Core vs LLVM/RustVM の差分検出（代表ケース）
Gates (default OFF)
- HAKO_GATE_C_CORE / NYASH_GATE_C_CORE — Gate‑C → Core 実行
- SMOKES_ENABLE_CORE_CANARY / SMOKES_ENABLE_2015 — 追加 canary 有効化
- HAKO_SELFHOST — Selfhost ルート（Stage 実行）
Rollback
- 既定切替は ENV/プロファイルで即戻し可能。契約は維持（後方互換）

54
docs/private/roadmap/phases/phase-10.11-builtins-to-plugins.md Normal file
View File

@ -0,0 +1,54 @@
# Phase 10.11: Builtins → Plugins Migration
## Goals
- Remove builtin Box implementations from execution paths (Interpreter/VM/JIT) to avoid divergence and double sources of truth.
- Provide all functionality via plugins (BID-FFI v1) and/or user-defined boxes.
- Keep backward compatibility guarded behind env flags until migration completes.
## Rationale
- Conflicts like ConsoleBox builtin vs plugin cause unexpected behavior.
- Native build (AOT/EXE) path benefits from uniform plugin boundary.
- One registry, one implementation per Box: simpler, safer.
## Plan (Incremental)
1) Disable Switch (Now)
- Add `NYASH_DISABLE_BUILTINS=1` to skip registering builtin box factory.
- Keep off by default; use in CI lanes and targeted tests.
2) Constructor Delegation (Now → Next)
- Ensure all constructors go through the unified registry, not direct builtin instantiation.
- Done: ConsoleBox; Next: remaining non-basic constructors.
3) Override Policy (Ongoing)
- Use `NYASH_USE_PLUGIN_BUILTINS=1` + `NYASH_PLUGIN_OVERRIDE_TYPES` to prefer plugins for selected types.
- Grow the allowlist as plugins become available.
4) Plugin Coverage (Milestones)
- ConsoleBox (stdout) — done
- Array/Map/String/Integer — in place
- File/Net/Python — in place
- Math/Time/etc. — add `nyash_box.toml` and minimal plugins
5) Remove Builtins (Final)
- Remove builtin factory or move into separate optional crate for legacy runs.
- Update docs, examples, and CI to plugin-only.
## Acceptance Criteria
- `NYASH_DISABLE_BUILTINS=1` + plugin set → examples run green (VM path).
- No direct builtins in interpreter constructors (registry only).
- JIT/AOT compile from MIR uses only plugin invoke shims for Box methods.
## How to Test
```bash
# Strict plugin preference + disable builtins
export NYASH_USE_PLUGIN_BUILTINS=1
export NYASH_PLUGIN_OVERRIDE_TYPES="ArrayBox,MapBox,ConsoleBox,StringBox,IntegerBox"
export NYASH_DISABLE_BUILTINS=1
cargo build --release --features cranelift-jit
./target/release/nyash --backend vm examples/console_demo.nyash
```
## Notes
- Temporary breakages expected when some builtin-only boxes remain. Use the override allowlist tactically.
- Keep `[libraries]` and `[plugins]` configured to ensure provider discovery.

48
docs/private/roadmap/phases/phase-11.9/PLAN.md Normal file
View File

@ -0,0 +1,48 @@
# Phase 11.9: 統一文法アーキテクチャ — 実装予定（MVP〜段階移行）
## 目的
- Tokenizer/Parser/Interpreter/MIR/VM/JIT の解釈差異を解消し、単一の「文法・意味・実行」定義から各層が参照する構造へ移行する。
- 変更や拡張（予約語/演算子/構文）のコストと不整合リスクを減らす。
## マイルストーン（MVP→段階導入）
### M1: 予約語レジストリの導入（最小）
- 追加: `src/grammar/engine.rs`（`UnifiedGrammarEngine`、`KeywordRegistry` の骨格）
- 追加: `grammar/unified-grammar.toml`（初期エントリ: `me`, `from`, `loop`, `+`）
- 追加: `build.rs` で TOML → `src/grammar/generated.rs` をコード生成（ランタイム I/O 回避）
- Tokenizer 統合（非侵襲）: 従来テーブルの後段に `engine.is_keyword()` を差し込み、`NYASH_GRAMMAR_DIFF=1` で差分ログ
- 成功条件: 既存テストを落とさず、差分ログが 0 or 想定内のみに収束
### M2: 演算子セマンティクスの統一（加算など最小）
- `ExecutionSemantics` に `operators.add` を定義（型規則/コアーション/エラー方針）
- Interpreter/VM/JIT で `execute_semantic("add", …)` による共通実装窓口を追加（従来実装はフォールバック）
- 既存 `hostcall_registry`/JIT ポリシーと接合するインターフェースを用意（型分類/シンボルの参照点を一本化）
- 成功条件: 文字列結合/整数加算/浮動小数加算の3系統で VM/JIT/Interpreter の一致を維持
### M3: 構文規則エンジンの段階導入
- `SyntaxRuleEngine` 追加、`statement`/`expr` の骨格ルールを TOML 側へ切り出し
- Parser 統合（段階的）: 既存パーサ優先＋新ルールでの検証を併走、差分ログで移行安全性を担保
- 成功条件: 代表サンプルで新旧の AST→MIR が一致（スナップショット）
### M4: 並行実行/差分検出・テスト整備
- 並行期間は新旧両系の結果を比較し、スナップショットとファズで回帰防止
- 収束後、旧ルートを段階的に縮退
## 実装順（詳細 TODO）
1) `build.rs` と `src/grammar/mod.rs` の雛形追加（`generated.rs` を `include!`）
2) `KeywordRegistry` の生成コードを実装、Tokenizer に差し込み（環境変数で切り替え）
3) `operators.add` の型規則を TOML 化し、`ExecutionSemantics` で解決
4) Interpreter/VM/JIT へ共通窓口の薄い統合（実行は従来実装と比較可能に）
5) 構文ルール最小セット（statement/expr）を TOML へ移管し、解析の差分をログ化
6) スナップショット/ファズの整備と収束確認
## リスクと対策
- 競合/拡張: プラグイン由来の拡張を名前空間＋優先度でマージ、競合は検知してビルド失敗で気付かせる
- 実行コスト: 生成コード方式でランタイム I/O を避け、起動時間・ホットパスへの影響をゼロに近づける
- 文脈依存: `contextual` のキー粒度を設計（node_kind/context など）し、曖昧解釈を防ぐ
## 成功基準（Exit Criteria）
- 予約語解決の統一（Tokenizer での差分 0）
- 加算に関する VM/JIT/Interpreter のセマンティクス一致（型差分含む）
- 構文最小セットで新旧の AST→MIR が一致（代表ケース）

108
docs/private/roadmap/phases/phase-11.9/README.md Normal file
View File

@ -0,0 +1,108 @@
# Phase 11.9: 文法統一化とAI連携強化
## 📋 概要
Nyashの文法知識が分散している問題を解決し、AIがNyashコードを正しく書けるよう支援する包括的な文法統一化フェーズ。
## 🔥 核心的な問題
現在のNyashは各層（Tokenizer/Parser/Interpreter/MIR/VM/JIT）で予約語・文法解釈がバラバラに実装されており、これが以下の問題を引き起こしている：
- 同じ `me` キーワードが各層で独自解釈される
- `+` 演算子の動作がInterpreter/VM/JITで微妙に異なる
- 新しい予約語追加時に6箇所以上の修正が必要
- AIが正しいコードを書けない（どの層の解釈に従うべきか不明）
## 🎯 フェーズの目的
1. **完全統一文法エンジン**: すべての層が単一の文法定義を参照
2. **セマンティクス一元化**: 演算子・型変換・実行規則の完全統一
3. **AIエラー削減**: 文法間違いを90%以上削減
4. **保守性革命**: 新機能追加が1箇所の修正で完了
## 📊 主要成果物
### 文法定義
- [ ] nyash-grammar-v1.yaml（統一文法定義）
- [ ] Grammar Runtime実装
- [ ] 文法検証ツール
### コンポーネント統合
- [ ] Tokenizer文法統合
- [ ] Parser文法統合
- [ ] Interpreter統合
- [ ] MIR Builder連携
### AI支援機能
- [ ] AI向け文法エクスポート
- [ ] AIコード検証器
- [ ] トレーニングデータ生成
- [ ] 文法aware ANCP
## 🔧 技術的アプローチ
### アーキテクチャ
```
Grammar Definition (YAML)
↓
Grammar Runtime (Rust)
↓
Components (Tokenizer/Parser/Interpreter)
```
### 核心的な改善
```yaml
# 文法定義の例
keywords:
me:
token: ME
deprecated_aliases: ["this", "self"]
ai_hint: "Always use 'me', never 'this'"
```
## 📅 実施時期
- **開始条件**: Phase 11.8完了後
- **推定期間**: 4-5週間
- **優先度**: 高（AIとの協働開発に必須）
## 💡 期待される成果
1. **単一の真実の源**: 文法がYAMLファイル1つに集約
2. **AIフレンドリー**: 明確な文法でAIの学習効率向上
3. **保守性向上**: 新機能追加が簡単に
4. **品質向上**: 統一的な検証で一貫性確保
## 🔗 関連ドキュメント
### 📌 まず読むべき資料
- **[統一セマンティクス実装設計](unified-semantics-implementation.txt)** ← **🎯 最新の実装方針**
- **[統一文法設計総合まとめ](UNIFIED-GRAMMAR-DESIGN-SUMMARY.md)** ← 設計思想の理解
### 🔥 核心設計ドキュメント
- [統一文法アーキテクチャ設計書](unified-grammar-architecture.md) - 基本設計
- [統一予約語システム仕様](unified-keyword-system.md) - 具体的実装
- [AI深層考察: 統一文法アーキテクチャ](ai-deep-thoughts-unified-grammar.md) - Gemini/Codex分析
### 📚 発展的設計（参考）
- [発展的設計集](advanced-designs/) - より深い設計思想
- box-first-grammar-architecture.md - 箱化アプローチ
- root-cutting-architecture.md - 疎結合設計
- zero-knowledge-architecture.md - 究極の分離
### 🔧 実装資料
- [アーカイブ](archive/) - 過去の詳細設計ドキュメント
- grammar-unification.txt - 初期の文法統一化詳細設計
- nyash-grammar-v1.yaml - 統一文法定義YAML（初版）
- implementation-plan.txt - 実装計画
### 🔗 関連フェーズ
- [AI-Nyash Compact Notation Protocol](../../ideas/new-features/2025-08-29-ai-compact-notation-protocol.md)
- [Phase 12: プラグインシステム](../phase-12/)
## 🌟 なぜ重要か？
> 「文法の揺らぎをゼロにし、AIが正しいNyashコードを書ける世界へ」
現在、AIがNyashコードを書く際の最大の障害は文法の不統一。
これを解決することで、開発効率が劇的に向上する。

107
docs/private/roadmap/phases/phase-11.9/UNIFIED-GRAMMAR-DESIGN-SUMMARY.md Normal file
View File

@ -0,0 +1,107 @@
# Phase 11.9 統一文法設計 - 総合まとめ
## 📋 概要
Nyashの各実行層（Tokenizer/Parser/Interpreter/MIR/VM/JIT）で予約語・文法解釈がバラバラに実装されている問題を解決する統一文法アーキテクチャ設計のまとめです。
## 🎯 核心的な問題
```rust
// 現在: 同じ "me" が6箇所で別々に定義
Tokenizer: "me" → TokenType::ME
Parser: 独自のme処理ロジック
Interpreter: 独自のself参照実装
MIR Builder: LoadLocal(0)への変換
VM: OP_LOAD_MEの実行
JIT: LoadFirstParamの生成
```
## 💡 提案された解決策
### 1. 基本アプローチ: 統一文法エンジン
- 単一の文法定義（YAML/TOML）
- 各層が参照する統一API
- UnifiedSemantics による一貫した実行
### 2. AI提案: ビルド時コード生成
- **Gemini**: 宣言的定義 + build.rs によるコード生成
- **Codex**: MIR中心の統一セマンティクス基盤
- 実行時オーバーヘッドゼロ
### 3. 箱化による疎結合設計
- 各層を独立した「箱」として実装
- 変換箱（TransformerBox）パターン
- パイプライン方式での連結
## 📊 実装アプローチの比較
| アプローチ | 利点 | 欠点 | 推奨度 |
|---------|------|------|-------|
| 統一エンジン | シンプル、理解しやすい | 実行時オーバーヘッド | ★★★ |
| コード生成 | 高性能、型安全 | ビルド複雑化 | ★★★★★ |
| 完全箱化 | 究極の疎結合 | 実装複雑度高 | ★★★★ |
## 🚀 推奨実装計画
### Phase 1: 文法定義ファイル作成
```yaml
# grammar/nyash.yml
tokens:
me: { id: 1, category: self_reference }
from: { id: 2, category: delegation }
loop: { id: 3, category: control_flow }
operators:
"+": { precedence: 10, associativity: left }
```
### Phase 2: コード生成基盤
```rust
// build.rs
fn generate_from_grammar() {
// grammar.yml → generated/*.rs
}
```
### Phase 3: 段階的移行
1. Tokenizer を生成コードに移行
2. Parser を統一文法に移行
3. Semantics を一元化
4. MIR/VM/JIT を統合
## 🎯 期待される効果
1. **保守性向上**: 新機能追加が1箇所で完了
2. **一貫性確保**: 全層で同じセマンティクス
3. **AI対応改善**: LLMが正確なコードを生成
4. **性能維持**: ビルド時最適化でオーバーヘッドなし
## 📁 作成されたドキュメント
### 必須ドキュメント（実装に必要）
1. **[統一文法アーキテクチャ設計書](unified-grammar-architecture.md)** - 基本設計
2. **[統一予約語システム仕様](unified-keyword-system.md)** - 具体的実装仕様
3. **[AI深層考察](ai-deep-thoughts-unified-grammar.md)** - Gemini/Codex分析
### 発展的ドキュメント（参考資料）
4. **[Box-First文法アーキテクチャ](box-first-grammar-architecture.md)** - 箱化アプローチ
5. **[根切り文法アーキテクチャ](root-cutting-architecture.md)** - 完全疎結合設計
6. **[ゼロ知識文法アーキテクチャ](zero-knowledge-architecture.md)** - 究極の分離設計
### 既存ドキュメント
- [文法統一化詳細設計](grammar-unification.txt)
- [統一文法定義YAML](nyash-grammar-v1.yaml)
- [実装計画](implementation-plan.txt)
## 🔧 次のステップ
1. `grammar/nyash.yml` の初版作成
2. `crates/nygrammar-gen` の実装開始
3. Tokenizer の移行から着手
4. 段階的に全層を統一
## 📝 結論
コード生成アプローチ（Gemini/Codex推奨）を採用し、`grammar/nyash.yml` を単一の真実の源として、build.rs で各層向けのコードを生成する方式が最も実用的です。
これにより、Nyashの文法が完全に統一され、保守性・一貫性・AI対応すべてが改善されます。

339
docs/private/roadmap/phases/phase-11.9/advanced-designs/box-first-grammar-architecture.md Normal file
View File

@ -0,0 +1,339 @@
# Box-First統一文法アーキテクチャ再設計
## 🚨 現在の設計の問題点
### 1. 密結合の罠
```rust
// ❌ 現在の設計: 各層がUnifiedGrammarEngineに直接依存
impl Tokenizer {
fn tokenize(&mut self) {
self.engine.is_keyword() // 直接参照！
}
}
```
### 2. 根が這う実装
```rust
// ❌ UnifiedKeyword構造体が全層の情報を持つ
struct UnifiedKeyword {
token_type: TokenType, // Tokenizer層
semantic_action: Action, // Parser層
mir_instruction: MirOp, // MIR層
vm_opcode: VmOp, // VM層
jit_pattern: JitPattern, // JIT層
// すべてが絡み合っている！
}
```
### 3. 巨大な神オブジェクト
```rust
// ❌ UnifiedGrammarEngineが全てを知っている
struct UnifiedGrammarEngine {
keywords: KeywordRegistry,
syntax: SyntaxRules,
semantics: SemanticRules,
execution: ExecutionSemantics,
// 責任が多すぎる！
}
```
## 🎯 Box-First再設計
### 核心思想: 「箱に入れて、箱同士をつなぐ」
```
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ GrammarBox │ │ TokenBox │ │ ParserBox │
│ (定義のみ) │ --> │ (Token化) │ --> │ (構文解析) │
└─────────────┘ └─────────────┘ └─────────────┘
| |
v v
┌─────────────┐ ┌─────────────┐
│ SemanticBox │ <---------------------- │ ASTBox │
│ (意味解釈) │ │ (構文木) │
└─────────────┘ └─────────────┘
|
v
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ MIRBox │ --> │ VMBox │ │ JITBox │
│ (中間表現) │ │ (実行) │ │ (コンパイル) │
└─────────────┘ └─────────────┘ └─────────────┘
```
## 📦 各箱の責任と境界
### 1. GrammarBox - 純粋な定義の箱
```rust
// 定義だけを持つ、実装を持たない
box GrammarBox {
init { definitions }
// キーワード定義を返すだけ
getKeywordDef(word) {
return me.definitions.keywords.get(word)
}
// 演算子定義を返すだけ
getOperatorDef(symbol) {
return me.definitions.operators.get(symbol)
}
}
// キーワード定義は純粋なデータ
box KeywordDef {
init { literal, category, aliases }
// 実装なし、データのみ
}
```
### 2. TokenBox - トークン化だけの責任
```rust
box TokenBox {
init { grammarBox } // 定義への参照のみ
tokenize(text) {
local tokens = []
// GrammarBoxに聞くだけ、自分では判断しない
loop(text.hasMore()) {
local word = text.readWord()
local def = me.grammarBox.getKeywordDef(word)
if def {
tokens.push(new Token(def.category, word))
} else {
tokens.push(new Token("IDENTIFIER", word))
}
}
return tokens
}
}
```
### 3. SemanticBox - 意味解釈の箱
```rust
box SemanticBox {
init { } // 他の箱に依存しない！
// 純粋関数として実装
add(left, right) {
// String + String
if left.isString() and right.isString() {
return new StringBox(left.value + right.value)
}
// Number + Number
if left.isNumber() and right.isNumber() {
return new IntegerBox(left.value + right.value)
}
// エラー
return new ErrorBox("Type mismatch")
}
coerceToString(value) {
// 各型の変換ロジック
if value.isString() { return value }
if value.isNumber() { return new StringBox(value.toString()) }
// ...
}
}
```
### 4. MIRBuilderBox - AST→MIR変換の箱
```rust
box MIRBuilderBox {
init { semanticBox } // セマンティクスへの参照のみ
buildFromAST(ast) {
// ASTの種類に応じてMIRを生成
if ast.type == "BinaryOp" {
return me.buildBinaryOp(ast)
}
// ...
}
buildBinaryOp(ast) {
local left = me.buildFromAST(ast.left)
local right = me.buildFromAST(ast.right)
// セマンティクスに聞いて、適切なMIR命令を選択
if ast.op == "+" {
// SemanticBoxに型情報を聞く
local mirOp = me.selectAddInstruction(left.type, right.type)
return new MIRNode(mirOp, left, right)
}
}
}
```
## 🔄 疎結合の実現方法
### 1. インターフェース（契約）による結合
```rust
// 各箱は最小限のインターフェースだけを公開
trait TokenProvider {
fn next_token(&mut self) -> Option<Token>;
}
trait SemanticProvider {
fn apply_operator(&self, op: &str, args: &[Value]) -> Result<Value>;
}
trait MIRProvider {
fn get_instruction(&self, index: usize) -> &MIRInstruction;
}
```
### 2. メッセージパッシング
```rust
// 箱同士は直接呼び出さず、メッセージで通信
box ParserBox {
parseExpression() {
// TokenBoxにメッセージを送る
local token = me.sendMessage(me.tokenBox, "nextToken")
// 結果を処理
if token.type == "NUMBER" {
return new NumberNode(token.value)
}
}
}
```
### 3. イベント駆動
```rust
// 文法変更時の通知システム
box GrammarBox {
updateKeyword(word, newDef) {
me.definitions.keywords.set(word, newDef)
// 変更を通知（購読者に伝える）
me.notify("keyword_changed", word)
}
}
box TokenBox {
init { grammarBox }
constructor() {
// 文法変更を購読
me.grammarBox.subscribe("keyword_changed", me.onKeywordChanged)
}
onKeywordChanged(word) {
// キャッシュをクリア
me.clearCache()
}
}
```
## 📐 ビルド時生成の箱化
### GeneratorBox - コード生成も箱
```rust
box GeneratorBox {
init { grammarBox, outputPath }
generate() {
local grammar = me.grammarBox.getDefinitions()
// 各層向けのコードを生成
me.generateTokens(grammar.keywords)
me.generateParseTables(grammar.syntax)
me.generateSemanticTables(grammar.operators)
}
generateTokens(keywords) {
local code = "pub enum Token {\n"
keywords.forEach((name, def) => {
code += " " + name + ",\n"
})
code += "}\n"
me.writeFile("generated/tokens.rs", code)
}
}
```
## 🎯 密結合を避ける設計原則
### 1. 単一責任の原則
- GrammarBox: 定義の管理のみ
- TokenBox: トークン化のみ
- ParserBox: 構文解析のみ
- SemanticBox: 意味解釈のみ
### 2. 依存関係の逆転
```rust
// ❌ 悪い例: 具象に依存
box VMBox {
init { mirBuilder: MIRBuilderBox } // 具象型に依存
}
// ✅ 良い例: 抽象に依存
box VMBox {
init { mirProvider: MIRProvider } // インターフェースに依存
}
```
### 3. Open/Closed原則
```rust
// 新しい演算子の追加が既存コードを変更しない
box OperatorRegistry {
init { operators }
register(symbol, handler) {
me.operators.set(symbol, handler)
}
apply(symbol, args) {
local handler = me.operators.get(symbol)
if handler {
return handler.apply(args)
}
return new ErrorBox("Unknown operator")
}
}
```
## 🔧 段階的移行（箱単位）
### Phase 1: GrammarBox導入
- grammar.yamlをGrammarBoxでラップ
- 既存コードはGrammarBox経由でアクセス
### Phase 2: TokenBox分離
- Tokenizerの機能をTokenBoxに移動
- GrammarBoxへの依存を最小化
### Phase 3: SemanticBox独立
- 演算子実装をSemanticBoxに集約
- 純粋関数として実装
### Phase 4: 箱間通信の確立
- メッセージパッシング導入
- イベントシステム構築
## 📊 疎結合度の測定
### 1. 依存関係グラフ
```
GrammarBox (依存なし)
↓
TokenBox → GrammarBox (1依存)
ParserBox → TokenBox (1依存)
SemanticBox (依存なし)
MIRBox → SemanticBox (1依存)
VMBox → MIRBox (1依存)
JITBox → MIRBox (1依存)
```
### 2. 変更影響範囲
- 新キーワード追加: GrammarBoxのみ
- 新演算子追加: GrammarBox + SemanticBoxのみ
- 新バックエンド追加: 既存箱への変更なし
## 🚀 期待される効果
1. **真の疎結合**: 各箱が独立して開発・テスト可能
2. **容易な拡張**: 新しい箱の追加が既存を壊さない
3. **明確な境界**: 責任の所在が明確
4. **並行開発**: チームが独立して各箱を開発可能
これで「Everything is Box」哲学に忠実な、真に疎結合な統一文法アーキテクチャが実現されます。

297
docs/private/roadmap/phases/phase-11.9/advanced-designs/root-cutting-architecture.md Normal file
View File

@ -0,0 +1,297 @@
# 根切り文法アーキテクチャ - 真の疎結合設計
## 🌳 「根が這う」問題の本質
### 現在の設計の根本的な問題
```rust
// 🌳 根が這っている例: 一つの変更が全体に波及
struct Keyword {
name: String,
token_type: TokenType, // Tokenizer層の型
parser_rule: ParserRule, // Parser層の型
mir_op: MIROpcode, // MIR層の型
vm_handler: VMHandler, // VM層の型
// → 一つのstructが全層の型を知っている！
}
```
## 🎯 根切り設計: レイヤー完全分離
### 核心思想: 「各層は自分の関心事だけを知る」
```
【Tokenizer層】 【Parser層】 【Semantic層】
"me" → Token::Me → SelfReference
知識:文字列のみ 知識:トークンのみ 知識:意味のみ
【MIR層】 【VM層】 【JIT層】
LoadLocal(0) → OP_LOAD_0 → mov rax, [rbp]
知識:MIRのみ 知識:オペコードのみ 知識:機械語のみ
```
## 📦 真の箱化: 変換箱（TransformerBox）パターン
### 1. 各層は純粋な箱
```rust
// Tokenizer層: 文字列→トークンの変換のみ
box StringToTokenBox {
init { } // 依存なし！
transform(text: String) -> TokenStream {
// 純粋な文字列処理
local tokens = []
local chars = text.chars()
loop(chars.hasNext()) {
local ch = chars.next()
if ch.isLetter() {
local word = me.readWord(chars, ch)
tokens.push(me.classifyWord(word))
}
// ...
}
return TokenStream(tokens)
}
classifyWord(word: String) -> Token {
// ローカルな判定のみ
match word {
"me" => Token::Me,
"from" => Token::From,
"loop" => Token::Loop,
_ => Token::Identifier(word)
}
}
}
```
### 2. 層間の変換も箱
```rust
// Token→AST変換箱
box TokenToASTBox {
init { } // 依存なし！
transform(tokens: TokenStream) -> AST {
local parser = PrattParser()
return parser.parse(tokens)
}
}
// AST→MIR変換箱
box ASTToMIRBox {
init { } // 依存なし！
transform(ast: AST) -> MIR {
match ast {
AST::BinaryOp(op, left, right) => {
local leftMIR = me.transform(left)
local rightMIR = me.transform(right)
return me.selectMIROp(op, leftMIR, rightMIR)
}
// ...
}
}
selectMIROp(op: String, left: MIR, right: MIR) -> MIR {
// ローカルな判断のみ
if op == "+" {
if left.type == "String" and right.type == "String" {
return MIR::StringConcat(left, right)
}
if left.type == "Integer" and right.type == "Integer" {
return MIR::AddI64(left, right)
}
}
// ...
}
}
```
## 🔄 パイプライン: 箱の連鎖
### 純粋関数的パイプライン
```rust
// 各箱は前の箱の出力を入力として受け取るだけ
box NyashPipeline {
init { }
compile(source: String) -> ExecutableCode {
// 各変換箱を順番に適用
local tokens = StringToTokenBox().transform(source)
local ast = TokenToASTBox().transform(tokens)
local mir = ASTToMIRBox().transform(ast)
local bytecode = MIRToVMBox().transform(mir)
return bytecode
}
}
```
## 📐 設定の分離: ConfigBox
### 文法定義も実行時から分離
```rust
// ビルド時のみ使用される設定箱
box GrammarConfigBox {
init { yamlPath }
load() -> GrammarConfig {
// YAMLを読み込んで設定オブジェクトを返す
return YAML.parse(File.read(me.yamlPath))
}
}
// ビルド時コード生成箱
box CodeGeneratorBox {
init { config }
generate() {
// 設定から各層のコードを生成
me.generateTokenizerTable(me.config.keywords)
me.generateParserTable(me.config.syntax)
me.generateMIRTable(me.config.semantics)
}
generateTokenizerTable(keywords) {
// キーワードマッチング用の完全ハッシュ関数生成
local code = "fn classify_keyword(s: &str) -> Token {\n"
code += " match s {\n"
keywords.forEach((word, info) => {
code += ' "' + word + '" => Token::' + info.token + ',\n'
})
code += " _ => Token::Identifier(s.to_string())\n"
code += " }\n"
code += "}\n"
File.write("src/generated/keywords.rs", code)
}
}
```
## 🎯 セマンティクスの分離
### セマンティクスも変換箱として実装
```rust
// 型強制変換箱
box TypeCoercionBox {
init { } // 依存なし！
coerceToString(value: Value) -> StringValue {
match value {
Value::String(s) => StringValue(s),
Value::Integer(i) => StringValue(i.toString()),
Value::Float(f) => StringValue(f.toString()),
Value::Bool(b) => StringValue(b ? "true" : "false"),
_ => panic("Cannot coerce to string")
}
}
}
// 演算子実行箱
box OperatorExecutorBox {
init { coercionBox }
executeAdd(left: Value, right: Value) -> Value {
// ローカルな判断
match (left, right) {
(Value::String(s1), Value::String(s2)) => {
Value::String(s1 + s2)
}
(Value::String(s), other) => {
local s2 = me.coercionBox.coerceToString(other)
Value::String(s + s2.value)
}
(Value::Integer(i1), Value::Integer(i2)) => {
Value::Integer(i1 + i2)
}
// ...
}
}
}
```
## 🔧 テスト可能性の向上
### 各箱が独立してテスト可能
```rust
// StringToTokenBoxのテスト
test "tokenize keywords" {
local box = StringToTokenBox()
local tokens = box.transform("me loop from")
assert tokens == [Token::Me, Token::Loop, Token::From]
}
// ASTToMIRBoxのテスト
test "binary op to MIR" {
local box = ASTToMIRBox()
local ast = AST::BinaryOp("+",
AST::Literal(Value::Integer(1)),
AST::Literal(Value::Integer(2))
)
local mir = box.transform(ast)
assert mir == MIR::AddI64(
MIR::Const(Value::Integer(1)),
MIR::Const(Value::Integer(2))
)
}
```
## 📊 依存グラフ: 完全なDAG（有向非巡環グラフ）
```
StringToTokenBox (依存: 0)
↓
TokenToASTBox (依存: 0)
↓
ASTToMIRBox (依存: 0)
↓ ↓
MIRToVMBox (依存: 0) MIRToJITBox (依存: 0)
TypeCoercionBox (依存: 0)
↓
OperatorExecutorBox (依存: 1)
```
## 🚀 この設計の利点
### 1. 真の疎結合
- 各箱は入力と出力の型だけを知る
- 他の箱の実装を一切知らない
- インターフェースすら不要（型だけで十分）
### 2. 並行開発可能
- チームAがTokenizer開発
- チームBがParser開発
- チームCがMIR開発
- 全員が独立して作業可能
### 3. 差し替え可能
```rust
// 別実装への差し替えが容易
local pipeline = NyashPipeline()
pipeline.tokenizer = OptimizedStringToTokenBox() // 高速版
pipeline.parser = ErrorRecoveringTokenToASTBox() // エラー回復版
```
### 4. 段階的最適化
```rust
// 最適化も箱として追加
box MIROptimizerBox {
transform(mir: MIR) -> MIR {
// 定数畳み込み、死んだコード除去など
return optimized
}
}
// パイプラインに挿入
local mir = ASTToMIRBox().transform(ast)
mir = MIROptimizerBox().transform(mir) // 追加
local bytecode = MIRToVMBox().transform(mir)
```
## 🎯 まとめ: 根を完全に切る
1. **データ中心設計**: 各層は入力データを出力データに変換するだけ
2. **状態を持たない**: すべての箱が純粋関数的
3. **設定と実装の分離**: ビルド時と実行時を明確に分離
4. **変換の連鎖**: パイプラインで箱をつなぐ
これにより、真に「根が這わない」アーキテクチャが実現されます。

304
docs/private/roadmap/phases/phase-11.9/advanced-designs/zero-knowledge-architecture.md Normal file
View File

@ -0,0 +1,304 @@
# ゼロ知識文法アーキテクチャ - 究極の疎結合
## 🔍 さらに深い問題: 暗黙知識の漏洩
### 現在の設計でもまだ残る問題
```rust
// 🚨 TokenToASTBoxがTokenの意味を知っている
transform(tokens: TokenStream) -> AST {
if token == Token::Me { // Tokenの意味を知っている！
return AST::SelfReference
}
}
// 🚨 ASTToMIRBoxがASTの構造を知っている
transform(ast: AST) -> MIR {
match ast {
AST::BinaryOp(op, left, right) => { // AST構造を知っている！
// ...
}
}
}
```
## 🎯 ゼロ知識原則: 「箱は変換ルールだけを知る」
### 純粋な変換テーブル駆動設計
```rust
// 各箱は変換テーブルだけを持つ
box TokenClassifierBox {
init { table: Map<String, u32> } // 文字列→数値のマッピングのみ
classify(word: String) -> u32 {
return me.table.get(word).unwrapOr(0) // 0 = unknown
}
}
// ビルド時に生成される純粋なマッピング
const TOKEN_TABLE: Map<String, u32> = {
"me" => 1,
"from" => 2,
"loop" => 3,
// ...
}
```
## 📊 統一中間表現（UIR: Unified Intermediate Representation）
### すべての層が数値タグで通信
```
Source Code UIR Tags Execution
----------- -------- ---------
"me" → [1] → LoadLocal(0)
"+" → [100] → Add
"loop" → [200] → Branch
1 + 2 → [300,1,300,2,100] → Const(1), Const(2), Add
```
### UIRTag: 意味を持たない純粋な識別子
```rust
box UIRTag {
init { id: u32, children: Array<UIRTag> }
// タグは意味を持たない、ただの番号
isLeaf() { return me.children.isEmpty() }
getChildren() { return me.children }
}
```
## 🔄 完全分離された変換パイプライン
### 1. 字句解析: 文字列→UIRタグ
```rust
box LexicalTransformerBox {
init { charTable: Array<u32> } // 文字→タグのテーブル
transform(text: String) -> Array<UIRTag> {
local tags = []
local chars = text.chars()
loop(chars.hasNext()) {
local ch = chars.next()
local tag = me.charTable[ch.code()]
if tag == TAG_LETTER {
local word = me.collectWhile(chars, TAG_LETTER)
tags.push(me.lookupWord(word))
} else if tag == TAG_DIGIT {
local num = me.collectWhile(chars, TAG_DIGIT)
tags.push(UIRTag(TAG_NUMBER, num))
}
// ...
}
return tags
}
// 単語検索も純粋なハッシュ値
lookupWord(word: String) -> UIRTag {
local hash = me.perfectHash(word)
return UIRTag(hash, [])
}
}
```
### 2. 構文解析: UIRタグ→UIRツリー
```rust
box SyntaxTransformerBox {
init {
// 優先順位テーブル（タグ→優先度）
precedence: Map<u32, u32>,
// 結合性テーブル（タグ→左/右）
associativity: Map<u32, u8>
}
transform(tags: Array<UIRTag>) -> UIRTag {
// Prattパーサーだが、意味を知らない
return me.parseExpression(tags, 0)
}
parseExpression(tags: Array<UIRTag>, minPrec: u32) -> UIRTag {
local left = me.parsePrimary(tags)
loop(tags.hasNext()) {
local op = tags.peek()
local prec = me.precedence.get(op.id).unwrapOr(0)
if prec < minPrec { break }
tags.next() // consume operator
local assoc = me.associativity.get(op.id).unwrapOr(LEFT)
local nextPrec = if assoc == LEFT { prec + 1 } else { prec }
local right = me.parseExpression(tags, nextPrec)
// 構造だけ作る、意味は知らない
left = UIRTag(op.id, [left, right])
}
return left
}
}
```
### 3. 意味解析: UIRツリー→実行可能形式
```rust
box SemanticTransformerBox {
init {
// タグ→実行アクションのテーブル
actions: Map<u32, ExecutionAction>
}
transform(tree: UIRTag) -> ExecutableCode {
local action = me.actions.get(tree.id)
if action {
return action.generate(tree.children.map(child => {
me.transform(child)
}))
}
return ExecutableCode.Noop()
}
}
```
## 📐 ビルド時の統一: マスターテーブル生成
### grammar.yaml → 各種テーブル生成
```yaml
# grammar.yaml - 真の単一情報源
tokens:
me: { id: 1, type: self_reference }
from: { id: 2, type: delegation }
loop: { id: 3, type: control_flow }
operators:
"+": { id: 100, precedence: 10, associativity: left }
"*": { id: 101, precedence: 20, associativity: left }
semantics:
1: { action: load_self }
2: { action: delegate_call }
3: { action: loop_construct }
100: { action: add_operation }
```
### ビルド時生成
```rust
// build.rs
fn generate_tables(grammar: GrammarDef) {
// 1. 完全ハッシュ関数生成
generate_perfect_hash(grammar.tokens)
// 2. 優先順位テーブル生成
generate_precedence_table(grammar.operators)
// 3. セマンティクステーブル生成
generate_semantic_table(grammar.semantics)
// 4. 各層の定数生成
generate_constants(grammar)
}
```
## 🎯 究極の利点: 完全な知識分離
### 1. 各箱が知っていること
- **LexicalTransformer**: 文字の分類とハッシュ計算のみ
- **SyntaxTransformer**: 優先順位と結合性のみ
- **SemanticTransformer**: タグとアクションの対応のみ
### 2. 各箱が知らないこと
- **すべての箱**: 他の層の存在、Nyashという言語名すら知らない
- **すべての箱**: キーワードの意味、演算子の意味
- **すべての箱**: 最終的な実行形式
### 3. テストの単純化
```rust
test "lexical transformer" {
local table = { "hello" => 42 }
local box = LexicalTransformerBox(table)
assert box.transform("hello") == [UIRTag(42)]
}
test "syntax transformer" {
local prec = { 100 => 10, 101 => 20 }
local box = SyntaxTransformerBox(prec, {})
// 1 + 2 * 3
local tags = [UIRTag(1), UIRTag(100), UIRTag(2), UIRTag(101), UIRTag(3)]
local tree = box.transform(tags)
// 期待: (+ 1 (* 2 3))
assert tree == UIRTag(100, [
UIRTag(1),
UIRTag(101, [UIRTag(2), UIRTag(3)])
])
}
```
## 🔧 動的拡張: プラグインテーブル
### 実行時のテーブル拡張
```rust
box PluginLoaderBox {
init { transformers: Map<String, TransformerBox> }
loadPlugin(path: String) {
local plugin = Plugin.load(path)
// プラグインは新しいタグを登録
local newTags = plugin.getTags()
// 各変換器のテーブルを拡張
me.transformers.get("lexical").extendTable(newTags.lexical)
me.transformers.get("syntax").extendTable(newTags.syntax)
me.transformers.get("semantic").extendTable(newTags.semantic)
}
}
```
## 📊 性能特性
### 1. キャッシュ効率
- 各テーブルは連続メモリに配置
- CPUキャッシュに収まるサイズ
- ランダムアクセスなし
### 2. 並列化可能
- 各変換は状態を持たない
- 入力を分割して並列処理可能
- ロックフリー実装
### 3. 最適化の余地
- テーブルのコンパクト化
- SIMDによる並列検索
- JITによるテーブル特化
## 🚀 最終形: 言語に依存しない変換エンジン
```rust
// このエンジンはNyashを知らない！
box UniversalTransformEngine {
init {
pipeline: Array<TransformerBox>,
tables: Map<String, Table>
}
execute(input: String) -> Output {
local data = input
// 各変換を順番に適用
me.pipeline.forEach(transformer => {
data = transformer.transform(data)
})
return data
}
}
// Nyash = 特定のテーブルセット
const NYASH_TABLES = load_tables("nyash-grammar.yaml")
local engine = UniversalTransformEngine(STANDARD_PIPELINE, NYASH_TABLES)
```
これが究極の「根を切った」設計です。各箱は純粋な変換器であり、Nyashという言語の存在すら知りません。

146
docs/private/roadmap/phases/phase-11.9/ai-deep-thoughts-unified-grammar.md Normal file
View File

@ -0,0 +1,146 @@
# AI深層考察: Nyash統一文法アーキテクチャ
## 🎯 概要
GeminiとCodexに時間無制限で深く考えてもらった、Nyash統一文法アーキテクチャに関する洞察をまとめました。
## 🔥 Gemini先生の洞察
### 核心的提言: 宣言的文法定義 + ビルド時コード生成
```
[ grammar.toml ] ← 宣言的SSoT（Single Source of Truth）
↓
[ build.rs ] ← メタプログラミング層
↓
├─ generated_tokens.rs
├─ generated_keywords.rs
├─ generated_rules.rs
└─ generated_opcodes.rs
```
### 重要ポイント
1. **真の分離**: `UnifiedKeyword`構造体は依然として各層を密結合させる。宣言的ファイルからコード生成する方が疎結合を保てる。
2. **ゼロコスト抽象化**:
- ビルド時生成により実行時オーバーヘッドなし
- `enum`と`match`文で高速ディスパッチ
- `#[inline(always)]`で関数呼び出しコストなし
3. **コンパイラ駆動開発**:
```rust
// 新機能追加時、全層でコンパイルエラー発生
// → 実装漏れがなくなる
match token {
TokenType::Async => // 新しく追加されたので実装必須
_ => // ...
}
```
4. **他言語からの学び**:
- **CPython**: `Grammar/Tokens`ファイルから生成
- **V8**: Ignition(インタプリタ)とTurboFan(JIT)の分離
- **rustc**: HIR→MIRという段階的表現
## 💡 Codex先生の洞察
### 核心的提言: MIRを中心とした統一セマンティクス基盤
```yaml
# grammar/nyash.yml
tokens:
- name: ME
literal: "me"
soft: true
contexts: ["expr", "pattern"]
deprecated_aliases: ["self"]
ai_hint: "Current object; not assignable."
operators:
- symbol: "+"
name: add
precedence: 110
associativity: left
overloads:
- types: ["i64","i64"] -> "i64"
lower: MIR.AddI64
- types: ["String","String"] -> "String"
lower: MIR.Concat
```
### 実装戦略
1. **単一仕様ファイル**: `grammar/nyash.yml`に全て定義
- キーワード、演算子、文法、型、強制変換
- MIRローリング、VMオペコード、JITパターン
- 非推奨、AIヒント
2. **コード生成クレート**: `crates/nygrammar-gen`
- Perfect hash関数でO(1)キーワード認識
- Pratt/PEGパーサーテーブル生成
- 型ディスパッチマトリックス生成
3. **MIRが真実の基盤**:
```rust
pub fn add(lhs: Value, rhs: Value) -> Result<MIRNode> {
// 生成されたfast-pathを使用
// 常にMIRノードを返す
}
```
4. **性能最適化**:
- ビルド時にすべて決定（実行時検索なし）
- インラインキャッシュで呼び出しサイト最適化
- ソフトキーワードはパーサー状態で判定
### 段階的移行計画
- **Phase 0**: ベースラインテスト（現状記録）
- **Phase 1**: 正準MIR定義
- **Phase 2**: KeywordRegistry生成
- **Phase 3**: UnifiedSemantics導入
- **Phase 4**: パーサー統一
- **Phase 5**: バックエンドマッピング
- **Phase 6**: 非推奨警告
- **Phase 7**: ツール/ドキュメント生成
## 🎯 統合された知見
両AIの提言を統合すると：
### 1. 宣言的定義 + コード生成が最強
- YAML/TOMLで文法を宣言的に定義
- build.rsでRustコードを生成
- 実行時オーバーヘッドゼロ
### 2. MIRを中心とした統一
- すべてのセマンティクスはMIRで表現
- 各バックエンドはMIRを実行/コンパイル
- 一貫性が自動的に保証される
### 3. AI友好的な設計
- 機械可読な仕様ファイル
- 豊富な例とエラーカタログ
- 自動生成されるドキュメント
### 4. 拡張性への配慮
- 新バックエンド追加が容易
- プラグインによる拡張可能
- 後方互換性の維持
## 📋 実装優先順位
1. **最優先**: `grammar/nyash.yml`の初版作成
2. **高優先**: `build.rs`によるトークン生成
3. **中優先**: MIR統一とUnifiedSemantics
4. **低優先**: JIT最適化ヒント
## 🚀 期待される効果
- **保守性**: 新機能追加が1箇所の修正で完了
- **一貫性**: 全層で同じセマンティクス保証
- **性能**: ビルド時最適化で実行時コストなし
- **AI対応**: LLMが正確にNyashコードを生成
これらの深い洞察により、Nyashの統一文法アーキテクチャは強固な基盤の上に構築されることになります。

255
docs/private/roadmap/phases/phase-11.9/chatgpt5-feedback-integration.md Normal file
View File

@ -0,0 +1,255 @@
# ChatGPT5フィードバック統合 - 統一文法アーキテクチャ改善
## 📋 ChatGPT5からの評価
> 「Grammar as THE Source of Truth で各層の乖離を一元化する狙いは現状の痛点に直結しており、有効です」
## 🎯 指摘されたリスクへの対応策
### 1. ランタイム依存過多への対応
#### 問題
```rust
// ❌ 悪い例：実行時にTOMLパース
let grammar = toml::from_str(&fs::read_to_string("grammar.toml")?)?;
```
#### 解決策：build.rs による完全コード生成
```rust
// build.rs
fn main() {
println!("cargo:rerun-if-changed=grammar/nyash.yml");
let grammar = load_grammar_definition();
// Rust定数として生成
generate_keyword_constants(&grammar);
generate_perfect_hash_function(&grammar);
generate_semantic_tables(&grammar);
generate_mir_mappings(&grammar);
}
// 生成されるコード例
// generated/keywords.rs
pub const KEYWORD_ME: u32 = 1;
pub const KEYWORD_FROM: u32 = 2;
pub const KEYWORD_LOOP: u32 = 3;
#[inline(always)]
pub fn classify_keyword(s: &str) -> Option<u32> {
match s {
"me" => Some(KEYWORD_ME),
"from" => Some(KEYWORD_FROM),
"loop" => Some(KEYWORD_LOOP),
_ => None,
}
}
```
### 2. プラグイン拡張性と競合への対応
#### マージ戦略の定義
```yaml
# grammar/nyash.yml
version: "1.0"
namespace: "core"
# プラグイン拡張ポイント
extension_points:
operators:
merge_strategy: "priority" # 優先順位ベース
conflict_resolution: "namespace" # 名前空間で分離
# プラグイン例
# plugins/custom/grammar.yml
namespace: "custom"
extends: "core"
operators:
"++": # 新しい演算子
priority: 100
precedence: 15
semantics: increment
```
#### 実装時の名前空間解決
```rust
pub struct GrammarRegistry {
core: CoreGrammar,
plugins: HashMap<String, PluginGrammar>,
}
impl GrammarRegistry {
pub fn resolve_operator(&self, op: &str, context: &Context) -> OperatorDef {
// 1. 現在の名前空間で検索
if let Some(def) = context.namespace.find_operator(op) {
return def;
}
// 2. インポートされた名前空間を優先順位順に検索
for imported in &context.imports {
if let Some(def) = self.plugins.get(imported)?.find_operator(op) {
return def;
}
}
// 3. コア名前空間にフォールバック
self.core.find_operator(op).unwrap_or_else(|| {
panic!("Unknown operator: {}", op)
})
}
}
```
### 3. 文脈依存キーワードの曖昧性解決
#### fromキーワードの文脈解決ルール
```yaml
# grammar/nyash.yml
contextual_keywords:
from:
contexts:
- name: "box_delegation"
pattern: "box IDENT from"
priority: 100
- name: "method_delegation"
pattern: "from IDENT.IDENT"
priority: 90
- name: "variable_name"
pattern: "IDENT = from" # 変数名として使用
priority: 10
resolution: "longest_match_first" # 最長一致優先
```
#### パーサーでの実装
```rust
impl Parser {
fn parse_from(&mut self) -> Result<Node> {
let start_pos = self.current_pos();
// 最長一致を試みる
if let Ok(delegation) = self.try_parse_delegation() {
return Ok(delegation);
}
// フォールバック：通常の識別子として扱う
self.reset_to(start_pos);
Ok(Node::Identifier("from".to_string()))
}
}
```
### 4. 二重実装期間の管理
#### 自動差分検出テスト
```rust
#[cfg(test)]
mod migration_tests {
use super::*;
#[test]
fn test_unified_vs_legacy_semantics() {
let test_cases = load_test_cases("tests/semantics/*.nyash");
for case in test_cases {
let legacy_result = legacy_interpreter.execute(&case);
let unified_result = unified_interpreter.execute(&case);
// スナップショットテスト
assert_snapshot!(
format!("{}_unified", case.name),
unified_result
);
// 差分検出
if legacy_result != unified_result {
// 意図的な変更か確認
assert!(
is_expected_difference(&case, &legacy_result, &unified_result),
"Unexpected difference in {}: {:?} vs {:?}",
case.name, legacy_result, unified_result
);
}
}
}
}
```
#### 段階的移行フラグ
```rust
pub struct ExecutionConfig {
pub use_unified_grammar: bool,
pub log_differences: bool,
pub fail_on_difference: bool,
}
impl Interpreter {
pub fn execute_with_migration(&mut self, expr: &Expression) -> Result<Value> {
if self.config.use_unified_grammar {
let result = self.unified_execute(expr)?;
if self.config.log_differences {
let legacy_result = self.legacy_execute(expr)?;
if result != legacy_result {
log::warn!(
"Semantic difference detected: {:?} -> unified: {:?}, legacy: {:?}",
expr, result, legacy_result
);
if self.config.fail_on_difference {
panic!("Unexpected semantic difference");
}
}
}
Ok(result)
} else {
self.legacy_execute(expr)
}
}
}
```
## 📊 改善された実装計画
### Phase 0: 準備（1週間）
- ベースラインテストスイート作成
- 現在のセマンティクスのスナップショット記録
- 差分検出フレームワーク構築
### Phase 1: コード生成基盤（1週間）
- build.rs による完全静的生成
- ゼロランタイムコスト実現
- CI/CDでの生成コード検証
### Phase 2: 名前空間とプラグイン（1週間）
- 名前空間解決システム
- プラグインマージ戦略実装
- 競合検出と報告
### Phase 3: 文脈依存解決（1週間）
- fromキーワードの文脈ルール実装
- 最長一致パーサー
- 曖昧性テストケース
### Phase 4: 段階的移行（2週間）
- フィーチャーフラグ実装
- 並行実行と差分ログ
- 本番環境での検証
## 🎯 期待される成果
1. **ゼロコスト抽象化**: 実行時オーバーヘッドなし
2. **安全な拡張性**: プラグイン競合の自動解決
3. **明確な文脈解決**: 曖昧性のない文法
4. **リスクフリー移行**: 自動検証による安全な移行
## 📝 まとめ
ChatGPT5さんの指摘により、実装の潜在的リスクが明確になりました。
これらの対策を組み込むことで、より堅牢で実用的な統一文法アーキテクチャが実現できます。
「痛点直結」という評価に応えられる実装を目指しますにゃ！🚀

344
docs/private/roadmap/phases/phase-11.9/unified-grammar-architecture.md Normal file
View File

@ -0,0 +1,344 @@
# Phase 11.9: 統一文法アーキテクチャ設計書
## 🔴 現在の根本的問題
現在のNyashは、各層で予約語・文法解釈がバラバラに実装されている：
### 1. Tokenizer層での分散
```rust
// src/tokenizer.rs
match word.as_str() {
"me" => TokenType::ME, // ハードコード
"from" => TokenType::FROM, // ハードコード
"loop" => TokenType::LOOP, // ハードコード
// ... 各予約語が個別定義
}
```
### 2. Parser層での独自解釈
```rust
// src/parser/mod.rs
fn parse_loop(&mut self) {
// loop構文の独自解釈
// while/forとの混同を個別チェック
}
```
### 3. Interpreter層での独自実行
```rust
// src/interpreter/expressions.rs
fn execute_from_call(&mut self) {
// fromの独自解釈
// デリゲーションロジックが埋め込み
}
```
### 4. MIR Builder層での独自変換
```rust
// src/mir/builder.rs
fn build_loop(&mut self) {
// loop → MIRへの独自変換
// セーフポイント挿入も個別判断
}
```
### 5. VM/JIT層での独自実行
- VM: 独自のセマンティクス実装
- JIT: 独自のコード生成戦略
## 🎯 統一文法アーキテクチャの設計
### 核心コンセプト: "Grammar as THE Source of Truth"
```
┌─────────────────────────────────────────────┐
│ Unified Grammar Engine │
│ (単一の文法定義・解釈・実行エンジン) │
├─────────────────────────────────────────────┤
│ - Keyword Registry (予約語レジストリ) │
│ - Syntax Rules (構文規則) │
│ - Semantic Rules (意味規則) │
│ - Execution Semantics (実行セマンティクス) │
└─────────────────────────────────────────────┘
↓
┌──────────┬──────────┬──────────┬──────────┐
│Tokenizer │ Parser │Interpreter│MIR/VM/JIT│
│ (利用) │ (利用) │ (利用) │ (利用) │
└──────────┴──────────┴──────────┴──────────┘
```
## 📐 統一文法エンジンの実装設計
### 1. コア構造体
```rust
// src/grammar/engine.rs
pub struct UnifiedGrammarEngine {
// 予約語の統一定義
keywords: KeywordRegistry,
// 構文規則の統一定義
syntax: SyntaxRuleEngine,
// 意味規則の統一定義
semantics: SemanticRuleEngine,
// 実行セマンティクスの統一定義
execution: ExecutionSemantics,
}
impl UnifiedGrammarEngine {
/// 単一のソースから全情報を読み込み
pub fn load() -> Self {
// YAML/TOML/Rustコードから読み込み
let config = include_str!("../../../grammar/unified-grammar.toml");
Self::from_config(config)
}
/// Tokenizerが使う統一API
pub fn is_keyword(&self, word: &str) -> Option<TokenType> {
self.keywords.lookup(word)
}
/// Parserが使う統一API
pub fn parse_rule(&self, rule_name: &str) -> &SyntaxRule {
self.syntax.get_rule(rule_name)
}
/// Interpreter/VM/JITが使う統一API
pub fn execute_semantic(&self, op: &str, args: &[Value]) -> Value {
self.execution.apply(op, args)
}
}
```
### 2. 予約語レジストリ
```rust
pub struct KeywordRegistry {
// 正規形マップ
canonical: HashMap<String, KeywordDef>,
// エイリアスマップ（非推奨含む）
aliases: HashMap<String, String>,
// コンテキスト別解釈
contextual: HashMap<(String, Context), KeywordDef>,
}
pub struct KeywordDef {
pub token: TokenType,
pub category: KeywordCategory,
pub semantic_action: SemanticAction,
pub mir_opcode: Option<MirOpcode>,
pub vm_handler: Option<VmHandler>,
pub jit_lowering: Option<JitLowering>,
}
```
### 3. 構文規則エンジン
```rust
pub struct SyntaxRuleEngine {
rules: HashMap<String, SyntaxRule>,
}
pub struct SyntaxRule {
pub pattern: Pattern,
pub precedence: i32,
pub associativity: Associativity,
pub semantic_transform: Box<dyn Fn(&AST) -> MIR>,
}
```
### 4. 実行セマンティクス統一
```rust
pub struct ExecutionSemantics {
// 演算子の統一実装
operators: HashMap<String, OperatorSemantics>,
// 型変換の統一ルール
coercions: CoercionRules,
// エラー処理の統一
error_handling: ErrorSemantics,
}
impl ExecutionSemantics {
/// すべてのバックエンドが使う統一演算
pub fn add(&self, left: Value, right: Value) -> Value {
// Interpreter/VM/JIT すべて同じロジック
match (&left, &right) {
(Value::String(s1), Value::String(s2)) => {
Value::String(s1.clone() + s2)
}
(Value::Integer(i1), Value::Integer(i2)) => {
Value::Integer(i1 + i2)
}
_ => self.coerce_and_add(left, right)
}
}
}
```
## 🔄 統一化の実装手順
### Phase 1: 基盤構築
1. `src/grammar/engine.rs` - 統一エンジン本体
2. `grammar/unified-grammar.toml` - 統一定義ファイル
3. 既存コードとの並行実行（デバッグ用）
### Phase 2: Tokenizer統合
```rust
impl NyashTokenizer {
fn new() -> Self {
Self {
engine: UnifiedGrammarEngine::load(),
// ...
}
}
fn read_keyword_or_identifier(&mut self) -> TokenType {
let word = self.read_word();
// 統一エンジンに委譲
self.engine.is_keyword(&word)
.unwrap_or(TokenType::IDENTIFIER(word))
}
}
```
### Phase 3: Parser統合
```rust
impl Parser {
fn parse_statement(&mut self) -> Result<ASTNode> {
// 統一エンジンから構文規則を取得
let rule = self.engine.get_syntax_rule("statement");
rule.parse(self)
}
}
```
### Phase 4: セマンティクス統合
```rust
// Interpreter
impl Interpreter {
fn execute_binop(&mut self, op: &str, left: Value, right: Value) -> Value {
// 統一エンジンに委譲
self.engine.execute_semantic(op, &[left, right])
}
}
// VM
impl VM {
fn execute_add(&mut self) -> Result<()> {
let right = self.pop()?;
let left = self.pop()?;
// 統一エンジンに委譲
let result = self.engine.execute_semantic("add", &[left, right]);
self.push(result)
}
}
// JIT
impl JitBuilder {
fn lower_add(&mut self, left: Value, right: Value) {
// 統一エンジンから最適化ヒントを取得
let strategy = self.engine.get_jit_strategy("add", &left, &right);
strategy.emit(self, left, right)
}
}
```
## 🎯 統一定義ファイルの例
```toml
# grammar/unified-grammar.toml
[keywords.me]
token = "ME"
category = "self_reference"
deprecated_aliases = ["this", "self", "@"]
semantic_action = "load_self"
mir_opcode = "LoadSelf"
vm_handler = "OP_LOAD_ME"
jit_lowering = "emit_load_local(0)"
[keywords.from]
token = "FROM"
category = "delegation"
contexts = [
{ context = "class_decl", meaning = "inheritance" },
{ context = "method_call", meaning = "delegation_call" }
]
semantic_action = "delegate"
mir_opcode = "DelegateCall"
[keywords.loop]
token = "LOOP"
category = "control_flow"
deprecated_aliases = ["while", "for"]
semantic_action = "loop_construct"
mir_opcode = "Loop"
safepoint_insertion = true
[operators.add]
symbol = "+"
precedence = 10
associativity = "left"
type_rules = [
{ left = "String", right = "String", result = "String", action = "concat" },
{ left = "Integer", right = "Integer", result = "Integer", action = "add_i64" },
{ left = "Float", right = "Float", result = "Float", action = "add_f64" },
]
coercion_strategy = "string_priority" # String + anything = String
[semantics.string_concat]
interpreter = "rust:concatenate_strings"
vm = "CONCAT_STRINGS"
jit = "call @nyash.string.concat_hh"
```
## 🚀 期待される効果
1. **完全な一貫性**
- すべての層が同じ予約語定義を使用
- すべての層が同じ文法解釈を実行
- すべての層が同じセマンティクスを適用
2. **保守性の劇的向上**
- 新しい予約語/演算子の追加が1箇所
- 文法変更が全層に自動反映
- バグの削減（解釈の不一致がなくなる）
3. **AI開発の簡素化**
- 単一の文法定義をAIに学習させる
- 正しいNyashコードの生成率向上
- エラーメッセージの一貫性
4. **性能最適化の余地**
- 統一エンジンでの最適化が全層に効果
- JITヒントの統一管理
- キャッシュ戦略の一元化
## 📊 実装優先度
1. **最優先**: 予約語レジストリ（すぐ効果が出る）
2. **高優先**: セマンティクス統一（バグ削減効果大）
3. **中優先**: 構文規則エンジン（段階的移行可能）
4. **低優先**: JIT最適化ヒント（性能向上は後回し）
## 🔧 移行戦略
1. **並行実行期間**
- 新旧両方の実装を維持
- デバッグモードで差分検出
- 段階的に新実装に切り替え
2. **テスト駆動**
- 各層の動作一致を自動テスト
- スナップショットテストで回帰防止
- ファズテストで edge case 発見
3. **ドキュメント駆動**
- 統一文法仕様書を先に作成
- 実装は仕様書に従う
- AIトレーニングデータも同時生成
これにより、Nyashの全層で完全に統一された文法解釈と実行が実現される。

321
docs/private/roadmap/phases/phase-11.9/unified-keyword-system.md Normal file
View File

@ -0,0 +1,321 @@
# Nyash統一予約語システム仕様
## 🎯 目的
Nyashの全実行層（Script/MIR/VM/JIT）で完全に同一の予約語・文法解釈を実現する。
## 📊 現状の予約語分散状況
### Tokenizer層 (src/tokenizer.rs)
```rust
// 現在: ハードコードされた予約語
match word.as_str() {
"box" => TokenType::BOX,
"me" => TokenType::ME,
"from" => TokenType::FROM,
"loop" => TokenType::LOOP,
"if" => TokenType::IF,
"else" => TokenType::ELSE,
"local" => TokenType::LOCAL,
"return" => TokenType::RETURN,
"new" => TokenType::NEW,
"static" => TokenType::STATIC,
"init" => TokenType::INIT,
"birth" => TokenType::BIRTH,
"pack" => TokenType::PACK,
"override" => TokenType::OVERRIDE,
"and" => TokenType::AND,
"or" => TokenType::OR,
"not" => TokenType::NOT,
_ => TokenType::IDENTIFIER(word)
}
```
### MIR Builder層での独自解釈
```rust
// 現在: MIR生成時の独自判断
fn build_from_call(&mut self) {
// "from"の解釈がTokenizerと異なる可能性
}
```
### VM/JIT層での実行差異
```rust
// VM: 文字列連結の独自実装
VMValue::String(s1) + VMValue::String(s2) => concat
// JIT: 異なる最適化戦略
emit_call("nyash.string.concat_hh")
```
## 🏗️ 統一予約語システムの設計
### 1. 中央予約語レジストリ
```rust
// src/grammar/keyword_registry.rs
pub struct UnifiedKeywordRegistry {
keywords: HashMap<&'static str, UnifiedKeyword>,
}
pub struct UnifiedKeyword {
// トークン情報
pub token_type: TokenType,
pub literal: &'static str,
// 文法情報
pub category: KeywordCategory,
pub precedence: Option<i32>,
// セマンティクス情報
pub semantic_action: SemanticAction,
pub mir_instruction: Option<MirInstruction>,
pub vm_opcode: Option<VmOpcode>,
pub jit_pattern: Option<JitPattern>,
// メタ情報
pub deprecated_aliases: Vec<&'static str>,
pub ai_hint: &'static str,
}
// 静的に初期化される単一インスタンス
pub static KEYWORDS: Lazy<UnifiedKeywordRegistry> = Lazy::new(|| {
let mut registry = UnifiedKeywordRegistry::new();
// "me" - 自己参照
registry.register(UnifiedKeyword {
token_type: TokenType::ME,
literal: "me",
category: KeywordCategory::SelfReference,
semantic_action: SemanticAction::LoadSelf,
mir_instruction: Some(MirInstruction::LoadLocal(0)),
vm_opcode: Some(VmOpcode::LOAD_ME),
jit_pattern: Some(JitPattern::LoadFirstParam),
deprecated_aliases: vec!["this", "self", "@"],
ai_hint: "Always use 'me' for self-reference",
precedence: None,
});
// "from" - デリゲーション
registry.register(UnifiedKeyword {
token_type: TokenType::FROM,
literal: "from",
category: KeywordCategory::Delegation,
semantic_action: SemanticAction::DelegateCall,
mir_instruction: Some(MirInstruction::Call),
vm_opcode: Some(VmOpcode::DELEGATE_CALL),
jit_pattern: Some(JitPattern::VirtualCall),
deprecated_aliases: vec!["super", "parent", "base"],
ai_hint: "Use 'from' for parent method calls",
precedence: None,
});
// "loop" - 制御フロー
registry.register(UnifiedKeyword {
token_type: TokenType::LOOP,
literal: "loop",
category: KeywordCategory::ControlFlow,
semantic_action: SemanticAction::Loop,
mir_instruction: Some(MirInstruction::Branch),
vm_opcode: Some(VmOpcode::LOOP_START),
jit_pattern: Some(JitPattern::LoopWithSafepoint),
deprecated_aliases: vec!["while", "for", "repeat"],
ai_hint: "Only 'loop' exists for iteration",
precedence: None,
});
// 演算子も統一管理
registry.register(UnifiedKeyword {
token_type: TokenType::PLUS,
literal: "+",
category: KeywordCategory::BinaryOperator,
precedence: Some(10),
semantic_action: SemanticAction::Add,
mir_instruction: Some(MirInstruction::BinOp(BinOpKind::Add)),
vm_opcode: Some(VmOpcode::ADD),
jit_pattern: Some(JitPattern::PolymorphicAdd),
deprecated_aliases: vec![],
ai_hint: "String + String = concat, Number + Number = add",
});
registry
});
```
### 2. 各層での統一API使用
#### Tokenizer統合
```rust
impl NyashTokenizer {
fn tokenize_word(&mut self, word: String) -> TokenType {
// 統一レジストリを参照
KEYWORDS.lookup(&word)
.map(|kw| kw.token_type.clone())
.unwrap_or(TokenType::IDENTIFIER(word))
}
}
```
#### Parser統合
```rust
impl Parser {
fn parse_keyword(&mut self, token: &Token) -> Result<ASTNode> {
if let Some(keyword) = KEYWORDS.get_by_token(&token.token_type) {
// 統一されたセマンティクスアクションを実行
match keyword.semantic_action {
SemanticAction::Loop => self.parse_loop_unified(keyword),
SemanticAction::DelegateCall => self.parse_from_unified(keyword),
// ...
}
}
}
}
```
#### MIR Builder統合
```rust
impl MirBuilder {
fn build_keyword(&mut self, keyword: &UnifiedKeyword, args: Vec<MirValue>) -> MirValue {
// 統一されたMIR命令を生成
if let Some(mir_inst) = &keyword.mir_instruction {
self.emit_unified(mir_inst.clone(), args)
}
}
}
```
#### VM統合
```rust
impl VM {
fn execute_keyword(&mut self, keyword: &UnifiedKeyword) -> Result<()> {
// 統一されたVMオペコードを実行
if let Some(opcode) = &keyword.vm_opcode {
self.execute_unified_opcode(opcode)
}
}
}
```
#### JIT統合
```rust
impl JitBuilder {
fn compile_keyword(&mut self, keyword: &UnifiedKeyword, args: &[Value]) {
// 統一されたJITパターンを適用
if let Some(pattern) = &keyword.jit_pattern {
self.emit_unified_pattern(pattern, args)
}
}
}
```
## 🔄 セマンティクス統一の例
### 現在の問題: "+" 演算子の挙動差異
```rust
// Interpreter: 独自の型変換ロジック
fn execute_add(&mut self, left: Value, right: Value) -> Value {
// 複雑な型変換ロジック
}
// VM: 異なる型変換ロジック
fn vm_add(&mut self) {
// 別の型変換ロジック
}
// JIT: さらに異なる最適化
fn jit_add(&mut self) {
// JIT独自の最適化
}
```
### 統一後: 単一のセマンティクス定義
```rust
// src/grammar/unified_semantics.rs
pub struct UnifiedSemantics;
impl UnifiedSemantics {
/// すべての層が使用する統一Add実装
pub fn add(left: &Value, right: &Value) -> Result<Value> {
use Value::*;
match (left, right) {
// String優先（Nyashの仕様）
(String(s1), String(s2)) => Ok(String(s1.clone() + s2)),
(String(s), other) | (other, String(s)) => {
Ok(String(s.clone() + &Self::coerce_to_string(other)?))
}
// 数値演算
(Integer(i1), Integer(i2)) => Ok(Integer(i1 + i2)),
(Float(f1), Float(f2)) => Ok(Float(f1 + f2)),
(Integer(i), Float(f)) | (Float(f), Integer(i)) => {
Ok(Float(*i as f64 + f))
}
// その他はエラー
_ => Err(Error::TypeMismatch)
}
}
/// 統一された文字列変換
pub fn coerce_to_string(value: &Value) -> Result<String> {
match value {
Value::String(s) => Ok(s.clone()),
Value::Integer(i) => Ok(i.to_string()),
Value::Float(f) => Ok(f.to_string()),
Value::Bool(b) => Ok(b.to_string()),
Value::Null => Ok("null".to_string()),
_ => Err(Error::CannotCoerceToString)
}
}
}
// 各層での使用
// Interpreter
left_value = UnifiedSemantics::add(&left, &right)?;
// VM
let result = UnifiedSemantics::add(&self.pop()?, &self.pop()?)?;
self.push(result);
// JIT
self.emit_call("UnifiedSemantics::add", args);
```
## 📋 実装チェックリスト
- [ ] `src/grammar/keyword_registry.rs` - 統一予約語レジストリ
- [ ] `src/grammar/unified_semantics.rs` - 統一セマンティクス
- [ ] `src/grammar/mod.rs` - モジュール統合
- [ ] Tokenizer修正 - 統一レジストリ参照
- [ ] Parser修正 - 統一セマンティクス使用
- [ ] MIR Builder修正 - 統一MIR生成
- [ ] VM修正 - 統一実行
- [ ] JIT修正 - 統一コード生成
- [ ] テストスイート - 全層の一致確認
- [ ] ドキュメント - 統一仕様書
## 🎯 成功基準
1. **完全一致**: すべての層で同じ入力が同じ出力を生成
2. **単一修正**: 新予約語追加が1ファイルの修正で完了
3. **AI正確性**: AIが生成するコードのエラー率90%削減
4. **性能維持**: 統一化による性能劣化5%以内
## 🚀 移行計画
### Phase 1: 基盤構築（1週間）
- 統一レジストリ実装
- 既存コードとの並行動作
### Phase 2: Tokenizer/Parser統合（1週間）
- 段階的切り替え
- 差分検出とログ
### Phase 3: 実行層統合（2週間）
- MIR/VM/JIT の統一
- 包括的テスト
### Phase 4: 完全移行（1週間）
- 旧コード削除
- ドキュメント完成
これにより、Nyashのすべての層で完全に統一された予約語・文法解釈が実現される。

255
docs/private/roadmap/phases/phase-11.9/unified-semantics-implementation.txt Normal file
View File

@ -0,0 +1,255 @@
# Nyash統一セマンティクス実装設計
# 作成日: 2025-09-02
# 目的: Interpreter/VM/JIT全層での予約語・文法解釈の完全統一
## 概要
すべての実行層が同じセマンティクスに従うよう、MIR正規化層を中心とした統一実装を行う。
## 核心的な問題
現在、同じ式が各層で異なる解釈をされている：
- "hello" + 123
- Interpreter: エラーを出す
- VM: 型変換してから連結
- JIT: 数値を文字列化してから連結
## 解決策：MIR統一セマンティクス + 軽量UIRタグ
### 1. 統一セマンティクス定義（grammar/semantics.yml）
```yaml
# すべての層が従う唯一の定義
version: "1.0"
semantics:
add:
- pattern: [String, String]
action: concat
mir: StringConcat
vm: OP_STR_CONCAT
- pattern: [String, Any]
action: coerce_concat
steps:
- ToString($2)
- StringConcat($1, $2)
- pattern: [Integer, Integer]
action: add_i64
mir: AddI64
vm: OP_ADD_I64
toString:
- pattern: [String]
action: identity
- pattern: [Integer]
action: int_to_string
- pattern: [Float]
action: float_to_string
- pattern: [Bool]
action: bool_to_string
- pattern: [Null]
action: const_null_string
```
### 2. UIRタグシステム（層間通信）
```rust
// generated/uir_tags.rs (build.rsで生成)
#[derive(Copy, Clone, Debug, Eq, PartialEq)]
#[repr(u32)]
pub enum UIRTag {
// 予約語
ME = 1,
FROM = 2,
LOOP = 3,
BOX = 4,
INIT = 5,
// 演算子
ADD = 100,
SUB = 101,
MUL = 102,
DIV = 103,
// セマンティクスアクション
STRING_CONCAT = 200,
TO_STRING = 201,
ADD_I64 = 202,
ADD_F64 = 203,
}
```
### 3. MIR正規化層（真実の基盤）
```rust
// src/mir/normalizer.rs
pub struct MIRNormalizer {
semantics_table: SemanticRuleTable,
}
impl MIRNormalizer {
pub fn normalize(&self, expr: &Expression) -> MIR {
match expr {
Expression::BinaryOp(op, left, right) => {
let left_type = self.infer_type(left);
let right_type = self.infer_type(right);
// 統一ルールを適用
let rule = self.semantics_table.lookup(op, &[left_type, right_type]);
match rule.action {
Action::Concat => {
MIR::StringConcat(
Box::new(self.normalize(left)),
Box::new(self.normalize(right))
)
}
Action::CoerceConcat => {
// 右辺を文字列に変換してから連結
MIR::Sequence(vec![
self.normalize(left),
MIR::ToString(Box::new(self.normalize(right))),
MIR::StringConcat
])
}
Action::AddI64 => {
MIR::AddI64(
Box::new(self.normalize(left)),
Box::new(self.normalize(right))
)
}
}
}
}
}
}
```
### 4. 各層の統一実装
#### Interpreter層
```rust
impl Interpreter {
fn execute_expression(&mut self, expr: &Expression) -> Result<Value> {
// すべてMIR経由で実行
let mir = self.mir_normalizer.normalize(expr);
self.execute_mir(&mir)
}
fn execute_mir(&mut self, mir: &MIR) -> Result<Value> {
match mir {
MIR::StringConcat(left, right) => {
let left_val = self.execute_mir(left)?;
let right_val = self.execute_mir(right)?;
Ok(Value::String(format!("{}{}", left_val, right_val)))
}
MIR::ToString(expr) => {
let val = self.execute_mir(expr)?;
Ok(Value::String(self.value_to_string(&val)))
}
MIR::AddI64(left, right) => {
let left_val = self.execute_mir(left)?;
let right_val = self.execute_mir(right)?;
Ok(Value::Integer(left_val.as_i64()? + right_val.as_i64()?))
}
}
}
}
```
#### VM層
```rust
impl VM {
fn compile_mir(&mut self, mir: &MIR) -> Vec<Opcode> {
// MIRから機械的にバイトコード生成
match mir {
MIR::StringConcat(left, right) => {
let mut code = vec![];
code.extend(self.compile_mir(left));
code.extend(self.compile_mir(right));
code.push(Opcode::StringConcat);
code
}
MIR::ToString(expr) => {
let mut code = self.compile_mir(expr);
code.push(Opcode::ToString);
code
}
MIR::AddI64(left, right) => {
let mut code = vec![];
code.extend(self.compile_mir(left));
code.extend(self.compile_mir(right));
code.push(Opcode::AddI64);
code
}
}
}
}
```
#### JIT層
```rust
impl JITCompiler {
fn compile_mir(&mut self, mir: &MIR) {
// MIRから最適化されたネイティブコード生成
match mir {
MIR::StringConcat(left, right) => {
self.compile_mir(left);
self.compile_mir(right);
// 高速な文字列連結関数を呼び出し
self.emit_call(fast_string_concat);
}
MIR::ToString(expr) => {
self.compile_mir(expr);
// 型に応じた最適な変換
self.emit_call(optimized_to_string);
}
MIR::AddI64(left, right) => {
self.compile_mir(left);
self.compile_mir(right);
// ネイティブな加算命令
self.emit_add_i64();
}
}
}
}
```
## 実装手順
### Phase 1: 基盤構築（1週間）
1. grammar/semantics.yml 作成
2. UIRTag定義とbuild.rs生成
3. SemanticRuleTable実装
### Phase 2: MIR正規化層（1週間）
1. MIRNormalizer実装
2. 型推論システム構築
3. セマンティクステーブル連携
### Phase 3: 各層統合（2週間）
1. Interpreterを MIR経由に変更
2. VMのMIRコンパイラ実装
3. JITのMIRコンパイラ実装
### Phase 4: テストと検証（1週間）
1. 統一セマンティクステスト作成
2. 各層での一貫性検証
3. パフォーマンス測定
## 期待される効果
1. **完全な一貫性**: すべての層が同じ動作
2. **保守性向上**: セマンティクス変更が1箇所
3. **拡張性**: 新しい演算子の追加が容易
4. **AI対応**: 単一の仕様から学習可能
5. **デバッグ容易性**: MIRレベルでの統一デバッグ
## 注意事項
- 既存のコードとの互換性を保つため、フィーチャーフラグで段階的移行
- パフォーマンスへの影響を最小限にするため、ビルド時最適化を活用
- テストカバレッジを十分に確保してから本番移行
## 関連ファイル
- grammar/semantics.yml - セマンティクス定義
- src/mir/normalizer.rs - MIR正規化実装
- build.rs - コード生成
- tests/unified_semantics.rs - 統一テスト

452
docs/private/roadmap/phases/phase-12.7/README.md Normal file
View File

@ -0,0 +1,452 @@
# Phase 12.7 - 文法改革 + AI統合最適化
🚀 **究極の挑戦**: 文法革新 × 極限圧縮 = 90%コード削減！
## 📋 統合概要
Phase 12.7は3つの革命的な改革の段階的実装です：
### Phase 12.7-A: 基礎文法改革（✅ 実装済み）
- 予約語15個への削減（peek, birth, continue統一）
- peek構文による分岐革命
- continue文の追加
- ?演算子（Result伝播）
- Lambda式（fn文法）
- フィールド型アノテーション（field: TypeBox）
### Phase 12.7-B: ChatGPT5糖衣構文（✅ 基本完了／拡張はゲート計画）
- 基本（P0・実装済み、ゲート可）
- パイプライン演算子（`|>`）
- セーフアクセス（`?.`）とデフォルト値（`??`）
- 拡張（P1・段階適用、設計/ドキュメント整備済み）
- デストラクチャリング（`{x,y}`, `[a,b,...]`）
- 増分代入（`+=, -=, *=, /=`）
- 範囲演算子（`a .. b` → `Range(a,b)`）
- 高階関数演算子（`/:` map, `\:` filter, `//` reduce）
- ラベル付き引数（`key: value`）
**🎯 重要な設計方針：**
- **使いたい人が使いたい糖衣構文を選択可能**
- **すべての糖衣構文は元のNyashコードに可逆変換可能**
- **明示性と超圧縮の両立** - 用途に応じて使い分け
### Phase 12.7-C: ANCP圧縮記法（📅 計画中）
- ANCP v1.0（48%削減）
- 極限糖衣構文（75%削減）
- 融合記法（90%削減）
- 可逆フォーマッター完備
- 参考: `ancp-specs/ANCP-Reversible-Mapping-v1.md`（12.7‑B subset の可逆化）
- nyfmt PoC: `docs/tools/nyfmt/NYFMT_POC_ROADMAP.md` / `tools/nyfmt_smoke.sh`
## 🎯 なぜPhase 12.7なのか？
### タイミングの完璧さ
- **Phase 12**: TypeBox統合ABI完了（安定した基盤）
- **Phase 12.5**: MIR15最適化（コンパクトな中間表現）
- **Phase 12.7**: ANCP（AIとの架け橋）← **ここ！**
- **Phase 13**: ブラウザー革命（別の大きな挑戦）
- **Phase 15**: セルフホスティング（ANCPで書かれた超小型コンパイラ！）
### 戦略的価値
1. **即効性**: 実装が比較的簡単で、すぐに効果が出る
2. **相乗効果**: Phase 15のセルフホスティングと組み合わせて究極の圧縮
3. **AI協働**: Claude/ChatGPT/Gemini/Codexとの開発効率が劇的に向上
## 🌟 革命的インパクト
### Phase 12.7-A: 実装済み機能（2025-09-04）
```nyash
# Peek式 - パターンマッチング風分岐
local result = peek status {
"success" => 200,
"error" => 500,
"pending" => 102,
else => 404
}
# Continue文 - ループ制御
loop(i < 100) {
if i % 2 == 0 {
continue # 偶数スキップ
}
process(i)
}
# ?演算子 - Result伝播
local config = readFile("app.json")? # エラーなら早期return
local version = parseJSON(config)?.get("version")?
# Lambda式
local double = fn(x) { x * 2 }
array.map(fn(x) { x * x })
```
### Phase 12.7-B: ChatGPT5糖衣構文（実装済みの例／拡張の草案）
```nyash
# パイプライン演算子（|>）
local result = data
|> normalize()
|> transform()
|> validate()?
|> finalize()
# セーフアクセス（?.）とデフォルト値（??）
local name = user?.profile?.name ?? "Guest"
# デストラクチャリング
let {x, y} = point
let [first, second, ...rest] = array
# 増分代入
count += 1
total *= 1.1
# 高階関数演算子（記号による簡潔表現）
evens = nums \: {$_%2==0} # filter: 偶数のみ
squares = nums /: {$_*$_} # map: 二乗
sum = nums // {$1+$2} # reduce: 合計
# ラベル付き引数
Http.request(
url: "/api/data",
method: "POST",
headers: {"Content-Type": "application/json"},
body: payload
)
```
### Phase 12.7-C: ANCP記法（計画中）
```nyash
// 通常のNyash（約100文字）
box NyashCompiler {
compile(source) {
local ast = me.parse(source)
local mir = me.lower(ast)
return me.codegen(mir)
}
}
// ChatGPT5糖衣構文適用（約60文字） - 40%削減！
box NyashCompiler {
compile(source) {
return source |> me.parse |> me.lower |> me.codegen
}
}
// ANCP記法（約30文字） - 70%削減！
$NyashCompiler{compile(s){r s|>m.parse|>m.lower|>m.codegen}}
// 夢の組み合わせ：
// Phase 15: 80k行 → 20k行（75%削減）
// + 糖衣構文: 20k行 → 12k行（40%削減）
// + ANCP: 12k行 → 6k行相当（50%削減）
// = 最終的に92.5%削減！世界一小さい実用コンパイラ！
```
### AIコンテキスト革命
- **GPT-4** (128k tokens): 通常2万行 → ANCP で4万行扱える！
- **Claude** (200k tokens): 通常4万行 → ANCP で8万行扱える！
- **Nyash全体のソースコード** がAIのコンテキストに収まる！
## 🎯 最重要ドキュメント
### 📚 実装者必読
- **[🚀 ANCP実装計画（統合版）](implementation/ANCP-IMPLEMENTATION-PLAN.md)** ← ⭐ START HERE! ⭐
- **[📋 ANCP Token仕様書 v1](ancp-specs/ANCP-Token-Specification-v1.md)** - ChatGPT5作成の最新仕様
- [🔧 実装チェックリスト](implementation/implementation-final-checklist.txt)
### 📐 ANCP仕様書
- **[🔥 究極のAIコーディングガイド](ancp-specs/ULTIMATE-AI-CODING-GUIDE.md)** - 5層圧縮体系
- [⚡ 極限糖衣構文提案](ancp-specs/extreme-sugar-proposals.txt)
- [🔄 糖衣構文フォーマッター](ancp-specs/sugar-formatter-tool.txt)
- [🔬 圧縮技術参考ライブラリ](ancp-specs/compression-reference-libraries.md)
### 📝 文法仕様書
- [📝 文法改革最終決定](grammar-specs/grammar-reform-final-decision.txt)
- [📐 文法技術仕様書](grammar-specs/grammar-technical-spec.txt)
### 🤖 AIアドバイザーフィードバック
- **[📋 統合フィードバック](ai-feedback/)** - 全AIアドバイザーの知見
- [ChatGPT5実装アドバイス](ai-feedback/chatgpt5-ancp-implementation-advice.md)
- [Claude/Codex技術分析](ai-feedback/codex-ancp-response.md)
- [Gemini革命的評価](ai-feedback/gemini-ancp-response.md)
- [即座実装ガイド](ai-feedback/quick-implementation-guide.md)
### 📁 アーカイブ（検討過程）
- [🗃️ 過去の議論・検討資料](archive/)
## 📊 主要成果物
### Phase 12.7-A: 基礎文法改革（✅ 完了）
- ✅ 予約語15個確定（peek, birth, continue追加）
- ✅ peek構文実装完了
- ✅ continue文実装完了
- ✅ ?演算子（Result伝播）実装完了
- ✅ Lambda式（fn構文）実装完了
- ✅ フィールド型アノテーション実装完了
### Phase 12.7-B: ChatGPT5糖衣構文（✅ 基本完了／拡張はゲート計画）
- 📅 パイプライン演算子（|>）
- 📅 セーフアクセス（?.）とデフォルト値（??）
- 📅 デストラクチャリング（パターン束縛）
- 📅 増分代入演算子（+=, -=, *=, /=）
- 📅 範囲演算子（..）
- 📅 高階関数演算子（/:, \:, //）
- 📅 ラベル付き引数
### Phase 12.7-C: ANCP圧縮記法（📅 計画中）
- ✅ ANCP v1.0仕様完成（48%圧縮）
- ✅ 極限糖衣構文設計（75%圧縮）
- ✅ 融合記法考案（90%圧縮）
- ✅ 可逆フォーマッター仕様完成
- 📅 統合ツール実装
- 📅 VSCode拡張
## 🔧 技術的アプローチ
### 記号マッピング（最適化版）
```
【高頻度・基本】
box → $ # Box定義（毎回出現）
new → n # インスタンス生成
me → m # 自己参照（超頻出）
local → l # ローカル変数
return → r # 戻り値
【構造系】
from → @ # 継承/デリゲーション
init → # # フィールド初期化
birth → b # コンストラクタ
static → S # 静的定義
【制御系】
if → ? # 条件分岐
else → : # else節
loop → L # ループ
override → O # オーバーライド
```
### 🔄 可逆変換保証
**すべての糖衣構文は双方向変換可能：**
```bash
# フォーマッターによる自由な変換
nyash format --style=explicit code.nyash # 明示的記法へ
nyash format --style=sugar code.nyash # 糖衣構文へ
nyash format --style=ancp code.nyash # 極限圧縮へ
```
**同じコードの3つの表現：**
```nyash
# 明示的（学習・デバッグ用）
result = users.filter(function(u) { return u.active }).map(function(u) { return u.name })
# 糖衣構文（通常開発用）
result = users \: {$_.active} /: {$_.name}
# ANCP圧縮（AI協働用）
r=u\:_.a/:_.n
```
### 実装優先順位
#### Phase 12.7-B: ChatGPT5糖衣構文（実装中）
**優先度1: 即効性の高い演算子（1週間）**
```rust
// tokenizer.rs に追加
PIPE, // |> パイプライン
SAFE_ACCESS, // ?. セーフアクセス
NULL_COALESCE, // ?? デフォルト値
PLUS_ASSIGN, // += 増分代入
MINUS_ASSIGN, // -= 減分代入
// etc...
```
**優先度2: パイプラインとセーフアクセス（2週間）**
```nyash
// パイプライン: x |> f → f(x)
// セーフアクセス: x?.y → x != null ? x.y : null
// デフォルト値: x ?? y → x != null ? x : y
```
**優先度3: デストラクチャリング（3週間）**
```nyash
// オブジェクト: let {x, y} = point
// 配列: let [a, b, ...rest] = array
// MIR変換: 複数のLoad命令に展開
```
#### Phase 12.7-C: ANCP圧縮記法（計画中）
**Phase 1: 基本トランスコーダー（1週間）**
```rust
pub struct AncpTranscoder {
mappings: HashMap<&'static str, &'static str>,
sugar_enabled: bool, // 糖衣構文も含めて圧縮
}
```
**Phase 2: スマート変換（2週間）**
- コンテキスト認識（文字列内は変換しない）
- 空白・コメント保持
- エラー位置マッピング
**Phase 3: ツール統合（2週間）**
- VSCode拡張（ホバーで元のコード表示）
- CLIツール（--format=ancp オプション）
- スモークテスト自動ANCP化
## 🔗 関連ドキュメント
- [ANCP技術仕様](technical-spec.md)
- [実装計画](implementation-plan.md)
- [AI統合ガイド](ai-integration-guide.md)
- [元のアイデア文書](../../../ideas/new-features/2025-08-29-ai-compact-notation-protocol.md)
## 📅 実施スケジュール
### Phase 12.7-A（✅ 完了）
- ✅ peek式、continue文、?演算子、Lambda式
- ✅ フィールド型アノテーション
- ✅ birth統一、予約語15個確定
### Phase 12.7-B（🔄 実装中）
#### Week 1-2: 基本演算子
- 基本（P0・実装済み、ゲート可）
- パイプライン演算子（`|>`）
- セーフアクセス（`?.`）とデフォルト値（`??`）
- 増分代入演算子（+=, -=等）
#### Week 3-4: 高度な構文
- デストラクチャリング（{}, []）
- 範囲演算子（..）
- 高階関数演算子（/:, \:, //）
#### Week 5: 統合・最適化
- ラベル付き引数
- MIR変換最適化
- テストスイート完成
### Phase 12.7-C（📅 計画中）
- **Week 1**: 基本トランスコーダー実装
- **Week 2**: パーサー統合・往復テスト
- **Week 3**: ツール実装（CLI/VSCode）
- **Week 4**: AI連携・最適化
## 🎨 糖衣構文の使い分けガイド
### 用途別推奨レベル
| 用途 | 推奨記法 | 理由 |
|------|----------|------|
| 学習・チュートリアル | 明示的 | 動作が明確 |
| 通常の開発 | 基本糖衣 | バランスが良い |
| コードレビュー | 明示的〜基本糖衣 | 可読性重視 |
| AI協働開発 | 全糖衣〜ANCP | コンテキスト最大化 |
| セルフホスティング | ANCP | 極限圧縮必須 |
### プロジェクト設定例
```toml
# nyash.toml
[syntax]
# none: 糖衣構文なし（明示的のみ）
# basic: 基本的な糖衣構文（+=, ?., ??）
# full: すべての糖衣構文（高階関数演算子含む）
# ancp: ANCP記法も許可
sugar_level = "full"
# 高階関数演算子の有効化
high_order_operators = true
# 可逆変換の検証（保存時に自動チェック）
verify_reversible = true
```
## 💡 期待される成果
### 定量的
- **Phase 12.7-B（糖衣構文）**: コード削減率 40-50%
- **Phase 12.7-C（ANCP）**: さらに50-60%削減
- **総合効果**: 最大92.5%のコード削減
- **AI開発効率**: 3-5倍向上
- **コンテキスト容量**: 10倍に拡大
### 定性的（追加）
- **選択の自由**: 開発者が好きな記法を選べる
- **可逆性保証**: いつでも別の形式に変換可能
- **段階的導入**: プロジェクトごとに糖衣レベルを調整
### 定性的
- **可読性向上**: パイプライン演算子で処理フローが明確に
- **安全性向上**: セーフアクセスでnullエラー激減
- **表現力向上**: 高階関数演算子で関数型プログラミングが簡潔に
- **AIとの親和性**: より多くのコードをAIが一度に理解可能
- **学習曲線**: 他言語経験者にとって馴染みやすい構文
## 🌟 夢の実現
### Phase 15との究極コンボ
```nyash
// 通常のセルフホスティングコンパイラ
box Compiler {
compile(source) {
local ast = me.parser.parse(source)
local mir = me.lowerer.transform(ast)
local code = me.backend.generate(mir)
return code
}
}
// ChatGPT5糖衣構文適用版
box Compiler {
compile(source) {
return source
|> me.parser.parse
|> me.lowerer.transform
|> me.backend.generate
}
}
// ANCP記法（究極形態）
$Compiler{compile(s){r s|>m.parser.parse|>m.lowerer.transform|>m.backend.generate}}
```
これが「世界一美しい箱」の究極形態にゃ！
### ChatGPT5糖衣構文によるコード例の変革
```nyash
# Before: ネストした関数呼び出し（読みづらい）
result = finalize(validate(transform(normalize(data))))
# After: パイプライン（処理の流れが明確）
result = data |> normalize |> transform |> validate |> finalize
# Before: null安全でない（実行時エラーの危険）
name = user.profile.name
# After: セーフアクセス（null安全）
name = user?.profile?.name ?? "Guest"
# Before: 冗長な配列処理
evens = []
for x in numbers {
if x % 2 == 0 {
evens.push(x * x)
}
}
# After: 高階関数演算子（簡潔で宣言的）
evens = numbers \: {$_%2==0} /: {$_*$_}
```
## 🚀 なぜ今すぐ始めるべきか
1. **AI時代の必須技術**: コンテキスト制限との戦い
2. **開発効率の即効薬**: 今すぐ効果を実感
3. **Nyashの差別化要因**: 他言語にない強み
> 「コードも箱に入れて、小さく美しく」- ANCP Philosophy
---
Phase 12.7は、Nyashを真のAI時代のプログラミング言語にする重要な一歩です。

61
docs/private/roadmap/phases/phase-12.7/ancp-specs/ANCP-Reversible-Mapping-v1.md Normal file
View File

@ -0,0 +1,61 @@
# ANCP v1 – Reversible Mapping (P0 subset)
Status: Preview (12.7‑C P0). Scope is the sugar subset already implemented and gated in 12.7‑B.
Goals
- Provide a clear, reversible mapping between Nyash sugar and canonical forms.
- Make round‑trip (original → canonical → ANCP → canonical → original) predictable for the subset.
Gating
- Runtime sugar is gated by `NYASH_SYNTAX_SUGAR_LEVEL=basic|full`.
- ANCP tools/nyfmt remain PoC/docs only at this stage.
Subset Mappings
- Pipeline `|>`
- Nyash: `lhs |> f(a,b)` → Canonical: `f(lhs, a, b)`
- Nyash: `lhs |> obj.m(a)` → Canonical: `obj.m(lhs, a)`
- Round‑trip invariant: No change of call order or arity.
- Safe Access `?.`
- Nyash: `a?.b` → Canonical (peek): `peek a { null => null, else => a.b }`
- Nyash: `a?.m(x)` → Canonical: `peek a { null => null, else => a.m(x) }`
- Round‑trip invariant: No change of receivers/args; only the null guard appears.
- Default `??`
- Nyash: `a ?? b` → Canonical (peek): `peek a { null => b, else => a }`
- Round‑trip invariant: Both branches preserved as‑is.
- Range `..`
- Nyash: `a .. b` → Canonical: `Range(a, b)`
- Round‑trip invariant: Closed form preserved; no inclusive/exclusive change.
- Compound Assign `+=, -=, *=, /=`
- Nyash: `x += y` → Canonical: `x = x + y`（`x` は変数/フィールド）
- Round‑trip invariant: Operator identity preserved; left target identical.
Examples (Before / Canonical / Round‑Trip)
1) Pipeline + Default
```
Before: data |> normalize() |> transform() ?? fallback
Canonical: peek transform(normalize(data)) { null => fallback, else => transform(normalize(data)) }
RoundTrip: data |> normalize() |> transform() ?? fallback
```
2) Safe Access Chain
```
Before: user?.profile?.name
Canonical: peek user { null => null, else => peek user.profile { null => null, else => user.profile.name } }
RoundTrip: user?.profile?.name
```
3) Range + Compound Assign
```
Before: i += 1; r = 1 .. 5
Canonical: i = i + 1; r = Range(1, 5)
RoundTrip: i += 1; r = 1 .. 5
```
Notes
- Precise precedence handling is left to the parser; mappings assume already parsed trees.
- Full ANCP compact tokens will be documented in a separate spec revision.

230
docs/private/roadmap/phases/phase-12.7/ancp-specs/ANCP-Token-Specification-v1.md Normal file
View File

@ -0,0 +1,230 @@
# ANCP Transcoder v1 トークン仕様（EBNF＋運用ルール）
Author: ChatGPT5
Date: 2025-09-03
Version: 1.0
> まずは「P=Pretty（正典）→C=Compact（ANCP ASCII/Unicode）」の**トークン変換**が安全に往復できる最小コア。
## 1) レクサの前提
* 入力は UTF-8。**ASCIIモード**と**Unicodeモード**を切替（既定=ASCII）。
* 変換は**トークン列→トークン列**。**文字列/コメント/正規表現**内部は**絶対に変換しない**。
* 空白/改行/コメントは**隣接トークン間のメタに付与**して保持（ソースマップ2.0）。
### 1.1 トークンクラス（共通）
```ebnf
Identifier = IDStart IDContinue* ;
IDStart = Letter | "_" ;
IDContinue = IDStart | Digit ;
Digit = "0"…"9" ;
Letter = "A"…"Z" | "a"…"z" | NonAsciiLetter ;
IntLiteral = Digit+ ;
FloatLiteral = Digit+ "." Digit+ (ExponentPart)? | "." Digit+ (ExponentPart)? ;
ExponentPart = ("e"|"E") ("+"|"-")? Digit+ ;
StringLit = '"' ( Escape | ~["\r\n] )* '"'
| "'" ( Escape | ~['\r\n] )* "'" ;
Escape = "\\" . ;
RegexLit = "/" ( Escape | ~[/\r\n] )+ "/" [a-z]* ; // Pのみ（Cでは素通し）
CommentLine = "//" ~[\r\n]* ;
CommentBlock = "/*" .*? "*/" ; // ネスト不可（Phase1）
WS = Space | Tab ;
NL = "\r"? "\n" ;
```
## 2) 予約語と記号マップ（P→C）
**衝突しないASCII記号**を採用。Unicodeモードは `→` の右側を `uni` 欄で置換。
**識別子と区別**するため、`~x` 形は**先頭に `~`**を付ける（通常のIDに現れにくい）。
| 機能 | Pretty(P) | Compact(C ascii) | Compact(C uni) |
|------|-----------|------------------|----------------|
| Box定義 | `box` | `$` | `＄` |
| 新規生成 | `new` | `~n` | `ⁿ` |
| 自参照 | `me` | `m` | `ｍ` |
| 局所変数 | `local` | `~l` | `ˡ` |
| 戻り | `return` | `~r` | `↩` |
| 継承/委譲 | `from` | `@` | `＠` |
| 初期化 | `init` | `#` | `＃` |
| コンストラクタ | `birth` | `b` | `ᵇ` |
| 静的 | `static` | `S` | `Ｓ` |
| 条件 | `if` | `?` | `？` |
| else | `else` | `:` | `：` |
| ループ | `loop` | `~L` | `ᴸ` |
| 継続 | `continue` | `~c` | `↻` |
| 分岐peek | `peek` | `~p` | `ᵖ` |
> 予約域：`~[A-Za-z]` は**将来予約**で識別子に使えないことを仕様化。
## 3) 演算子・糖衣（P↔C 等価）
* パイプ |>: `a |> f(x)` → **そのまま**（記号は等価、空白最小化のみ）
* セーフアクセス ?.: `o?.f` → **そのまま**
* ディレクティブ /:: `/: name` → **そのまま**（意味を壊さず最小化）
## 4) セパレータ・自動挿入規約
* **C出力**時、**記号トークンの左右に英数IDが隣接**する場合は**1スペース**を強制挿入（`m$X` の誤読防止）。
* セミコロンは P 側の規約準拠。C では**危険箇所のみ挿入**（§6の「ASI判定」参照）。
## 5) 変換アルゴリズム（疑似コード）
```text
encode(P → C):
lex P → tokens[]
for t in tokens:
if t in (StringLit, Comment*, RegexLit): emit t (verbatim); continue
if t is Keyword and t.lexeme in MAP: emit MAP[t.lexeme] as SymbolToken
else emit t (with WS-minify rules)
apply ASI (only-when-necessary)
attach inter-token trivia to sourcemap
decode(C → P):
lex C → tokens[]
for t in tokens:
if t is SymbolToken and t.lexeme in INV_MAP: emit INV_MAP[t.lexeme] as Keyword
else emit t
restore WS/comments by sourcemap if available
```
## 6) ASI（セミコロン自動挿入）判定（最小）
**挿入する**条件（どれか）：
1. 次トークンが `}` / EOF
2. 現トークンが `return (~r) / continue (~c) / break` 等で、**直後が行末**
3. 構文上、次トークンが**先頭に来るべき**（例えば次が `box/$` 定義）
**挿入しない**：
* 行末でも、次トークンが `(` `[` `{` `.` `?.` `/:` のとき
## 7) EBNF（P→C 変換で必要なサブセット）
**目的**：可逆のための**字句と一部構文の境界**を定義。完全文法ではなく、トークン接合規則に必要な核のみ。
```ebnf
Program = WS_NL* (Stmt WS_NL*)* ;
Stmt = BoxDecl
| LocalDecl
| ReturnStmt
| ExprStmt
;
BoxDecl = "box" Identifier BoxBody ;
BoxBody = "{" (MemberDecl WS_NL*)* "}" ;
MemberDecl = ( FieldDecl | MethodDecl | StaticDecl ) ;
FieldDecl = ( "init" | "#" ) Identifier ( "=" Expr )? ";"? ;
MethodDecl = Identifier ParamList Block ;
StaticDecl = ( "static" | "S" ) MethodDecl ;
LocalDecl = ( "local" | "~l" ) Identifier ( "=" Expr )? ";"? ;
ReturnStmt = ( "return" | "~r" ) Expr? ";"? ;
ExprStmt = Expr ";"? ;
Expr = AssignExpr ;
AssignExpr = OrExpr ( AssignOp OrExpr )? ;
AssignOp = "=" | "+=" | "-=" | "*=" | "/=" ;
OrExpr = AndExpr ( "||" AndExpr )* ;
AndExpr = PipeExpr ( "&&" PipeExpr )* ;
PipeExpr = TernaryExpr ( "|>" CallLike )* ;
TernaryExpr = NullsafeExpr ( "?" Expr ":" Expr )? ;
NullsafeExpr = MemberExpr | MemberExpr "?." Identifier | MemberExpr "/:" Identifier ;
MemberExpr = Primary ( ("." | "[") ... )? ; // 省略（可逆に影響しない部分）
CallLike = Identifier | Call ;
Call = Identifier "(" ArgList? ")" ;
ArgList = Expr ("," Expr)* ;
Primary = Identifier
| Literal
| "(" Expr ")"
;
Literal = IntLiteral | FloatLiteral | StringLit | RegexLit ;
Identifier = see §1.1 ;
```
> **ポイント**
> * `FieldDecl` は `init` と `#` を等価扱い（Cでは `#` に寄せる）
> * `StaticDecl` は `static` と `S` を等価
> * `LocalDecl` は `local` と `~l` を等価
> * `ReturnStmt` は `return` と `~r` を等価
> * `box` は `$` と等価（`BoxDecl`）
## 8) ソースマップ2.0（トークン粒度）
* **単一フォーマット（JSON Lines 推奨）**：各出力トークンに**元トークン範囲**と**トリビア**を付与。
```json
{"out_i":42,"out_span":[l1,c5,l1,c6],"in_file":"foo.ny","in_span":[l10,c1,l10,c3],"trivia":{"lead":" ","trail":""}}
```
* 例外/ログは**BoxID + トークン範囲**で P へ逆引き。
## 9) 衝突回避ルール（最重要）
* **ASCIIモード**：`~[A-Za-z]` は**保留記号**。Identifier と**絶対に一致しない**。
* **記号の周囲**：`$ m` のように**必要時1スペース**（前後が英数IDの場合）。
* **文字列/コメント/Regex**：**一切変換せず** verbatim。
## 10) 例（往復保証）
**P (Pretty)**
```nyash
box NyashCompiler {
compile(source) {
local ast = me.parse(source)
local mir = me.lower(ast)
return me.codegen(mir)
}
}
```
**C (Compact ASCII)**
```
$ NyashCompiler{
compile(src){
~l ast=m.parse(src)
~l mir=m.lower(ast)
~r m.codegen(mir)
}
}
```
**decode(C) → P** は上記Pと**等価**（空白/改行はソースマップで復元）。
---
## 実装メモ（すぐ書ける骨組み）
* レクサは **状態機械**：`DEFAULT / STRING / REGEX / COMMENT`
* 置換は**辞書マッチ → 最長一致**（`box`→`$` を `Identifier` と衝突させない）
* 出力時に**区切り挿入規則**を適用：`need_space(prev, next)`
* ASI は §6 の規則のみ実装（Phase1）。曖昧時は**セミコロン挿入を選ぶ**。
---
これで **Phase 12.7-A（Week1）** の「P↔C 可逆・安全」まで一気に行けるにゃ。
次にやるなら：この仕様をそのまま基に**トークナイザのテストケース**（OK/NG 30本）を並べよう。

57
docs/private/roadmap/phases/phase-12.7/ancp-specs/README.md Normal file
View File

@ -0,0 +1,57 @@
# ANCP (AI-Nyash Compact Notation Protocol) 仕様書
このフォルダには、ANCP圧縮技法に関する全ての仕様書と技術文書が含まれています。
## 📄 ドキュメント一覧
### 🎯 中核仕様
- **[ANCP-Token-Specification-v1.md](ANCP-Token-Specification-v1.md)** - ChatGPT5作成のトークン仕様書 v1.0
- P（Pretty）→ C（Compact）変換の完全仕様
- EBNF文法定義
- トークン変換ルール
- 衝突回避メカニズム
### 🔥 圧縮体系
- **[ULTIMATE-AI-CODING-GUIDE.md](ULTIMATE-AI-CODING-GUIDE.md)** - 5層圧縮体系の統合ガイド
- L0: Standard (通常のNyash)
- L1: Pretty (整形済み)
- L2: Compact (48%圧縮)
- L3: Sugar (75%圧縮)
- L4: Fusion (90%圧縮)
### ⚡ 糖衣構文
- **[extreme-sugar-proposals.txt](extreme-sugar-proposals.txt)** - 極限糖衣構文の提案集
- パイプライン演算子 `|>`
- 安全アクセス演算子 `?.`
- ディレクティブ記法 `/:`
- その他の革新的構文
### 🔄 ツール仕様
- **[sugar-formatter-tool.txt](sugar-formatter-tool.txt)** - 可逆フォーマッターの設計
- 双方向変換の保証
- ソースマップ2.0仕様
- VSCode統合計画
### 📚 参考資料
- **[compression-reference-libraries.md](compression-reference-libraries.md)** - 関連技術の調査
- 既存圧縮ツールの比較
- 学術研究の参照
- 実装のヒント
## 🚀 実装優先順位
1. **Week 1**: ANCP-Token-Specification-v1 に基づく基本実装
2. **Week 2**: 糖衣構文の統合
3. **Week 3**: Fusion層（F）の追加
4. **Week 4**: ツール・IDE統合
## 💡 重要な設計原則
- **完全可逆性**: P ↔ C ↔ F の変換で情報損失ゼロ
- **安全性優先**: 文字列・コメント内は変換しない
- **段階的導入**: まずCから、次にF層へ
- **AI最適化**: トークン削減率を最大化
---
最新の仕様については、ANCP-Token-Specification-v1.md を参照してください。

423
docs/private/roadmap/phases/phase-12.7/ancp-specs/ULTIMATE-AI-CODING-GUIDE.md Normal file
View File

@ -0,0 +1,423 @@
# 🚀 ULTIMATE AI CODING GUIDE for Nyash
## ANCP + 極限糖衣構文 = 最強のAI開発環境
> 8万行→2万行→1万行への挑戦！ANCPと極限糖衣構文の融合で実現する究極のコード圧縮
---
## 📊 圧縮レベル一覧
| レベル | 記法 | 圧縮率 | 用途 |
|-------|------|--------|------|
| L0: Standard | 通常のNyash | 0% | 人間が読み書き |
| L1: Sugar | 糖衣構文 | -40% | 開発時の標準 |
| L2: ANCP | AI記法 | -48% | AI通信用 |
| L3: Ultra | 極限糖衣 | -75% | コード圧縮 |
| L4: Fusion | ANCP+極限 | -90% | 最大圧縮 |
## 🎯 クイックスタート
### 統合マッピング表
```
# ANCP基本
$ = box # Box定義
n = new # インスタンス生成
m = me # 自己参照
l = local # ローカル変数
r = return # 戻り値
# 極限糖衣
$_ = 暗黙変数 # パイプライン引数
|> = パイプ # 関数連鎖
/: = map # リスト変換
\: = filter # フィルタリング
?. = null安全 # オプショナルチェイン
^ = return # 1文字リターン
```
## 💡 実例：5段階の圧縮
### L0: Standard Nyash（252文字）
```nyash
box WebServer from HttpBox {
init { port, routes, middleware }
birth(port) {
me.port = port
me.routes = new MapBox()
me.middleware = new ArrayBox()
}
use(fn) {
me.middleware.push(fn)
return me
}
route(path, handler) {
local wrapped = fn(req, res) {
for mw in me.middleware {
mw(req, res)
}
return handler(req, res)
}
me.routes.set(path, wrapped)
return me
}
}
```
### L1: Sugar（147文字、-42%）
```nyash
box WebServer from HttpBox {
port: IntegerBox
routes: MapBox = new MapBox()
middleware: ArrayBox = new ArrayBox()
birth(port) {
me.port = port
}
use(fn) {
me.middleware << fn
^ me
}
route(path, handler) {
l wrapped = fn(req, res) {
me.middleware !: { _(req, res) }
^ handler(req, res)
}
me.routes[path] = wrapped
^ me
}
}
```
### L2: ANCP（131文字、-48%）
```ancp
$WebServer@HttpBox{
#{port,routes,middleware}
b(port){
m.port=port
m.routes=n MapBox()
m.middleware=n ArrayBox()
}
use(fn){
m.middleware.push(fn)
r m
}
route(path,handler){
l wrapped=fn(req,res){
for mw in m.middleware{mw(req,res)}
r handler(req,res)
}
m.routes.set(path,wrapped)
r m
}
}
```
### L3: Ultra Sugar（89文字、-65%）
```ultra
$WebServer@HttpBox{
port;routes=@MapBox;middleware=@ArrayBox
birth(p){$.port=p}
use(f){$.middleware<<f;^$}
route(p,h){
$.routes[p]=fn{$2/:middleware|h($1,$2)}
^$
}
}
```
### L4: Fusion（52文字、-79%）
```fusion
$WS@H{p;r=@M;m=@A|b(p){$.p=p}u(f){$.m<<f^$}rt(p,h){$.r[p]=>{$2/:m|h}^$}}
```
## 🤖 AI別最適戦略
### Claude（Anthropic）- 200k tokens
```markdown
# 最大圧縮でコンテキスト3倍活用
;fusion:1.0;
全プロジェクトをL4で渡し、応答もL4で受け取る。
可逆フォーマッターで必要時展開。
推奨フロー:
1. nyash2fusion --all > project.fusion
2. Claudeに全体アーキテクチャ相談
3. fusion2nyash --level=1 response.fusion
```
### ChatGPT（OpenAI）- 128k tokens
```markdown
# バランス型：L2-L3を使い分け
コアロジック: L3 Ultra
周辺コード: L2 ANCP
新規生成: L1 Sugar（可読性重視）
```
### Gemini（Google）- 100k tokens
```markdown
# 深い考察にはL1-L2
「深く考えて」の指示にはSugar程度に留める。
複雑な推論には可読性が重要。
```
### Copilot - コンテキスト制限あり
```python
# .copilot/shortcuts.json
{
"patterns": {
"pipe": "input |> $_",
"map": "list /: {$_}",
"filter": "list \\: {$_}",
"safe": "obj?.$_"
}
}
```
## ⚡ 極限圧縮テクニック
### 1. 暗黙変数チェーン
```nyash
// Before（82文字）
local result = data.map(x => x.trim()).filter(x => x.length > 0).map(x => x.toUpper())
// After（31文字、-62%）
l r = data /: trim \: {$_.len>0} /: upper
```
### 2. パイプライン合成
```nyash
// Before（156文字）
fn processRequest(req) {
local validated = validate(req)
local authorized = checkAuth(validated)
local processed = handle(authorized)
return format(processed)
}
// After（44文字、-72%）
fn procReq = validate >> checkAuth >> handle >> format
```
### 3. null安全統一
```nyash
// Before（147文字）
if user != null {
if user.profile != null {
if user.profile.settings != null {
return user.profile.settings.theme
}
}
}
return "default"
// After（33文字、-78%）
^ user?.profile?.settings?.theme ?? "default"
```
### 4. パターンマッチング簡略化
```nyash
// Before（201文字）
peek ast {
BinaryOp(left, "+", right) => {
local l = compile(left)
local r = compile(right)
return l + " + " + r
}
UnaryOp("-", expr) => {
return "-" + compile(expr)
}
Literal(val) => {
return val.toString()
}
}
// After（89文字、-56%）
peek ast {
BinOp(l,"+",r) => compile(l)+"+"+compile(r)
UnOp("-",e) => "-"+compile(e)
Lit(v) => v+""
}
```
## 📈 実践的な圧縮フロー
### ステップ1: 標準コードを書く
```bash
# 通常のNyashで開発
vim src/feature.nyash
```
### ステップ2: 段階的圧縮
```bash
# L1: 糖衣構文適用
nyashfmt --sugar src/feature.nyash > feature.sugar.nyash
# L2: ANCP変換
nyash2ancp feature.sugar.nyash > feature.ancp
# L3: 極限糖衣
nyashfmt --ultra feature.ancp > feature.ultra.nyash
# L4: 最大圧縮
nyash2fusion feature.ultra.nyash > feature.fusion
```
### ステップ3: AIとの対話
```bash
# コンテキスト準備
cat *.fusion | clip
# AIプロンプト
"このfusionコードのバグを修正:
[貼り付け]
応答もfusion形式で。"
```
### ステップ4: 可逆展開
```bash
# AIの応答を展開
fusion2nyash --level=0 ai_response.fusion > fixed.nyash
# 差分確認
diff src/feature.nyash fixed.nyash
```
## 🛠️ ツールチェーン
### 統合CLIツール
```bash
# インストール
nyash install nyash-ultimate-formatter
# 使用例
nyuf compress --level=4 src/ # 最大圧縮
nyuf expand --level=1 code.fusion # Sugar形式へ展開
nyuf check code.fusion # 可逆性チェック
nyuf stats src/ # 圧縮統計表示
```
### VSCode拡張
```json
// settings.json
{
"nyash.ultimate": {
"defaultLevel": 1, // 通常はSugar
"aiCommunicationLevel": 4, // AI通信は最大圧縮
"showHoverExpansion": true, // ホバーで展開表示
"autoCompress": true // 保存時に圧縮版生成
}
}
```
### AI統合API
```nyash
// AI通信ラッパー
box AIClient {
level: IntegerBox = 4 // デフォルト圧縮レベル
ask(prompt, code) {
l compressed = Compressor.compress(code, me.level)
l response = me.ai.complete(prompt, compressed)
^ Compressor.expand(response, 1) // Sugarで返す
}
}
```
## 📊 圧縮効果の実測
### Nyashコンパイラ自体
| モジュール | 元サイズ | L1 Sugar | L2 ANCP | L3 Ultra | L4 Fusion |
|-----------|----------|----------|----------|-----------|-----------|
| Parser | 5,000行 | 3,000行 | 2,600行 | 1,500行 | 800行 |
| TypeChecker | 4,000行 | 2,400行 | 2,100行 | 1,200行 | 600行 |
| CodeGen | 3,000行 | 1,800行 | 1,600行 | 900行 | 500行 |
| **合計** | **80,000行** | **48,000行** | **42,000行** | **24,000行** | **12,000行** |
### トークン削減率（GPT-4換算）
```python
def measure_all_levels(original_code):
levels = {
"L0": original_code,
"L1": apply_sugar(original_code),
"L2": apply_ancp(original_code),
"L3": apply_ultra(original_code),
"L4": apply_fusion(original_code)
}
for level, code in levels.items():
tokens = count_tokens(code)
reduction = (1 - tokens / count_tokens(original_code)) * 100
print(f"{level}: {tokens} tokens ({reduction:.1f}% reduction)")
```
実測結果:
- L0: 40,000 tokens (0%)
- L1: 24,000 tokens (-40%)
- L2: 20,800 tokens (-48%)
- L3: 10,000 tokens (-75%)
- L4: 4,000 tokens (-90%)
## 🎓 学習パス
### 初級：L1 Sugar をマスター
1. パイプライン `|>`
2. 暗黙変数 `$_`
3. null安全 `?.`
4. 短縮return `^`
### 中級：L2 ANCP を活用
1. 基本マッピング（$, n, m, l, r）
2. コンパクト記法
3. AI通信への応用
### 上級：L3-L4 極限圧縮
1. HOF演算子（/:, \:, //）
2. 演算子セクション
3. 関数合成
4. 融合記法
## 🚨 注意事項
### DO ✅
- 開発は L0-L1 で行う
- AI通信は L2-L4 を使う
- 可逆性を常に確認
- チームで圧縮レベルを統一
### DON'T ❌
- 人間が L4 を直接編集
- 可逆性のない圧縮
- コメントまで圧縮
- デバッグ情報を削除
## 🔮 将来展望
### Phase 13: 圧縮記法の標準化
- ISO/IEC規格申請
- 他言語への展開
### Phase 14: AI専用最適化
- トークン予測を考慮した記法
- 意味保持圧縮アルゴリズム
### Phase 15: 量子的圧縮
- 重ね合わせ記法の研究
- 確率的コード表現
---
**Remember**: コードは書くより読む時間の方が長い。でもAIと話す時は違う。
極限まで圧縮して、より多くの文脈を共有しよう！
```fusion
// The Ultimate Nyash Philosophy
$Life{b(){p("Everything is Box, compressed to the limit!")}}
```

294
docs/private/roadmap/phases/phase-12.7/ancp-specs/chatgpt5-sugar-syntax-spec.md Normal file
View File

@ -0,0 +1,294 @@
# ChatGPT5糖衣構文仕様書
**Phase 12.7-B実装仕様（2025-09-04作成・更新）**
## 📋 概要
ChatGPT5アドバイザーから提案された糖衣構文を統合し、予約語を増やさずに表現力を劇的に向上させる。
## 🎯 設計原則
1. **予約語を増やさない** - 演算子・記号で実現
2. **可逆変換** - 糖衣構文⇔通常構文の完全な相互変換
3. **曖昧性ゼロ** - パース時の明確な優先順位
4. **MIR13への直接変換** - Phase 15セルフホスティングを意識
5. **使いたい人が使いたい構文を選択** - 強制ではなく選択
6. **超圧縮対応** - AIコンテキスト最大化のための極限記法
## 🔧 実装仕様
### 1. パイプライン演算子（|>）
**構文**
```ebnf
PipeExpr = Expr ( "|>" CallExpr )*
```
**変換規則**
```nyash
# 糖衣構文
x |> f |> g(y) |> h
# デシュガー後
h(g(f(x), y))
```
**MIR変換**
- 一時変数を使った直線的な命令列に変換
- 最適化で一時変数を削減
### 2. セーフアクセス（?.）とデフォルト値（??）
**構文**
```ebnf
SafeAccess = Primary ( ("?." | ".") Identifier )*
NullCoalesce = SafeAccess ( "??" SafeAccess )*
```
**変換規則**
```nyash
# 糖衣構文
user?.profile?.name ?? "Guest"
# デシュガー後
local t0, t1, t2
if user != null {
t0 = user.profile
if t0 != null {
t1 = t0.name
t2 = t1
} else {
t2 = "Guest"
}
} else {
t2 = "Guest"
}
```
### 3. デストラクチャリング
**構文**
```ebnf
DestructLet = "let" ( ObjectPattern | ArrayPattern ) "=" Expr
ObjectPattern = "{" Identifier ("," Identifier)* "}"
ArrayPattern = "[" Identifier ("," Identifier)* ("," "..." Identifier)? "]"
```
**変換規則**
```nyash
# オブジェクトパターン
let {x, y} = point
# →
local x = point.x
local y = point.y
# 配列パターン
let [a, b, ...rest] = array
# →
local a = array.get(0)
local b = array.get(1)
local rest = array.slice(2)
```
### 4. 増分代入演算子
**構文**
```ebnf
CompoundAssign = LValue ("+=" | "-=" | "*=" | "/=" | "%=") Expr
```
**変換規則**
```nyash
# 糖衣構文
count += 1
arr[i] *= 2
# デシュガー後
count = count + 1
arr.set(i, arr.get(i) * 2)
```
### 5. 範囲演算子（..）
**構文**
```ebnf
Range = Expr ".." Expr
```
**変換規則**
```nyash
# 糖衣構文
for i in 0..n {
print(i)
}
# デシュガー後
local _range = new RangeBox(0, n)
for i in _range {
print(i)
}
```
### 6. 高階関数演算子
**構文（3つの選択肢）**
```ebnf
# 演算子形式（超圧縮向け）
MapOp = Expr "/:" LambdaExpr
FilterOp = Expr "\:" LambdaExpr
ReduceOp = Expr "//" LambdaExpr
# メソッド形式（バランス型）
MapMethod = Expr ".map" "(" LambdaExpr ")"
FilterMethod = Expr ".filter" "(" LambdaExpr ")"
ReduceMethod = Expr ".reduce" "(" LambdaExpr ["," InitValue] ")"
```
**変換規則（すべて等価）**
```nyash
# 1. 明示的形式（学習・デバッグ向け）
evens = users.filter(function(u) { return u.age >= 18 })
.map(function(u) { return u.name })
# 2. 糖衣構文メソッド形式（通常開発向け）
evens = users.filter{$_.age >= 18}.map{$_.name}
# 3. 糖衣構文演算子形式（圧縮重視）
evens = users \: {$_.age>=18} /: {$_.name}
# 4. ANCP極限形式（AI協働向け）
e=u\:_.a>=18/:_.n
```
**暗黙変数**
- `$_` - 単一引数の暗黙変数
- `$1`, `$2` - 複数引数の位置指定
- 省略時の`_.`プロパティアクセス（ANCP）
### 7. ラベル付き引数
**構文**
```ebnf
LabeledArg = Identifier ":" Expr
Call = Identifier "(" (LabeledArg | Expr) ("," (LabeledArg | Expr))* ")"
```
**変換規則**
```nyash
# 糖衣構文
Http.request(
url: "/api",
method: "POST",
body: data
)
# デシュガー後
local _args = new MapBox()
_args.set("url", "/api")
_args.set("method", "POST")
_args.set("body", data)
Http.request(_args)
```
## 📊 優先順位表
| 優先度 | 演算子 | 結合性 |
|--------|--------|--------|
| 1 | `?.` | 左結合 |
| 2 | `??` | 左結合 |
| 3 | `\>` | 左結合 |
| 4 | `/:` `\:` `//` | 左結合 |
| 5 | `+=` `-=` etc | 右結合 |
| 6 | `..` | なし |
## 🔄 実装段階
### Stage 1: トークナイザー拡張
- 新しいトークンタイプの追加
- 演算子の最長一致ルール
### Stage 2: パーサー拡張
- 演算子優先順位の実装
- デシュガー変換の実装
### Stage 3: MIR変換
- 効率的なMIR命令列への変換
- 最適化パスの追加
### Stage 4: テスト・ドキュメント
- 包括的なテストケース
- エラーメッセージの改善
- チュートリアル作成
## 🎨 使い分けガイドライン
### 用途別推奨記法
```nyash
# 同じ処理の4段階表現
# 1. 学習用（超明示的）- 60文字
local result = []
for item in data {
if item.isValid() {
result.push(transform(normalize(item)))
}
}
# 2. 通常開発（メソッド糖衣）- 45文字
result = data.filter{$_.isValid()}
.map{$_ |> normalize |> transform}
# 3. 圧縮開発（演算子糖衣）- 35文字
result = data \: {$_.isValid()}
/: {$_ |> normalize |> transform}
# 4. AI協働（ANCP極限）- 20文字
r=d\:_.isValid()/:_|>n|>t
```
**最大67%のコード削減を実現！**
### 可逆変換の保証
```bash
# どの形式からでも相互変換可能
nyash format --from=explicit --to=sugar code.nyash
nyash format --from=sugar --to=ancp code.nyash
nyash format --from=ancp --to=explicit code.nyash
```
## 🚀 Phase 15との相乗効果
セルフホスティングコンパイラでの活用：
```nyash
box MirBuilder {
// 1. 明示的（デバッグ時）
buildExpr(ast) {
local desugared = me.desugar(ast)
local lowered = me.lower(desugared)
local checked = me.typeCheck(lowered)
return me.optimize(checked)
}
// 2. パイプライン糖衣（通常開発）
buildExpr(ast) {
return ast
|> me.desugar
|> me.lower
|> me.typeCheck
|> me.optimize
}
// 3. ANCP極限（AIとの共同作業）
buildExpr(a){r a|>m.desugar|>m.lower|>m.typeCheck|>m.optimize}
}
```
## 💡 重要な設計哲学
**「糖衣構文は使いたい人が使いたいものを選ぶ」**
- 強制ではなく選択
- プロジェクトごとに設定可能
- チームメンバーごとに表示形式を変更可能
- **重要なのは可逆変換できること**
これにより、Nyashは初心者からAI協働まで、あらゆるレベルの開発者に最適な記法を提供します。

157
docs/private/roadmap/phases/phase-12.7/ancp-specs/compression-reference-libraries.md Normal file
View File

@ -0,0 +1,157 @@
# 🔍 コード圧縮・変換ライブラリ参考資料
## Phase 12.7 極限糖衣構文の実装に向けた調査結果
---
## 🎯 発見：「AI専用言語」は実在する！
我々のL4 Fusion記法は、実は最先端の研究分野でした！
### 類似プロジェクト
#### 1. **Self-Optimizing AST Interpreters**
- **概念**: ASTを動的に最適化する専用DSL
- **特徴**: 入力に応じてAST構造自体を変更
- **Nyash関連性**: 我々のMIR最適化と同じアプローチ
#### 2. **Prometeo (Python-to-C)**
- **概念**: Python構文でC性能を実現
- **手法**: ASTレベル変換で異なる実行モデル
- **Nyash関連性**: Nyash→MIR→Native と同じ多段変換
#### 3. **Domain-Specific Compression Language**
- **概念**: 圧縮アルゴリズム専用の高レベル記法
- **効果**: 複雑なアルゴリズムを簡潔に表現
- **Nyash関連性**: ANCP記法の理論的裏付け
## 📊 既存ツールの圧縮性能
### JavaScript Minifiers (2025年最新)
| ツール | 圧縮率 | 速度 | 特徴 |
|--------|--------|------|------|
| Terser | 58% | 497ms | webpack標準 |
| SWC | 58% | 12ms | Rust実装・高速 |
| esbuild | 55% | 15ms | Go実装・超高速 |
| tdewolff/minify | 55% | 3ms | 最高速 |
**発見**: JavaScriptでも58%が限界！我々の90%は革命的！
### 実用的な参考実装
#### 1. **fflate** - 8KB高性能圧縮
```javascript
// 15%高速、60%向上の圧縮ライブラリ
import { compress, decompress } from 'fflate';
const compressed = compress(data); // 可逆圧縮
const original = decompress(compressed);
```
**学び**: 可逆性 + 高性能の両立は可能
#### 2. **Computational Law DSL**
```haskell
-- 自然言語 → AST → 中間表現 → ターゲット言語
natural4 → AST → CoreL4 → JavaScript/Prolog
```
**学び**: 多段変換パイプラインの実用例
## 🚀 Nyashの独自性
### 他にない特徴
#### 1. **5段階圧縮レベル**
```
L0 → L1 → L2 → L3 → L4
-40% -48% -75% -90%
```
既存ツール: 単一レベルのみ
**Nyash**: 用途別に選択可能！
#### 2. **意味保持圧縮**
既存ツール: 変数名をランダム化（意味喪失）
**Nyash**: 構造と意味を完全保持
#### 3. **AI最適化**
既存ツール: 人間の可読性重視
**Nyash**: AI理解性に特化
## 🔧 実装の参考ポイント
### 1. **多段変換パイプライン**
```rust
// Prometeo風の実装構造
struct TransformPipeline {
stages: Vec<Box<dyn Transform>>,
}
impl TransformPipeline {
fn transform(&self, input: AST) -> CompressedAST {
self.stages.iter().fold(input, |acc, stage| {
stage.apply(acc)
})
}
}
```
### 2. **可逆性保証**
```rust
// fflate風の往復テスト
#[test]
fn test_roundtrip() {
let original = "box WebServer { ... }";
let compressed = compress(original);
let restored = decompress(compressed);
assert_eq!(original, restored);
}
```
### 3. **パフォーマンス重視**
```rust
// SWC風の高速実装（Rust）
pub struct FastCompressor {
symbol_table: FxHashMap<String, String>, // FxHashMapで高速化
cache: LruCache<String, String>, // キャッシュで反復最適化
}
```
## 🎯 我々の実装方針
### 参考にすべき点
1. **SWC**: Rust実装の高速性
2. **Terser**: 成熟したJavaScript変換
3. **fflate**: 8KB軽量ライブラリ設計
4. **Prometeo**: 多段AST変換
### 独自路線を行く点
1. **意味保持**: 既存ツールは変数名破壊、我々は構造保持
2. **AI特化**: 人間向けでなくAI向け最適化
3. **多段階**: 5レベル選択式（他にない）
## 💡 結論
### 良いニュース
- **実装手法**: 多くの参考実装が存在
- **理論的裏付け**: 学術研究で有効性証明済み
- **技術的実現性**: Rustエコシステムで十分可能
### 我々の独創性
```fusion
// この圧縮率と可逆性の組み合わせは世界初！
$WS@H{p;r=@M;m=@A|b(p){$.p=p}...} // 90%圧縮
↕️ 完全可逆 ↕️
box WebServer from HttpBox { ... } // 100%復元
```
### 実装の現実性
**結論**: これ以上は確かに厳しいですが、**既存90%でも十分革命的**！
JavaScriptの限界が58%なのに、我々は90%達成。これは：
- **構造的圧縮**: 意味のある記号変換
- **言語設計**: Everything is Box の統一性
- **AI時代適応**: 新しい価値観（人間 < AI可読性）
の組み合わせによる奇跡ですにゃ！🎉
---
**最終判断**: 90%で十分。これ以上は学術実験レベル。実用性を重視しましょう！

302
docs/private/roadmap/phases/phase-12.7/ancp-specs/extreme-sugar-proposals.txt Normal file
View File

@ -0,0 +1,302 @@
================================================================================
Nyash 極限糖衣構文提案 - 二人の先生の知恵を結集
2025-09-03
================================================================================
【目標】
自己ホスティングコンパイラを8万行→2万行に圧縮（75%削減）
================================================================================
🎯 最優先実装（削減効果最大）
================================================================================
1. 暗黙変数 + パイプライン強化
================================================================================
【統一案】
- 暗黙変数: $_ （Perlスタイル）または単に _
- パイプライン最後引数自動注入
- プロパティ/メソッドアクセス短縮
// 現在（48文字）
local result = trim(uppercase(replace(input, "cat", "nyan")))
// 提案1: 暗黙変数（32文字、-33%）
local result = input |> replace(_, "cat", "nyan") |> uppercase() |> trim()
// 提案2: 最後引数自動（28文字、-42%）
local result = input |> replace("cat", "nyan") |> uppercase |> trim
// 提案3: プロパティアクセス（AST処理で威力発揮）
ast |> .left |> .value // ast.left.value と同じ
【実装コスト】
- パーサー: 最小限の変更
- 脱糖規則: x |> f(args) → f(args, x)
================================================================================
2. 高階関数専用演算子
================================================================================
【Gemini案 + Codex案の融合】
| 機能 | 演算子 | 例 | 削減率 |
|------|--------|---|---------|
| map | /: | list /: {$_*2} | -40% |
| filter | \: | list \: {$_>0} | -35% |
| reduce | // | nums // {$1+$2} | -45% |
// 現在（72文字）
local evens = list.filter(|x| x % 2 == 0).map(|x| x * x).reduce(|a,b| a + b)
// 提案（38文字、-47%）
local evens = list \: {$_%2==0} /: {$_*$_} // {$1+$2}
================================================================================
3. 演算子セクション（部分適用）
================================================================================
// 現在
list.map(|x| x + 1)
list.filter(|x| x > 0)
sorted_by(|a,b| a.key.cmp(b.key))
// 提案
list /: (+1)
list \: (>0)
sorted_by(by key) // byマクロ
【削減例】
- (+1) は |x| x+1 の短縮（-60%）
- (>0) は |x| x>0 の短縮（-55%）
================================================================================
4. 極短キーワードエイリアス
================================================================================
【必須短縮（1文字化）】
| 元 | 新 | 例 |
|----|----|----|
| local | l | l x = 42 |
| return | ^ | ^ result |
| function | fn | fn add(a,b) |
【頻出Box操作】
| 元 | 新 | 例 |
|----|----|----|
| new | @ | @ StringBox("hello") |
| me. | $ | $.count = $.count + 1 |
// 現在（128文字）
function calculate(x, y) {
local temp = x + y
local result = temp * 2
return result
}
// 提案（58文字、-55%）
fn calculate(x,y) {
l t = x+y
^ t*2
}
================================================================================
5. リスト内包 + 分割代入の統合
================================================================================
// 現在（複数行）
local names = new ArrayBox()
for user in users {
if user.active {
names.push(user.name)
}
}
// 提案1: 基本内包（27文字、-70%）
l names = [u.name for u in users if u.active]
// 提案2: 暗黙変数版（24文字、-75%）
l names = [$.name for users if $.active]
// 提案3: 分割代入併用
l [{name,age}] = users \: {$.age>18} // 18歳以上の名前と年齢
================================================================================
🚀 革新的提案（更なる短縮）
================================================================================
6. シジルモード（Gemini案）
================================================================================
【@モード: パイプライン特化】
@ input |> trim |> replace("a","b") |> upper
【$モード: プロパティチェーン】
$ user.profile.settings.theme.color
【効果】
- 特定文脈で暗黙ルール適用
- パーサーモード切り替えで実現
================================================================================
7. Unicode演算子（オプション）
================================================================================
| ASCII | Unicode | 意味 |
|-------|---------|------|
| -> | → | ラムダ |
| compose | ∘ | 関数合成 |
| in | ∈ | 所属判定 |
| != | ≠ | 不等号 |
// ASCIIフォールバック必須
l double = λx → x*2 // または x -> x*2
================================================================================
8. deriveマクロ（ボイラープレート削減）
================================================================================
// 現在（60-120行/ノード）
impl Visitor for AstNode {
fn visit_expr(&mut self, e: &Expr) {
match e {
Expr::Call(f, args) => {
self.visit_expr(f);
for a in args { self.visit_expr(a) }
}
// ... 各ケース実装
}
}
}
// 提案（1行、-99%）
derive visit for AstNode
================================================================================
9. peek式パターン強化
================================================================================
// 基本
peek ast {
BinaryOp(l,op,r) => compile(l) + op + compile(r)
UnaryOp(op,e) => op + compile(e)
Lit(v) => v
}
// ガード付き
peek n {
_ if _ > 0 => "positive"
_ if _ < 0 => "negative"
0 => "zero"
}
// 範囲
peek score {
0..60 => "F"
90..100 => "A"
}
================================================================================
10. 関数合成 + ポイントフリー
================================================================================
// 現在
fn process(x) {
return format(validate(parse(clean(x))))
}
// 提案1: 合成演算子
l process = clean >> parse >> validate >> format
// 提案2: 逆合成
l process = format ∘ validate ∘ parse ∘ clean
================================================================================
実装優先順位と削減見積もり
================================================================================
【Phase 12.7-A（即実装）】削減効果: -25%
1. 暗黙変数 $_
2. パイプライン強化（最後引数注入）
3. 高階関数演算子（/:, \:, //）
4. 1文字エイリアス（l, ^, fn）
【Phase 12.7-B（次段階）】削減効果: -20%
5. リスト内包 + 分割代入
6. 演算子セクション（部分適用）
7. deriveマクロ（visit, display, eq）
【Phase 12.7-C（将来）】削減効果: -10%
8. シジルモード
9. Unicode演算子
10. 関数合成演算子
================================================================================
具体例：コンパイラのコア部分
================================================================================
// 現在のコンパイラ（擬似コード、~200行）
fn compile(source: String) -> Result<ByteCode, Error> {
let tokens = match tokenize(source) {
Ok(t) => t,
Err(e) => return Err(e),
};
let ast = match parse(tokens) {
Ok(a) => a,
Err(e) => return Err(e),
};
let typed_ast = match type_check(ast) {
Ok(ta) => ta,
Err(e) => return Err(e),
};
let mir = match lower_to_mir(typed_ast) {
Ok(m) => m,
Err(e) => return Err(e),
};
let optimized = optimize(mir);
let bytecode = codegen(optimized);
Ok(bytecode)
}
// 極限短縮版（~10行、-95%）
fn compile(src) =
src |> tokenize
?. parse
?. type_check
?. lower_to_mir
/: optimize
/: codegen
// または関数合成版
l compile = tokenize >> parse >> type_check >> lower_to_mir >> optimize >> codegen
================================================================================
総合削減見積もり
================================================================================
【コンパイラ本体】
- パーサー: derive + 内包で -3000行
- 型検査: 暗黙変数 + HOF演算子で -2500行
- 最適化パス: 合成 + パイプで -2000行
- コード生成: テンプレート + マクロで -1500行
【標準ライブラリ】
- コレクション操作: -2000行
- エラー処理: -1000行
- ユーティリティ: -1000行
【合計】
現在: 80,000行
削減: -13,000行
目標: 67,000行 → さらなる削減が必要
【追加施策】
- ANCPとの併用で更に-40%
- 不要機能の削除
- アーキテクチャ簡素化
================================================================================

303
docs/private/roadmap/phases/phase-12.7/ancp-specs/sugar-formatter-tool.txt Normal file
View File

@ -0,0 +1,303 @@
================================================================================
Nyash 糖衣構文 可逆フォーマッター仕様
2025-09-03
================================================================================
【コンセプト】
極限短縮構文 ⇄ 標準構文の相互変換ツール（Nyashで実装）
================================================================================
1. 基本設計
================================================================================
box NyashFormatter {
mode: FormatterMode // Compact | Standard | Verbose
birth() {
me.mode = FormatterMode.Standard
}
// 短縮 → 標準への展開
expand(code: StringBox) -> StringBox {
code |> tokenize
|> expandSugar
|> format(me.mode)
|> toString
}
// 標準 → 短縮への圧縮
compact(code: StringBox) -> StringBox {
code |> tokenize
|> compactSugar
|> minify
|> toString
}
}
================================================================================
2. 変換規則マッピング
================================================================================
// 糖衣構文の変換ルールを定義
static box SugarRules {
// 暗黙変数の展開
expandImplicit(ast) {
peek ast {
ImplicitVar("$_") => {
// コンテキストから引数名を推論
local argName = inferArgumentName(ast.context)
Identifier(argName)
}
ImplicitVar("$1") => Identifier("_arg1")
ImplicitVar("$2") => Identifier("_arg2")
else => ast
}
}
// パイプラインの展開
expandPipeline(ast) {
peek ast {
Pipeline(expr, func) => {
// x |> f(a,b) → f(a, b, x)
peek func {
Call(name, args) => Call(name, [...args, expr])
PropertyAccess(prop) => PropertyAccess(expr, prop)
else => Call(func, [expr])
}
}
else => ast
}
}
// 短縮演算子の展開
expandOperators(ast) {
peek ast {
MapOp(list, expr) => {
// list /: expr → list.map(expr)
MethodCall(list, "map", [expandLambda(expr)])
}
FilterOp(list, expr) => {
// list \: expr → list.filter(expr)
MethodCall(list, "filter", [expandLambda(expr)])
}
else => ast
}
}
}
================================================================================
3. フォーマットモード
================================================================================
// 3段階の詳細度
enum FormatterMode {
Compact, // 極限短縮
Standard, // 標準的な記法
Verbose // 初心者向け詳細
}
// モード別の変換例
box FormatExamples {
showModes() {
local code = "[$.name for users if $.age > 18]"
print("=== Compact (極限) ===")
print(code)
print("=== Standard (標準) ===")
local standard = formatter.expand(code)
print(standard)
// [user.name for user in users if user.age > 18]
print("=== Verbose (詳細) ===")
local verbose = formatter.expandVerbose(code)
print(verbose)
// local result = new ArrayBox()
// for user in users {
// if user.age > 18 {
// result.push(user.name)
// }
// }
}
}
================================================================================
4. 実装例：主要な糖衣構文の変換
================================================================================
// 1. 暗黙変数
"list /: {$_*2}"
↓ expand
"list.map(fn(item) { return item * 2 })"
// 2. パイプライン
"input |> trim |> upper"
↓ expand
"upper(trim(input))"
// 3. null安全
"user?.profile?.name ?? 'Anonymous'"
↓ expand
"peek user {
null => 'Anonymous'
else => peek user.profile {
null => 'Anonymous'
else => peek user.profile.name {
null => 'Anonymous'
else => user.profile.name
}
}
}"
// 4. キーワード短縮
"l x = 42; ^ x*2"
↓ expand
"local x = 42
return x * 2"
// 5. 演算子セクション
"nums /: (+1)"
↓ expand
"nums.map(fn(x) { return x + 1 })"
// 6. リスト内包
"[x*x for x in nums if x%2==0]"
↓ expand (Standard)
"nums.filter(fn(x) { return x % 2 == 0 })
.map(fn(x) { return x * x })"
↓ expand (Verbose)
"local result = new ArrayBox()
for x in nums {
if x % 2 == 0 {
result.push(x * x)
}
}
result"
================================================================================
5. 使用例：コマンドラインツール
================================================================================
// nyashfmt.nyash - フォーマッターCLI
static box Main {
main(args) {
local formatter = new NyashFormatter()
local mode = args[1] ?? "standard"
local file = args[2]
peek mode {
"expand" => {
local code = FileBox.read(file)
local expanded = formatter.expand(code)
print(expanded)
}
"compact" => {
local code = FileBox.read(file)
local compacted = formatter.compact(code)
print(compacted)
}
"check" => {
// 可逆性チェック
local original = FileBox.read(file)
local round = original |> formatter.compact
|> formatter.expand
|> formatter.compact
if round == formatter.compact(original) {
print("✅ 可逆変換OK")
} else {
print("❌ 変換エラー：情報が失われています")
}
}
else => {
print("Usage: nyashfmt [expand|compact|check] <file>")
}
}
}
}
================================================================================
6. エディタ統合
================================================================================
// VSCode/エディタ向けのフォーマッター統合
box EditorFormatter {
// 選択範囲の展開/圧縮
formatSelection(text, mode) {
local formatter = new NyashFormatter()
peek mode {
"toggle" => {
// 自動判定：短縮記法が含まれていれば展開、なければ圧縮
if me.hasShortSyntax(text) {
formatter.expand(text)
} else {
formatter.compact(text)
}
}
"expand" => formatter.expand(text)
"compact" => formatter.compact(text)
else => text
}
}
// ホバー時のツールチップ表示
showExpanded(position) {
local ast = me.getAstAt(position)
local expanded = SugarRules.expandNode(ast)
// ツールチップに展開形を表示
return "展開形: " + expanded.toString()
}
}
================================================================================
7. 学習モード（初心者支援）
================================================================================
box LearningMode {
// 段階的に糖衣構文を導入
suggestSugar(code) {
local suggestions = new ArrayBox()
// パターンマッチで改善可能な箇所を検出
if code.contains("list.map(fn(x) { return") {
suggestions.push({
original: "list.map(fn(x) { return x * 2 })",
sugar: "list /: {$_*2}",
explanation: "/: は map の短縮記法です"
})
}
if code.contains("if x != null") {
suggestions.push({
original: "if x != null { x.method() } else { null }",
sugar: "x?.method()",
explanation: "?. でnullチェックを簡潔に"
})
}
return suggestions
}
}
================================================================================
8. 設定ファイル
================================================================================
// .nyashfmt.json - プロジェクト別設定
{
"mode": "standard",
"rules": {
"implicit_variable": true, // $_ を許可
"short_keywords": true, // l, ^, fn を許可
"unicode_operators": false, // λ, → は使わない
"pipeline": true, // |> を許可
"list_comprehension": true, // [...for...] を許可
"operator_sections": true // (+1) を許可
},
"expand_on_save": false, // 保存時に展開
"check_reversibility": true // 可逆性チェック
}
================================================================================

330
docs/private/roadmap/phases/phase-12.7/archive/ai-integration-guide.md Normal file
View File

@ -0,0 +1,330 @@
# AI Integration Guide for ANCP
## 🤖 AI開発者のためのANCP活用ガイド
### なぜANCPがAI開発を変えるのか
1. **コンテキスト容量2-3倍**: より多くのコードをAIに渡せる
2. **理解速度向上**: パターンが明確で認識しやすい
3. **生成効率向上**: 短い記号で素早くコード生成
## 📋 クイックリファレンス
### 最重要マッピング（必ず覚える）
```
$ = box # Box定義
n = new # インスタンス生成
m = me # 自己参照
l = local # ローカル変数
r = return # 戻り値
```
### よく使うパターン
```nyash
// Nyash
box Cat from Animal {
init { name }
birth(name) {
me.name = name
}
}
// ANCP
$Cat@Animal{
#{name}
b(name){m.name=name}
}
```
## 🎯 AI別最適化ガイド
### Claude (Anthropic)
```markdown
# Claudeへの指示例
NyashコードをANCP記法で書いてください。以下のマッピングを使用：
- box → $
- new → n
- me → m
- local → l
- return → r
コンテキスト: 200k tokens利用可能
推奨: 大規模プロジェクト全体をANCPで渡す
```
### ChatGPT (OpenAI)
```markdown
# ChatGPTへの指示例
Use ANCP notation for Nyash code:
;ancp:1.0 nyash:0.5;
Quick reference:
$ = box, n = new, m = me, l = local, r = return
Context: 128k tokens (GPT-4)
Strategy: Focus on core modules with ANCP
```
### Gemini (Google)
```markdown
# Geminiへの深い考察依頼
ANCPを使ったNyashコードの最適化を深く考えてください。
トークン効率とコード美しさのバランスを重視。
特に注目:
- $ (box) によるオブジェクト指向の簡潔表現
- m (me) による自己参照の明確化
```
### Codex/Copilot
```python
# .copilot/ancp_hints.py
"""
ANCP Quick Patterns:
- $ClassName{...} = box ClassName { ... }
- m.method() = me.method()
- l var = value = local var = value
- r value = return value
"""
```
## 💡 実践的な使い方
### 1. 大規模コードレビュー
```bash
# 全プロジェクトをANCPに変換してAIに渡す
nyash2ancp -i src/ -o /tmp/review.ancp --recursive
# AIへのプロンプト
"Review this ANCP code for performance issues:
[/tmp/review.ancp の内容]"
```
### 2. アーキテクチャ設計相談
```ancp
;ancp:1.0 nyash:0.5;
// 新しいP2Pシステムの設計
$P2PNetwork{
#{nodes,dht}
connect(peer){
l conn=n Connection(peer)
m.nodes.add(conn)
r conn
}
}
// AIへの質問
"この設計でスケーラビリティの問題はありますか？"
```
### 3. バグ修正依頼
```ancp
// バグのあるコード（ANCP）
$Calculator{
divide(a,b){
r a/b // ゼロ除算チェックなし
}
}
// AIへの依頼
"このANCPコードのバグを修正してください"
```
## 📊 効果測定
### トークン削減の実例
```python
# 測定スクリプト
import tiktoken
def measure_reduction(nyash_code, ancp_code):
enc = tiktoken.get_encoding("cl100k_base")
nyash_tokens = len(enc.encode(nyash_code))
ancp_tokens = len(enc.encode(ancp_code))
reduction = (1 - ancp_tokens / nyash_tokens) * 100
print(f"Nyash: {nyash_tokens} tokens")
print(f"ANCP: {ancp_tokens} tokens")
print(f"Reduction: {reduction:.1f}%")
return reduction
# 実例
nyash = """
box WebServer from HttpBox {
init { port, routes }
birth(port) {
me.port = port
me.routes = new MapBox()
}
addRoute(path, handler) {
me.routes.set(path, handler)
return me
}
}
"""
ancp = "$WebServer@HttpBox{#{port,routes}b(port){m.port=port m.routes=n MapBox()}addRoute(path,handler){m.routes.set(path,handler)r m}}"
reduction = measure_reduction(nyash, ancp)
# 結果: 約65%削減！
```
## 🔧 AIツール統合
### VSCode + GitHub Copilot
```json
// .vscode/settings.json
{
"github.copilot.advanced": {
"ancp.hints": {
"box": "$",
"new": "n",
"me": "m"
}
}
}
```
### Custom AI Integration
```typescript
// AI SDK統合例
class AncpAwareAI {
async complete(prompt: string, context: string): Promise<string> {
// コンテキストをANCPに変換
const ancpContext = this.transcoder.encode(context);
// AI APIコール（トークン数大幅削減）
const response = await this.ai.complete({
prompt,
context: ancpContext,
metadata: { format: "ancp:1.0" }
});
// レスポンスをNyashに戻す
return this.transcoder.decode(response);
}
}
```
## 📚 学習リソース
### AIモデル向けトレーニングデータ
```bash
# 並列コーパス生成
tools/generate_parallel_corpus.sh
# 出力
corpus/
├── nyash/ # 通常のNyashコード
├── ancp/ # 対応するANCPコード
└── metadata/ # トークン削減率等
```
### プロンプトテンプレート
```markdown
# 効果的なプロンプト例
## コード生成
"Write a P2P chat application in ANCP notation.
Requirements: [要件]
Use these patterns: $=box, n=new, m=me"
## コードレビュー
"Review this ANCP code for security issues:
```ancp
[コード]
```
Focus on: memory safety, race conditions"
## リファクタリング
"Refactor this ANCP code for better performance:
[コード]
Maintain the same API but optimize internals"
```
## 🚀 ベストプラクティス
### DO
- ✅ 大規模コードはANCPで渡す
- ✅ AI応答もANCPで受け取る
- ✅ 記号の意味を最初に説明
- ✅ バージョンヘッダーを含める
### DON'T
- ❌ 部分的なANCP使用（混乱の元）
- ❌ カスタム記号の追加
- ❌ コメントまで圧縮
## 🎮 実践演習
### 演習1: 基本変換
```nyash
// これをANCPに変換
box Calculator {
init { memory }
birth() {
me.memory = 0
}
add(x, y) {
local result = x + y
me.memory = result
return result
}
}
```
<details>
<summary>答え</summary>
```ancp
$Calculator{#{memory}b(){m.memory=0}add(x,y){l result=x+y m.memory=result r result}}
```
</details>
### 演習2: AI活用
```ancp
// このANCPコードの問題点をAIに聞く
$Server{listen(p){loop(true){l c=accept()process(c)}}}
```
期待する指摘:
- エラーハンドリングなし
- 接続の並行処理なし
- リソースリークの可能性
## 📈 成功事例
### 事例1: Nyashコンパイラ開発
- 通常: 20,000行 → 40,000 tokens
- ANCP: 20,000行 → 15,000 tokens
- **結果**: Claude一回のコンテキストで全体を把握！
### 事例2: バグ修正効率
- 従来: 関連コード5ファイルが入らない
- ANCP: 10ファイル＋テストコードまで含められる
- **結果**: AIが文脈を完全理解し、的確な修正提案
## 🔮 将来の展望
### ANCP v2.0
- AI専用の追加圧縮
- 意味保持型トークン削減
- カスタム辞書対応
### AI統合の深化
- IDEでのリアルタイムANCP変換
- AIレビューの自動ANCP化
- 学習済みANCPモデル
---
ANCPは単なる圧縮記法ではなく、AIとNyashをつなぐ架け橋です。
この革命的なプロトコルを活用して、AI時代の開発を加速させましょう！

96
docs/private/roadmap/phases/phase-12.7/archive/essential-features-consultation.txt Normal file
View File

@ -0,0 +1,96 @@
Nyash言語の必須機能について深い相談です（文法改革の続き）
【前回の合意事項】
- 予約語10個に削減
- セミコロン不要（改行区切り）
- フィールド宣言は name: Type 形式
- publicは先頭配置
【重要：忘れていた必須機能】
1. switch/case文（またはwhen文）
- if文地獄を避けるために絶対必要
- 以前Claude提案のwhen文も検討
- パターンマッチング機能は必要？
【例：現在のif文地獄】
if type == "dog" {
bark()
} else if type == "cat" {
meow()
} else if type == "bird" {
chirp()
} else {
silent()
}
【理想的な形は？】
when type {
"dog" => bark()
"cat" => meow()
"bird" => chirp()
else => silent()
}
または
switch type {
case "dog":
bark()
case "cat":
meow()
default:
silent()
}
【その他の必須機能候補】
1. continue文
- ループの次の反復へスキップ
- breakはあるのにcontinueがない
2. null/nil/void値
- 現在はVoidBoxだけ？
- もっと簡潔な表現が必要？
3. 型チェック機能
- value is StringBox のような？
- typeof演算子？
4. エラーハンドリング
- try/catch/finallyは予約語リストにあるが、本当に必要？
- Result型だけで十分？
5. モジュール/名前空間
- importはあるが、exportは？
- 名前空間の分離は？
6. その他検討事項
- yield（ジェネレータ）
- with文（リソース管理）
- defer文（遅延実行）
- assert文（デバッグ）
【質問】
1. switch/case vs when文、どちらがNyashに適している？
- 予約語数への影響は？
- Everything is Box哲学との整合性は？
2. 上記の機能候補の中で、本当に必須なものは？
- 予約語10個制限を守りつつ実現可能？
- 代替案はある？
3. Box型システムで解決できる機能は？
- 例：ResultBoxでエラーハンドリング
- 例：OptionBoxでnull安全性
4. 文法のシンプルさを保ちながら実用性を確保する方法は？
【理想】
- 予約語は最小限（できれば10個維持）
- Everything is Box哲学に忠実
- 実用的でif文地獄を避けられる
- 初学者にも分かりやすい
プログラミング言語設計の観点から、必須機能の優先順位と実装方法を提案してください。

301
docs/private/roadmap/phases/phase-12.7/archive/examples.md Normal file
View File

@ -0,0 +1,301 @@
# ANCP Examples - 実例で学ぶ圧縮記法
## 🎯 基本パターン
### 1. シンプルなBox定義
```nyash
// Nyash (31文字)
box Point {
init { x, y }
}
// ANCP (16文字) - 48%削減！
$Point{#{x,y}}
```
### 2. メソッド付きBox
```nyash
// Nyash (118文字)
box Calculator {
init { result }
birth() {
me.result = 0
}
add(x, y) {
me.result = x + y
return me.result
}
}
// ANCP (59文字) - 50%削減！
$Calculator{#{result}b(){m.result=0}add(x,y){m.result=x+y r m.result}}
```
### 3. 継承/デリゲーション
```nyash
// Nyash (165文字)
box Dog from Animal {
init { name, breed }
birth(name, breed) {
from Animal.init(name)
me.breed = breed
}
bark() {
return "Woof! I'm " + me.name
}
}
// ANCP (87文字) - 47%削減！
$Dog@Animal{#{name,breed}b(name,breed){@Animal.init(name)m.breed=breed}bark(){r"Woof! I'm"+m.name}}
```
## 🚀 実践的な例
### 4. P2Pノード実装
```nyash
// Nyash (287文字)
box P2PNode from NetworkBox {
init { id, peers, messages }
birth(id) {
me.id = id
me.peers = new ArrayBox()
me.messages = new MapBox()
}
connect(peer) {
me.peers.push(peer)
peer.addPeer(me)
return me
}
broadcast(msg) {
local i = 0
loop(i < me.peers.length()) {
me.peers.get(i).receive(msg)
i = i + 1
}
}
}
// ANCP (156文字) - 46%削減！
$P2PNode@NetworkBox{#{id,peers,messages}b(id){m.id=id m.peers=n ArrayBox()m.messages=n MapBox()}connect(peer){m.peers.push(peer)peer.addPeer(m)r m}broadcast(msg){l i=0 L(i<m.peers.length()){m.peers.get(i).receive(msg)i=i+1}}}
```
### 5. 非同期WebServer
```nyash
// Nyash (342文字)
box WebServer from HttpBox {
init { port, routes, middleware }
birth(port) {
from HttpBox.init(port)
me.routes = new MapBox()
me.middleware = new ArrayBox()
}
route(path, handler) {
me.routes.set(path, handler)
return me
}
use(middleware) {
me.middleware.push(middleware)
return me
}
async start() {
await from HttpBox.listen(me.port)
print("Server running on port " + me.port)
}
}
// ANCP (183文字) - 46%削減！
$WebServer@HttpBox{#{port,routes,middleware}b(port){@HttpBox.init(port)m.routes=n MapBox()m.middleware=n ArrayBox()}route(path,handler){m.routes.set(path,handler)r m}use(middleware){m.middleware.push(middleware)r m}async start(){await @HttpBox.listen(m.port)print("Server running on port"+m.port)}}
```
## 💡 高度なパターン
### 6. エラーハンドリング
```nyash
// Nyash (198文字)
box SafeCalculator {
divide(a, b) {
if b == 0 {
return new ErrorBox("Division by zero")
} else {
return new ResultBox(a / b)
}
}
}
// ANCP (93文字) - 53%削減！
$SafeCalculator{divide(a,b){?b==0{r n ErrorBox("Division by zero")}:{r n ResultBox(a/b)}}}
```
### 7. ジェネリック風パターン
```nyash
// Nyash (245文字)
box Container {
init { items, type }
birth(type) {
me.items = new ArrayBox()
me.type = type
}
add(item) {
if item.type() == me.type {
me.items.push(item)
return true
}
return false
}
}
// ANCP (124文字) - 49%削減！
$Container{#{items,type}b(type){m.items=n ArrayBox()m.type=type}add(item){?item.type()==m.type{m.items.push(item)r true}r false}}
```
## 🎮 完全なアプリケーション例
### 8. Todoアプリ（フル実装）
```nyash
// Nyash (562文字)
box TodoApp {
init { todos, nextId }
birth() {
me.todos = new ArrayBox()
me.nextId = 1
}
addTodo(text) {
local todo = new MapBox()
todo.set("id", me.nextId)
todo.set("text", text)
todo.set("done", false)
me.todos.push(todo)
me.nextId = me.nextId + 1
return todo.get("id")
}
toggleTodo(id) {
local i = 0
loop(i < me.todos.length()) {
local todo = me.todos.get(i)
if todo.get("id") == id {
todo.set("done", not todo.get("done"))
return true
}
i = i + 1
}
return false
}
listTodos() {
return me.todos
}
}
// ANCP (296文字) - 47%削減！
$TodoApp{#{todos,nextId}b(){m.todos=n ArrayBox()m.nextId=1}addTodo(text){l todo=n MapBox()todo.set("id",m.nextId)todo.set("text",text)todo.set("done",false)m.todos.push(todo)m.nextId=m.nextId+1 r todo.get("id")}toggleTodo(id){l i=0 L(i<m.todos.length()){l todo=m.todos.get(i)?todo.get("id")==id{todo.set("done",not todo.get("done"))r true}i=i+1}r false}listTodos(){r m.todos}}
```
## 📊 圧縮効果まとめ
| 例 | Nyash文字数 | ANCP文字数 | 削減率 |
|----|------------|-----------|--------|
| Point | 31 | 16 | 48% |
| Calculator | 118 | 59 | 50% |
| Dog | 165 | 87 | 47% |
| P2PNode | 287 | 156 | 46% |
| WebServer | 342 | 183 | 46% |
| SafeCalculator | 198 | 93 | 53% |
| Container | 245 | 124 | 49% |
| TodoApp | 562 | 296 | 47% |
**平均削減率: 48.3%**
## 🔍 パターン分析
### 最も効果的な変換
1. `return` → `r` (83%削減)
2. `local` → `l` (80%削減)
3. `new` → `n` (67%削減)
4. `box` → `$` (75%削減)
5. `me` → `m` (50%削減)
### 圧縮のコツ
- 空白を最小限に（セミコロン不要）
- 中括弧の直後に内容を書く
- 演算子の前後の空白を省略
- 文字列連結の空白も省略可能
## 🎯 練習問題
### 問題1
次のNyashコードをANCPに変換してください：
```nyash
box User {
init { name, email }
birth(name, email) {
me.name = name
me.email = email
}
toString() {
return me.name + " <" + me.email + ">"
}
}
```
<details>
<summary>答え</summary>
```ancp
$User{#{name,email}b(name,email){m.name=name m.email=email}toString(){r m.name+" <"+m.email+">"}}
```
</details>
### 問題2
次のANCPコードをNyashに戻してください：
```ancp
$Stack{#{items}b(){m.items=n ArrayBox()}push(item){m.items.push(item)}pop(){?m.items.length()>0{r m.items.pop()}r null}}
```
<details>
<summary>答え</summary>
```nyash
box Stack {
init { items }
birth() {
me.items = new ArrayBox()
}
push(item) {
me.items.push(item)
}
pop() {
if me.items.length() > 0 {
return me.items.pop()
}
return null
}
}
```
</details>
---
これらの例を参考に、ANCPを使いこなしてAI時代の効率的な開発を実現しましょう！

88
docs/private/roadmap/phases/phase-12.7/archive/grammar-fields-consultation.txt Normal file
View File

@ -0,0 +1,88 @@
Nyashプログラミング言語の文法改革について深い相談です。
【現在の検討状況】
1. 予約語を30個→10個に削減済み
- box, new, me, public, if, loop, break, return, import, from
2. コンストラクタ名
- 「birth」で統一（Everything is Box哲学を体現）
3. 変数宣言
- := 演算子は却下（localキーワードがあるため明示的）
- local x = 42 の形式を維持
4. デリゲーション
- fromキーワード維持（box Child from Parent）
- 親メソッド呼び出しは Parent::method()
5. フィールド可視性
- デフォルト非公開（privateキーワード削除）
- publicで明示的に公開
6. セミコロン
- 基本的に不要（Python風）
- 1行複数文の場合のみ使用可
【新たな提案：fields{}ブロック】
現在の書き方：
box Counter {
public { name, count }
private { cache }
birth() { }
}
提案されたfields{}ブロック：
box Counter {
fields {
IntegerBox count
public StringBox name
MapBox cache
}
birth(name) {
me.name = name
me.count = 0
}
}
【議論のポイント】
1. fields{}ブロック内だけセミコロンを使うと違和感がある
- 全体でセミコロンなしなのに、fieldsだけセミコロンは一貫性がない
2. 他の記法案：
- has{} ブロック（「箱が持つもの」）
- contains{} （「箱に含まれるもの」）
- inside{} （「箱の中身」）
【質問】
1. fields{}ブロック内のセミコロン問題をどう解決すべきか？
- セミコロンなしで統一？
- 改行で区切り？
- 別の区切り方？
2. フィールド宣言の最良の記法は？
- fields{} が最適か？
- 型名を先に書く（IntegerBox count）か後に書く（count: IntegerBox）か？
- publicの位置は？
3. Everything is Box哲学との整合性
- 「箱の中身を宣言する」という意味でfields{}は適切か？
- もっと箱らしい表現はあるか？
4. 全体の文法一貫性
- セミコロンなし統一でいくべきか？
- フィールド宣言だけ特別扱いすべきか？
【理想】
- 明示的（何が起きているか一目瞭然）
- 初学者フレンドリー
- Everything is Box哲学に忠実
- 書いていて楽しい文法
プログラミング言語設計の専門的視点から、深い分析と提案をお願いします。
時間制限なしでじっくり考えてください。

235
docs/private/roadmap/phases/phase-12.7/archive/grammar-reform-discussion.txt Normal file
View File

@ -0,0 +1,235 @@
================================================================================
Nyash文法改革 - 深い検討結果まとめ
2025-09-03
================================================================================
【検討参加者】
- Claude (私)
- Gemini先生
- Codex先生
- ユーザー（にゃ）
================================================================================
1. 現状の問題点
================================================================================
- 予約語が約30個と多すぎる
- CLAUDE.mdとLANGUAGE_REFERENCE_2025.mdで記述が矛盾
- CLAUDE.md: birth > pack > init > Box名形式
- LANGUAGE_REFERENCE_2025.md: init構文に統一
- 「Everything is Box」哲学に反する特殊ケースが多い
- 文法が複雑で初学者には分かりにくい
================================================================================
2. Gemini先生の提案
================================================================================
【核心的な提案】
1. birthコンストラクタ採用（Everything is Box哲学に最適）
2. 予約語10個に削減
3. デリゲーションは手動（fromキーワード廃止）→ しかしユーザーから問題指摘
4. 論理演算子は記号化（!, &&, ||）
5. エラーはResult Box（Ok/Err）で統一
【予約語リスト（Gemini案）】
- box, new, me, public, if, loop, break, return, let, import
【問題点】
- fromキーワードの重要な役割を見落としていた
1. デリゲーション宣言: box Child from Parent
2. 親メソッド呼び出し: from Parent.method()
================================================================================
3. Codex先生の革新的解決策
================================================================================
【fromキーワードの扱い】
- fromは残す（文脈的キーワードとして）
- 親メソッド呼び出しは :: 記法を使用
- Parent::method() ← 明確で美しい！
- 単一親の場合の糖衣構文: from method()
【変数宣言の革新】
- Go風の := 演算子を導入
- x := 10 // 新規宣言
- x = 20 // 既存変数への代入
- letはソフトキーワード（オプション）
- let x = 10 は x := 10 の糖衣構文
【その他の最適化】
- overrideを@override属性に変更（予約語削減）
- privateキーワード削除（デフォルト非公開）
================================================================================
4. 最終的な文法提案
================================================================================
【予約語（10個のみ！）】
1. box - Box定義
2. new - インスタンス生成
3. me - 自己参照
4. public - 公開指定（デフォルトは非公開）
5. if - 条件分岐
6. loop - ループ
7. break - ループ脱出
8. return - 戻り値
9. import - モジュール読み込み
10. from - デリゲーション宣言
【コンストラクタ】
- birthで統一（Everything is Box哲学を体現）
- packはビルトインBox継承専用（将来的に見直し可能）
【変数宣言】
x := 10 // 新規宣言（推奨）
let x = 10 // 新規宣言（糖衣構文）
x = 20 // 既存変数への代入
【デリゲーション】
box Child from Parent {
@override
public method() {
Parent::method() // 親メソッド呼び出し
// または
from method() // 単一親の場合の糖衣構文
}
}
【可視性】
box SecureBox {
// デフォルトで非公開
secret: str
internal_state: i64
// 明示的に公開
public id: str
// メソッドも同じ
process() { } // 非公開
public api() { } // 公開
}
【論理演算子】
- not → !
- and → &&
- or → ||
【エラーハンドリング】
- Result[T, E]型で統一
- Ok(value) / Err(error)
- ? 演算子でエラー伝播
================================================================================
5. 実装例
================================================================================
【基本的なBox定義】
box Calculator from BaseCalculator {
// フィールド（デフォルト非公開）
count := 0
cache: Map[str, f64]
// 公開フィールド
public name: str
// コンストラクタ
public birth(name) {
me.name = name
me.count = 0
me.cache = new Map[str, f64]()
}
// 公開メソッド
@override
public calculate(x, y) {
me.count = me.count + 1
// 親メソッド呼び出し
result := BaseCalculator::calculate(x, y)?
// キャッシュに保存
key := x + "," + y
me.cache.set(key, result)
return new Ok(result * 2)
}
// 非公開メソッド
clear_cache() {
me.cache.clear()
}
}
【使用例】
calc := new Calculator("MyCalc")
result := calc.calculate(10, 20)?
print(result) // 60
================================================================================
6. 移行ガイド
================================================================================
【予約語の変更】
- private → 削除（デフォルト非公開）
- var → 削除（:= または let を使用）
- static → 検討中
- interface → 検討中
- function → 削除（メソッドのみ）
- try/catch/throw → Result型 + ? 演算子
- true/false → 検討中（予約語から外す可能性）
- not/and/or → !/&&/||
【構文の変更】
- init() → birth()
- from Parent.method() → Parent::method()
- override → @override
- private field → field（デフォルト）
================================================================================
7. 未解決の課題
================================================================================
1. staticキーワードの扱い
- Static Box Mainパターンをどう表現するか
2. interfaceキーワードの扱い
- ダックタイピングで十分か？
- 構造的部分型で代替可能か？
3. true/falseの扱い
- 予約語から外してBoolBoxの定数にするか？
4. asyncの扱い
- Task[T]型 + .await()メソッドで十分か？
5. 型アノテーション
- : Type 形式で統一でOKか？
6. ジェネリクス
- Box[T, E] 形式で統一でOKか？
================================================================================
8. 次のステップ
================================================================================
1. この提案をベースに具体的な文法仕様書を作成
2. パーサーへの影響を評価
3. 既存コードの移行計画を立案
4. スモークテストの更新
5. ドキュメント（CLAUDE.md, LANGUAGE_REFERENCE_2025.md）の統一
================================================================================
9. 結論
================================================================================
予約語を10個に削減し、「Everything is Box」哲学を徹底することで、
シンプルで強力、かつ初学者にも分かりやすい言語を実現できる。
特に重要なのは：
- birthコンストラクタ（哲学の体現）
- fromキーワードの維持（実用性）
- := 演算子の導入（明確な宣言）
- デフォルト非公開（安全性）
- :: による親メソッド呼び出し（明確性）
これらにより、Nyashは本当に「世界一美しい箱」になる。

92
docs/private/roadmap/phases/phase-12.7/archive/grammar-reform-summary.txt Normal file
View File

@ -0,0 +1,92 @@
================================================================================
Nyash文法改革 - 実装向け要約
2025-09-03
================================================================================
【最重要決定事項】
1. 予約語は10個のみ
- box, new, me, public, if, loop, break, return, import, from
2. コンストラクタ名は「birth」で統一
- Everything is Box哲学を体現
- packはビルトインBox継承時のみ（将来廃止検討）
3. 変数宣言は := 演算子を導入
- x := 10 // 新規宣言
- x = 20 // 既存変数への代入
- let x = 10 // オプション（糖衣構文）
4. デリゲーションと親メソッド呼び出し
- box Child from Parent { } // fromは残す
- Parent::method() // 親メソッド呼び出し（推奨）
- from method() // 単一親の場合の糖衣構文
5. デフォルト非公開
- privateキーワード削除
- publicを付けたものだけ公開
================================================================================
【具体例】
================================================================================
box Counter from BaseCounter {
// フィールド（デフォルト非公開）
count := 0
// 公開フィールド
public name: str
// コンストラクタ（birthで統一）
public birth(name) {
me.name = name
BaseCounter::birth() // 親のbirth呼び出し
}
// メソッド（@overrideは属性）
@override
public increment() {
me.count = me.count + 1
BaseCounter::increment() // 親メソッド呼び出し
return me.count
}
}
// 使用
counter := new Counter("MyCounter")
counter.increment()
================================================================================
【移行チェックリスト】
================================================================================
□ init → birth に変更
□ private削除（デフォルト非公開）
□ var x = → x := に変更
□ from Parent.method() → Parent::method()
□ override → @override
□ and/or/not → &&/||/!
□ try/catch → Result型 + ?演算子
================================================================================
【パーサー実装への影響】
================================================================================
1. 予約語リストを10個に削減
2. := 演算子のサポート追加
3. :: 演算子の拡張（親メソッド呼び出し対応）
4. @属性のサポート追加
5. privateキーワードの削除
6. 文脈的from解釈の実装
================================================================================
【次のアクション】
================================================================================
1. LANGUAGE_REFERENCE_2025.mdの更新
2. CLAUDE.mdの更新（birthを最優先に）
3. パーサーの予約語リスト修正
4. テストケースの更新
5. 既存サンプルコードの移行
================================================================================

402
docs/private/roadmap/phases/phase-12.7/archive/implementation-plan.md Normal file
View File

@ -0,0 +1,402 @@
# ANCP Implementation Plan
## 🎯 実装戦略：段階的アプローチ
### 基本方針
1. **最小実装から開始**: 20語の固定辞書でMVP
2. **段階的拡張**: 機能を少しずつ追加
3. **早期統合**: スモークテストと早期に統合
4. **継続的検証**: 各段階で往復テスト実施
## 📅 Week 1: 基礎実装
### Day 1-2: プロジェクトセットアップ
```toml
# Cargo.toml に追加
[features]
ancp = []
[dependencies]
phf = "0.11" # 静的マップ用
tiktoken-rs = "0.5" # トークン計測用（optional）
```
### Day 3-4: 基本Transcoder実装
```rust
// src/ancp/mod.rs
pub mod transcoder;
pub mod mappings;
pub mod error;
// src/ancp/transcoder.rs
use phf::phf_map;
static NYASH_TO_ANCP: phf::Map<&'static str, &'static str> = phf_map! {
"box" => "$",
"new" => "n",
"me" => "m",
"local" => "l",
"return" => "r",
// ... 初期20語
};
pub struct BasicTranscoder;
impl BasicTranscoder {
pub fn encode(&self, input: &str) -> String {
let mut result = String::with_capacity(input.len());
let tokens = tokenize_simple(input);
for token in tokens {
match NYASH_TO_ANCP.get(token.text) {
Some(ancp) => result.push_str(ancp),
None => result.push_str(token.text),
}
result.push_str(&token.trailing_space);
}
result
}
}
```
### Day 5-7: 基本往復テスト
```rust
// tests/ancp_roundtrip.rs
#[test]
fn test_basic_roundtrip() {
let cases = vec![
"box Test { }",
"new StringBox()",
"me.field = 42",
"local x = 10",
"return result",
];
let transcoder = BasicTranscoder::new();
for case in cases {
let encoded = transcoder.encode(case);
let decoded = transcoder.decode(&encoded);
assert_eq!(case, decoded, "Failed for: {}", case);
}
}
```
## 📅 Week 2: スマート変換
### Day 8-9: コンテキスト認識パーサー
```rust
// src/ancp/context_parser.rs
pub struct ContextAwareTranscoder {
basic: BasicTranscoder,
}
impl ContextAwareTranscoder {
pub fn encode(&self, input: &str) -> String {
let mut result = String::new();
let mut in_string = false;
let mut in_comment = false;
// 文字列・コメント内は変換しない
for (i, ch) in input.chars().enumerate() {
match ch {
'"' if !in_comment => in_string = !in_string,
'/' if !in_string && peek_next(input, i) == Some('/') => {
in_comment = true;
},
'\n' => in_comment = false,
_ => {}
}
// コンテキストに応じて処理
if !in_string && !in_comment {
// トークン変換
} else {
// そのまま出力
}
}
result
}
}
```
### Day 10-11: Lexer統合
```rust
// src/parser/lexer.rs に追加
impl Lexer {
pub fn with_ancp_support(input: &str) -> Self {
if input.starts_with(";ancp:") {
// ANCPモードで初期化
Self::new_ancp_mode(input)
} else {
Self::new(input)
}
}
fn new_ancp_mode(input: &str) -> Self {
// ANCP → Nyash変換してからレキシング
let transcoder = get_transcoder();
let nyash_code = transcoder.decode(input).unwrap();
Self::new(&nyash_code)
}
}
```
### Day 12-14: エラー位置マッピング
```rust
// src/ancp/source_map.rs
pub struct SourceMap {
mappings: Vec<Mapping>,
}
impl SourceMap {
pub fn translate_position(&self, ancp_pos: Position) -> Position {
// ANCP位置 → Nyash位置への変換
self.mappings
.binary_search_by_key(&ancp_pos, |m| m.ancp_pos)
.map(|i| self.mappings[i].nyash_pos)
.unwrap_or(ancp_pos)
}
}
```
## 📅 Week 3: ツール実装
### Day 15-16: CLIツール
```rust
// src/bin/nyash2ancp.rs
use clap::Parser;
#[derive(Parser)]
struct Args {
#[clap(short, long)]
input: PathBuf,
#[clap(short, long)]
output: Option<PathBuf>,
#[clap(long)]
measure_tokens: bool,
}
fn main() -> Result<()> {
let args = Args::parse();
let content = fs::read_to_string(&args.input)?;
let transcoder = AncpTranscoder::new();
let encoded = transcoder.encode(&content)?;
if args.measure_tokens {
let reduction = measure_token_reduction(&content, &encoded);
eprintln!("Token reduction: {:.1}%", reduction * 100.0);
}
match args.output {
Some(path) => fs::write(path, encoded)?,
None => print!("{}", encoded),
}
Ok(())
}
```
### Day 17-18: スモークテスト統合
```bash
#!/bin/bash
# tools/test_ancp_roundtrip.sh
test_file=$1
expected_pattern=$2
# 1. 通常実行
normal_output=$(./target/release/nyash "$test_file" 2>&1)
# 2. ANCP変換
ancp_file="${test_file%.nyash}.ancp"
./target/release/nyash2ancp -i "$test_file" -o "$ancp_file"
# 3. ANCP実行
ancp_output=$(./target/release/nyash "$ancp_file" 2>&1)
# 4. 出力比較
if [ "$normal_output" != "$ancp_output" ]; then
echo "ERROR: Output mismatch for $test_file"
exit 1
fi
# 5. パターン検証（既存のスモークテスト方式）
echo "$ancp_output" | grep -q "$expected_pattern"
```
### Day 19-21: VSCode拡張（基礎）
```typescript
// vscode-extension/src/extension.ts
import * as vscode from 'vscode';
export function activate(context: vscode.ExtensionContext) {
// ホバープロバイダー
const hoverProvider = vscode.languages.registerHoverProvider(
'ancp',
{
provideHover(document, position) {
const word = document.getText(
document.getWordRangeAtPosition(position)
);
const original = ancpToNyash(word);
if (original !== word) {
return new vscode.Hover(
`ANCP: \`${word}\` → Nyash: \`${original}\``
);
}
}
}
);
context.subscriptions.push(hoverProvider);
}
```
## 📅 Week 4: 最適化と統合
### Day 22-23: tiktoken実測と最適化
```python
# tools/measure_ancp_efficiency.py
import tiktoken
import json
enc = tiktoken.get_encoding("cl100k_base")
def measure_file(nyash_path, ancp_path):
with open(nyash_path) as f:
nyash_code = f.read()
with open(ancp_path) as f:
ancp_code = f.read()
nyash_tokens = len(enc.encode(nyash_code))
ancp_tokens = len(enc.encode(ancp_code))
return {
"file": nyash_path,
"nyash_tokens": nyash_tokens,
"ancp_tokens": ancp_tokens,
"reduction": 1 - (ancp_tokens / nyash_tokens),
"nyash_chars": len(nyash_code),
"ancp_chars": len(ancp_code),
}
# 全サンプルファイルで測定
results = []
for nyash_file in glob.glob("examples/*.nyash"):
ancp_file = nyash_file.replace(".nyash", ".ancp")
results.append(measure_file(nyash_file, ancp_file))
# 統計出力
avg_reduction = sum(r["reduction"] for r in results) / len(results)
print(f"Average token reduction: {avg_reduction:.1%}")
```
### Day 24-25: CI/CD統合
```yaml
# .github/workflows/ancp.yml
name: ANCP Tests
on: [push, pull_request]
jobs:
ancp-roundtrip:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build with ANCP
run: cargo build --release --features ancp
- name: Run roundtrip tests
run: |
for f in examples/*.nyash; do
echo "Testing: $f"
./tools/test_ancp_roundtrip.sh "$f"
done
- name: Measure efficiency
run: |
python3 tools/measure_ancp_efficiency.py > ancp_report.json
- name: Upload report
uses: actions/upload-artifact@v3
with:
name: ancp-efficiency-report
path: ancp_report.json
```
### Day 26-28: ドキュメント・最終調整
- ユーザーガイド作成
- API ドキュメント生成
- パフォーマンスチューニング
- 最終テスト
## 🎯 成功指標
### Week 1終了時
- [ ] 基本20語で往復変換成功
- [ ] 単純なNyashプログラムが動作
### Week 2終了時
- [ ] コンテキスト認識変換
- [ ] Lexer統合完了
- [ ] エラー位置の正確なマッピング
### Week 3終了時
- [ ] CLI ツール完成
- [ ] スモークテスト統合
- [ ] VSCode基本機能
### Week 4終了時
- [ ] トークン削減率50%以上達成
- [ ] 全サンプルで往復テスト成功
- [ ] CI/CD完全統合
- [ ] ドキュメント完成
## 🚧 リスクと対策
### 技術的リスク
1. **パフォーマンス劣化**
- 対策: 段階的実装で早期発見
- 対策: プロファイリング継続実施
2. **互換性問題**
- 対策: 既存テストスイートで検証
- 対策: feature flagで段階的有効化
### 運用リスク
1. **採用障壁**
- 対策: 分かりやすいドキュメント
- 対策: 移行ツール提供
2. **メンテナンス負荷**
- 対策: 自動テスト充実
- 対策: CI/CDで品質保証
## 📝 チェックリスト
### 実装前
- [ ] tiktoken実測による記号選定完了
- [ ] 関係者への影響確認
- [ ] feature flag設計確認
### 実装中
- [ ] 日次で往復テスト実施
- [ ] パフォーマンス計測継続
- [ ] ドキュメント同時更新
### 実装後
- [ ] 全スモークテスト合格
- [ ] トークン削減率目標達成
- [ ] ユーザーガイド完成
---
この計画に従って実装を進めることで、4週間でANCPを完成させ、AIとの協働開発を革命的に改善します！

297
docs/private/roadmap/phases/phase-12.7/archive/powerful-syntax-sugar-proposals.txt Normal file
View File

@ -0,0 +1,297 @@
================================================================================
Nyash つよつよ糖衣構文提案 - 自己ホスティングに向けて
2025-09-03
================================================================================
【背景】
自己ホスティング（NyashでNyashコンパイラを書く）を実現するため、
コード量を劇的に削減できる強力な糖衣構文を検討する。
================================================================================
1. パイプライン演算子 |> （優先度：最高）
================================================================================
【現在の問題】
// ネストが深くて読みにくい
local result = trim(uppercase(replace(input, "cat", "nyan")))
【提案構文】
local result = input
|> replace($, "cat", "nyan")
|> uppercase($)
|> trim($)
// $ は前の結果を表す特殊変数
// または第一引数に自動挿入も可
local result = input
|> replace("cat", "nyan") // 第一引数に自動挿入
|> uppercase()
|> trim()
【効果】
- AST変換処理が非常に読みやすくなる
- 関数合成が直感的
- デバッグ時に中間結果を確認しやすい
================================================================================
2. 分割代入（Destructuring）（優先度：高）
================================================================================
【基本形】
// タプル分割
local (x, y, z) = getCoordinates()
// Box分割
local { name, age, email } = getUserInfo()
// 配列分割
local [first, second, ...rest] = items
【peek内での構造体パターン】
peek ast {
BinaryOp(left, op, right) => {
// left, op, right が自動的に変数として使える
compile(left) + compile(op) + compile(right)
}
UnaryOp(op, expr) => {
compile(op) + compile(expr)
}
Literal(value) => value.toString()
}
【効果】
- パーサー実装で威力発揮
- ASTノードの処理が簡潔に
- ボイラープレートコード削減
================================================================================
3. null安全演算子 ?. と ?? （優先度：高）
================================================================================
【?.（null安全アクセス）】
// 現在
local name
if user != null {
if user.profile != null {
if user.profile.name != null {
name = user.profile.name
}
}
}
// 提案
local name = user?.profile?.name
【??（null合体演算子）】
local displayName = user?.name ?? "Anonymous"
local port = config?.server?.port ?? 8080
【組み合わせ】
local result = getData()?.process()?.format() ?? "default"
【効果】
- null/undefinedエラーの防止
- 防御的プログラミングが簡潔に
- 設定値の読み込みで特に有用
================================================================================
4. 文字列テンプレート強化（優先度：高）
================================================================================
【基本テンプレート】
// 現在
local msg = "Error at line " + line + ", column " + col + ": " + error
// 提案
local msg = `Error at line ${line}, column ${col}: ${error}`
【複数行テンプレート】
local code = ```
fn ${name}(${params.join(", ")}) {
${body.indent(4)}
}
```
【タグ付きテンプレート（将来）】
local sql = SQL`SELECT * FROM users WHERE id = ${userId}`
local regex = RE`\d{3}-\d{4}` // エスケープ不要
【効果】
- コード生成が劇的に簡単に
- SQLやHTML生成で安全性向上
- 可読性の大幅改善
================================================================================
5. リスト内包表記（優先度：中）
================================================================================
【基本形】
// 現在
local result = new ArrayBox()
for item in list {
if item.isValid() {
result.push(item.process())
}
}
// 提案
local result = [item.process() for item in list if item.isValid()]
【ネスト】
local pairs = [(x, y) for x in xs for y in ys if x != y]
【辞書内包】
local map = {key: value.process() for (key, value) in entries}
【効果】
- 変換処理が1行で書ける
- 関数型プログラミングスタイル
- メモリ効率的な実装も可能
================================================================================
6. for式（値を返すfor）（優先度：中）
================================================================================
【基本形】
local tokens = for token in input yield parseToken(token)
【フィルタ付き】
local validTokens = for token in tokens if token.isValid() yield token
【変換付き】
local ast = for line in lines {
local trimmed = line.trim()
if trimmed.length() > 0 {
yield parseLine(trimmed)
}
}
【効果】
- リスト内包より複雑な処理に対応
- 中間変数を使える
- yieldで明示的
================================================================================
7. スプレッド演算子 ... （優先度：中）
================================================================================
【配列展開】
local combined = [...array1, ...array2, newItem]
local clone = [...original]
【Box展開】
local updated = { ...oldConfig, debug: true, port: 8080 }
【関数引数展開】
processItems(...args)
local max = Math.max(...numbers)
【効果】
- 配列・オブジェクト操作が簡潔
- イミュータブルな更新が簡単
- 可変長引数の処理
================================================================================
8. with文（リソース管理）（優先度：低）
================================================================================
【基本形】
with file = openFile("data.txt") {
local content = file.read()
process(content)
} // 自動的にfile.close()
【複数リソース】
with db = connectDB(), file = openLog() {
db.query("SELECT...")
file.write(result)
} // 両方自動クローズ
【効果】
- リソースリークの防止
- finally不要
- RAII的な管理
================================================================================
9. 関数合成演算子（優先度：低）
================================================================================
【合成 >>】
local processLine = trim >> lowercase >> tokenize
local result = processLine(input)
【部分適用】
local add5 = add(5, _)
local result = add5(10) // 15
【カリー化】
local multiply = fn(a)(b) => a * b
local double = multiply(2)
【効果】
- 関数型プログラミング支援
- 高階関数の活用
- コードの再利用性向上
================================================================================
10. 強力なpeekパターン拡張（優先度：中）
================================================================================
【ガード】
peek value {
n if n > 0 => "positive"
n if n < 0 => "negative"
0 => "zero"
}
【範囲】
peek score {
0..60 => "F"
60..70 => "D"
70..80 => "C"
80..90 => "B"
90..100 => "A"
}
【深いパターン】
peek ast {
If({ condition: BinaryOp(_, "==", _), then, else }) => {
optimizeEquality(condition, then, else)
}
}
【効果】
- より表現力豊かな分岐
- コンパイラ実装で必須
- コードの意図が明確
================================================================================
実装優先順位まとめ
================================================================================
【Phase 13（次フェーズ）】
1. パイプライン演算子 |>
2. 分割代入（基本形のみ）
3. null安全演算子 ?. と ??
4. 文字列テンプレート `${}`
【Phase 14】
5. リスト内包表記
6. for式
7. peekパターン拡張（ガード）
【Phase 15以降】
8. スプレッド演算子
9. with文
10. 関数合成演算子
================================================================================
実装時の注意点
================================================================================
1. 各糖衣構文は既存構文へのデシュガーとして実装
2. エラーメッセージは元の構文で表示
3. デバッガーでのステップ実行に配慮
4. 段階的に導入（基本形→拡張形）
================================================================================

293
docs/private/roadmap/phases/phase-12.7/archive/technical-spec.md Normal file
View File

@ -0,0 +1,293 @@
# ANCP Technical Specification v1.0
## 1. プロトコル概要
### 1.1 設計原則
- **可逆性**: 100%の双方向変換保証
- **効率性**: 50-70%のトークン削減
- **可読性**: 人間も慣れれば読み書き可能
- **拡張性**: バージョニングによる将来対応
### 1.2 プロトコルヘッダー
```
;ancp:1.0 nyash:0.5.0;
```
- `ancp:1.0`: ANCPプロトコルバージョン
- `nyash:0.5.0`: 対応Nyashバージョン
## 2. 記号マッピング仕様
### 2.1 予約語マッピング（優先度順）
#### Tier 1: 超高頻度（1文字）
| Nyash | ANCP | 頻度 | tiktoken削減 |
|-------|------|------|--------------|
| me | m | 極高 | 2→1 (50%) |
| new | n | 高 | 3→1 (67%) |
| return | r | 高 | 6→1 (83%) |
| local | l | 高 | 5→1 (80%) |
#### Tier 2: 高頻度（1文字特殊）
| Nyash | ANCP | 理由 |
|-------|------|------|
| box | $ | 金庫のメタファー |
| from | @ | 接続を表現 |
| init | # | 初期化のハッシュ |
| if | ? | 疑問・条件 |
| else | : | 条件の区切り |
#### Tier 3: 中頻度（1-2文字）
| Nyash | ANCP | 理由 |
|-------|------|------|
| static | S | 大文字で静的を表現 |
| loop | L | ループのL |
| birth | b | 誕生のb |
| override | O | 上書きのO |
| pack | p | パックのp |
### 2.2 演算子・記号の扱い
- 算術演算子（+, -, *, /）: そのまま
- 比較演算子（==, !=, <, >）: そのまま
- 論理演算子（and, or, not）: 検討中
- `and` → `&`
- `or` → `|`
- `not` → `!`
### 2.3 複合パターン
```nyash
// 元のコード
box Cat from Animal {
init { name, age }
}
// ANCP変換後
$Cat@Animal{#{name,age}}
```
## 3. パース規則
### 3.1 トークン境界
- 記号の前後に空白は不要（`$Cat`でOK）
- 識別子の区切りは既存ルール継承
- 文字列・コメント内は変換しない
### 3.2 優先順位
1. 文字列リテラル内: 変換なし
2. コメント内: 変換なし
3. 識別子の一部: 変換なし（`method_name`の`me`は変換しない）
4. 独立トークン: 変換対象
### 3.3 コンテキスト認識
```rust
enum TokenContext {
Normal, // 通常（変換対象）
StringLiteral, // 文字列内
Comment, // コメント内
Identifier, // 識別子の一部
}
```
## 4. 実装仕様
### 4.1 Transcoder API
```rust
pub trait AncpTranscoder {
// 基本変換
fn encode(&self, nyash: &str) -> Result<String, AncpError>;
fn decode(&self, ancp: &str) -> Result<String, AncpError>;
// ストリーミング変換
fn encode_stream(&self, input: impl Read) -> impl Read;
fn decode_stream(&self, input: impl Read) -> impl Read;
// 位置情報保持
fn encode_with_map(&self, nyash: &str) -> Result<(String, SourceMap), AncpError>;
fn decode_with_map(&self, ancp: &str) -> Result<(String, SourceMap), AncpError>;
}
```
### 4.2 SourceMap仕様
```rust
pub struct SourceMap {
mappings: Vec<Mapping>,
}
pub struct Mapping {
// 元の位置
original_line: u32,
original_column: u32,
original_token: String,
// 変換後の位置
generated_line: u32,
generated_column: u32,
generated_token: String,
}
```
### 4.3 エラーハンドリング
```rust
pub enum AncpError {
// 構文エラー
InvalidSyntax { position: Position, expected: String },
// バージョン非互換
VersionMismatch { required: Version, found: Version },
// 変換不可能
UnsupportedConstruct { construct: String, reason: String },
}
```
## 5. 統合仕様
### 5.1 Lexer統合
```rust
// Lexerに追加
pub enum InputDialect {
Nyash,
Ancp(Version),
}
impl Lexer {
pub fn new_with_dialect(input: &str, dialect: InputDialect) -> Self {
// ヘッダー検出で自動判定も可能
let dialect = detect_dialect(input).unwrap_or(dialect);
// ...
}
}
```
### 5.2 CLI統合
```bash
# 変換コマンド
nyash --to-ancp input.nyash > output.ancp
nyash --from-ancp input.ancp > output.nyash
# 直接実行
nyash --dialect=ancp script.ancp
# フォーマット表示
nyash --view=ancp script.nyash # Nyashファイルをancp形式で表示
nyash --view=hybrid script.ancp # 並列表示
```
### 5.3 VSCode統合
```typescript
// 言語サーバープロトコル拡張
interface AncpHoverInfo {
original: string; // Nyash形式
compressed: string; // ANCP形式
savings: number; // 削減率
}
// リアルタイム変換
interface AncpLens {
showOriginal: boolean;
showCompressed: boolean;
showSavings: boolean;
}
```
## 6. テスト仕様
### 6.1 往復テスト
```rust
#[test]
fn roundtrip_all_constructs() {
let test_cases = vec![
// 基本構造
"box Test { }",
"box Child from Parent { }",
// メソッド定義
"birth() { me.x = 1 }",
"override method() { from Parent.method() }",
// 制御構造
"if x == 1 { } else { }",
"loop(i < 10) { i = i + 1 }",
// 複雑な例
include_str!("../examples/complex.nyash"),
];
for case in test_cases {
let encoded = transcoder.encode(case).unwrap();
let decoded = transcoder.decode(&encoded).unwrap();
assert_eq!(case, decoded);
}
}
```
### 6.2 トークン効率テスト
```rust
#[test]
fn measure_token_reduction() {
let encoder = tiktoken::get_encoding("cl100k_base");
let original = "box Cat from Animal { init { name } }";
let ancp = "$Cat@Animal{#{name}}";
let original_tokens = encoder.encode(original).len();
let ancp_tokens = encoder.encode(ancp).len();
let reduction = 1.0 - (ancp_tokens as f64 / original_tokens as f64);
assert!(reduction >= 0.5); // 50%以上の削減を保証
}
```
### 6.3 エラー位置テスト
```rust
#[test]
fn error_position_mapping() {
let ancp = "$Test{invalid syntax here}";
let result = transcoder.decode_with_map(ancp);
match result {
Err(AncpError::InvalidSyntax { position, .. }) => {
// エラー位置が正しくマッピングされているか
assert_eq!(position.line, 1);
assert_eq!(position.column, 14);
}
_ => panic!("Expected syntax error"),
}
}
```
## 7. パフォーマンス目標
### 7.1 変換性能
- エンコード: 100MB/s以上
- デコード: 150MB/s以上
- メモリ使用: 入力サイズの2倍以内
### 7.2 実行時性能
- パース時間増加: 10%以内
- 実行時オーバーヘッド: なし（パース後は同一AST）
## 8. セキュリティ考慮事項
### 8.1 インジェクション対策
- ANCP記号が既存コードを破壊しないよう検証
- 文字列エスケープの適切な処理
### 8.2 バージョン互換性
- 古いANCPバージョンの適切なエラー表示
- 将来の拡張に備えた設計
## 9. 将来の拡張
### 9.1 ANCP v2.0候補
- 文脈依存圧縮（頻出パターンの動的割当）
- カスタム辞書サポート
- バイナリ形式（BANCTP）
### 9.2 AI特化拡張
- モデル別最適化プロファイル
- トークナイザー直接統合
- 意味保持圧縮
---
この仕様書は、ANCPの技術的実装の基準となる文書です。実装時はこの仕様に従い、必要に応じて更新してください。

65
docs/private/roadmap/phases/phase-12.7/archive/when-naming-fun-consultation.txt Normal file
View File

@ -0,0 +1,65 @@
Nyash言語の分岐構文の名前について、楽しくユニークな相談です！
【背景】
when構文でほぼ決定していますが、これは「ニャーの言語」なので、もっと楽しい名前も考えてみたい！
【現在の候補】
1. when（現在の最有力候補）
2. match（パターンマッチング的）
3. pick（選ぶ）
4. given（与えられたとき）
5. with（〜で）
6. upon（〜に基づいて）
7. take（取る）
8. test（テスト）
9. by（〜によって）
10. for（〜について）
【使用例】
```nyash
// 現在のwhen
when animal {
"dog" => bark()
"cat" => meow()
else => silent()
}
// もし別の名前なら？
??? animal {
"dog" => bark()
"cat" => meow()
else => silent()
}
```
【質問】
1. もっとユニークで楽しい名前の提案はありますか？
- Nyash（猫言語）らしさ
- Everything is Box哲学
- 短くて覚えやすい
- 楽しくてワクワクする
2. 各言語の面白い分岐構文名の例は？
- 変わった名前
- 独特な哲学を持つもの
- 歴史的に面白いもの
3. 名前から連想される「使い心地」は？
- whenだと「〜の時」
- pickだと「選ぶ」
- 他の名前だと？
4. 猫っぽい名前はある？
- paw（肉球）
- meow（鳴き声）
- hunt（狩り）
- など...
【理想】
- 楽しくて使うたびにワクワクする
- でも実用的で分かりやすい
- 短い（できれば3-4文字）
- 特に良い案がなければwhenでOK！
気楽に、楽しく、ユニークな提案をお聞かせください！
「こんなの思いついたにゃ〜」という感じで！

109
docs/private/roadmap/phases/phase-12.7/archive/when-syntax-deep-consultation.txt Normal file
View File

@ -0,0 +1,109 @@
Nyash言語のwhen構文と関数Box設計について深い相談です
【前回の議論からの進展】
1. when文採用でほぼ決定
- switch/caseより予約語が少ない
- 式としても使える
- パターンマッチングへの拡張性
2. => 構文の導入
- 現代的で見やすい
- 他言語（Rust, Kotlin, JS）でも採用
- 単一式とブロック両対応を検討中
3. returnキーワードは必須！
- 早期リターンに必要
- 明示性のため重要
- 式指向だけでは複雑になりすぎる
【新しい設計提案：fnによる関数Box】
通常のブロックと関数Boxを明示的に区別する案：
```nyash
// 通常のブロック（外側のスコープを共有）
when animal {
"dog" => {
me.count = me.count + 1 // 外側のBoxのme
local sound = "woof"
playSound(sound)
return sound // whenの値として返る
}
"cat" => meow() // 単一式もOK
else => silent()
}
// 関数Box（新しいスコープ、再帰可能）
when operation {
"factorial" => fn(n) {
if n <= 1 { return 1 }
return n * me(n - 1) // meは新しい関数Box自身！
}(5) // 即座に呼び出し
"counter" => fn() {
local count = 0
return {
increment: fn() { count = count + 1 },
get: fn() { return count }
}
}()
}
```
【質問事項】
1. when vs match
- whenという名前で良いか？
- matchの方が良い？
- 他の候補：check, on, select
2. => 構文の詳細設計
- 単一式：`"dog" => bark()`
- ブロック：`"dog" => { ... }`
- 関数Box：`"dog" => fn(args) { ... }`
- この3パターンで十分か？
3. fnキーワードの役割拡張
- 現在：関数定義のみ
- 提案：インライン関数Box作成にも使用
- 一貫性は保たれるか？
4. Everything is Box哲学との整合性
- {} だけでは通常のブロック（Boxではない）
- fn{} で関数Box
- この区別は哲学に反しないか？
5. 実装の観点
- MIR/VM/LLVMでの実装難易度
- 最適化の可能性
- デバッグのしやすさ
【設計原則の確認】
- 明示性：何が起きているか一目瞭然
- シンプルさ：初学者にも分かりやすい
- 表現力：実用的なプログラムが書ける
- 一貫性：言語全体で統一感がある
【予約語リスト（案）】
必須機能に必要な最小限：
1. box
2. new
3. me
4. public
5. if
6. else
7. loop
8. break
9. continue
10. when (またはmatch)
11. return
12. import
13. from
14. birth (コンストラクタ)
15. fn
予約語10個厳守ではなく、必要なものは追加する方針です。
プログラミング言語設計の観点から、この設計の妥当性と改善案をお聞かせください。

72
docs/private/roadmap/phases/phase-12.7/grammar-specs/README.md Normal file
View File

@ -0,0 +1,72 @@
# Nyash文法改革仕様書
このフォルダには、Phase 12.7で決定されたNyash文法改革の仕様書が含まれています。
## 📄 ドキュメント一覧
### 📝 最終決定事項
- **[grammar-reform-final-decision.txt](grammar-reform-final-decision.txt)** - 文法改革の最終決定
- 予約語15個への削減
- peek構文の導入
- birth統一コンストラクタ
- フィールド宣言の明示化
### 📐 技術仕様
- **[grammar-technical-spec.txt](grammar-technical-spec.txt)** - 詳細な技術仕様書
- 構文のBNF定義
- パーサー実装ガイド
- 後方互換性の考慮事項
## 🎯 文法改革の要点
### 15個の予約語
```
box, new, me, public, if, else, loop, break, continue,
peek, return, import, from, birth, fn
```
### 主要な変更点
#### 1. peek構文（switch/case代替）
```nyash
peek value {
"hello" => print("Hi!")
42 => print("The answer")
else => print("Other")
}
```
#### 2. birth統一（コンストラクタ）
```nyash
box Life {
init { name, energy }
birth(lifeName) { // すべてのBoxでbirth使用
me.name = lifeName
me.energy = 100
}
}
```
#### 3. fn{}でFunctionBox作成
```nyash
local add = fn{a, b => a + b}
```
#### 4. フィールド宣言の明示化
```nyash
box Person {
init { name, age } // フィールドを明示的に宣言
}
```
## 🔄 実装状況
- ✅ 仕様決定完了
- ✅ ChatGPT5による基本実装
- 🔄 テスト作成中
- 📅 完全移行（Phase 12.7-B）
---
詳細な実装については、implementation/フォルダを参照してください。

231
docs/private/roadmap/phases/phase-12.7/grammar-specs/grammar-reform-final-decision.txt Normal file
View File

@ -0,0 +1,231 @@
================================================================================
Nyash文法改革 - 最終決定事項（実装向け）
2025-09-03
================================================================================
【Phase 12.7: 文法改革の完全仕様】
================================================================================
1. 予約語リスト（最終版）
================================================================================
合計15個の予約語：
1. box - Box定義
2. new - インスタンス生成
3. me - 自己参照
4. public - 公開指定（デフォルトは非公開）
5. if - 条件分岐
6. else - else節
7. loop - ループ（唯一の形式）
8. break - ループ脱出
9. continue - 次の反復へスキップ
10. peek - 分岐構文（旧when）※※※新決定！※※※
11. return - 関数リターン
12. import - モジュール読み込み
13. from - デリゲーション/親メソッド呼び出し
14. birth - コンストラクタ（Everything is Box哲学）
15. fn - 関数定義/関数Box生成
================================================================================
2. peek構文（分岐構文）
================================================================================
【基本構文】
peek <expression> {
<pattern> => <expression-or-block>
<pattern> => <expression-or-block>
else => <expression-or-block> // else必須
}
【3つの形式】
// 単一式
peek animal {
"dog" => bark()
"cat" => meow()
else => silent()
}
// ブロック式（最後の式が値）
peek type {
"error" => {
log("Error occurred")
local message = getErrorMessage()
notifyAdmin(message)
message // これがpeekの値
}
else => "ok"
}
// 関数Box（新しいスコープ）
peek operation {
"factorial" => fn(n) {
if n <= 1 { return 1 }
return n * me(n - 1) // meは関数Box自身
}(5)
else => fn() { return 1 }()
}
【重要な仕様】
- peekは「式」（値を返す）
- else節は必須（非網羅エラーを防ぐ）
- returnはpeekではなく関数から脱出
- =>の右側は式、ブロック、関数Boxのいずれか
- パターンは当初「リテラルの等値比較」のみ
================================================================================
3. フィールド宣言（Box内）
================================================================================
【基本形式】
box ClassName {
// フィールド宣言（最上部に配置）
fieldName: TypeBox // デフォルト非公開
public fieldName: TypeBox // 公開フィールド
// コンストラクタ
birth(params) {
// 初期化処理
}
// メソッド
methodName(params) {
// 処理
}
}
【具体例】
box Counter {
count: IntegerBox
public name: StringBox
cache: MapBox = new MapBox() // デフォルト値も可能
birth(name) {
me.name = name
me.count = 0
// cacheは既に初期化済み
}
}
================================================================================
4. デリゲーション構文
================================================================================
box Child from Parent {
additionalField: StringBox
birth(name, extra) {
from Parent.birth(name) // 親のコンストラクタ呼び出し
me.additionalField = extra
}
// メソッドオーバーライド（@overrideは将来検討）
process() {
Parent::process() // 親メソッド呼び出し（::記法）
// または
from Parent.process() // 従来記法も可
}
}
================================================================================
5. fn（関数Box）の拡張
================================================================================
【用途】
1. トップレベル関数定義
2. インライン関数Box作成（クロージャ）
【例】
// 通常の関数定義
fn add(a, b) {
return a + b
}
// インライン関数Box
local counter = fn() {
local count = 0
return {
increment: fn() { count = count + 1 },
get: fn() { return count }
}
}()
// peek内での使用
peek operation {
"make_adder" => fn(x) {
return fn(y) { return x + y } // クロージャ
}
else => fn() { return null }
}
【重要】
- fn{} は新しいスコープ（関数Box）を作る
- {} だけは単なるブロック（スコープ共有）
- meの意味が変わる（関数Box内では関数自身）
================================================================================
6. その他の重要事項
================================================================================
【セミコロン】
- 基本的に不要（改行が文の区切り）
- 1行に複数文を書く場合のみ使用可
【変数宣言】
- local x = 42 // ローカル変数
- 未宣言変数への代入はエラー
【論理演算子】
- not, and, or を使用（!, &&, || は非推奨）
【型チェック】
- typeof()関数 + peek構文で実現
- 例: peek typeof(value) { "StringBox" => ... }
================================================================================
7. 実装優先順位
================================================================================
P0（即実装）:
1. パーサーにpeek構文追加
2. continue追加
3. フィールド宣言の name: Type 形式
4. birth統一
P1（次フェーズ）:
1. Parent::method() 記法
2. fn{} クロージャ完全実装
3. OptionBox/ResultBox標準化
P2（将来検討）:
1. パターンマッチング拡張
2. @override等の属性
3. 構文糖衣（nyan等のエイリアス）
================================================================================
8. パーサー実装への注意点
================================================================================
- peek <expr> { の識別
- => トークンの追加
- else必須チェック
- ブロックと関数Boxの区別（fnキーワードの有無）
- returnのスコープ（最も内側の関数から脱出）
================================================================================
9. MIR/VM/LLVM実装指針
================================================================================
【MIR】
- PeekExpr { scrutinee, arms: [(Pattern, Expr)], else_expr }
- Pattern は当初 Literal のみ
- 将来的に Pattern を拡張可能な設計に
【VM】
- 小規模: if-else連鎖
- 大規模: ジャンプテーブル最適化
【LLVM】
- 整数: switch命令
- 文字列: ハッシュテーブル or 二分探索
================================================================================

267
docs/private/roadmap/phases/phase-12.7/grammar-specs/grammar-technical-spec.txt Normal file
View File

@ -0,0 +1,267 @@
================================================================================
Nyash文法改革 - 技術仕様書（パーサー実装向け）
2025-09-03
================================================================================
1. トークン定義
================================================================================
【予約語（Keywords）】15個
- box, new, me, public, if, else, loop, break, continue
- peek, return, import, from, birth, fn
【演算子・記号（Operators/Symbols）】
- 算術: + - * / %
- 比較: == != < > <= >=
- 論理: and or not
- 代入: =
- アクセス: . (ドット) [ ] (インデックス)
- 関数: ( ) { }
- 区切り: , ;
- 型注釈: :
- peekアーム: =>
- 親メソッド: ::
- コメント: // /* */
【リテラル（Literals）】
- 整数: /[0-9]+/
- 浮動小数: /[0-9]+\.[0-9]+/
- 文字列: /"([^"\\]|\\.)*"/
- 真偽値: true false
- null値: null
【識別子（Identifier）】
- /[a-zA-Z_][a-zA-Z0-9_]*/
- 予約語と衝突しない
【空白・改行】
- 改行は文の区切り（セミコロン自動挿入規則適用）
- インデント: 意味を持たない（Python風ではない）
- 行継続: \ で明示的に次行へ続く
================================================================================
2. 式構文（Expression Grammar）
================================================================================
【優先順位（高→低）】
1. リテラル、識別子、(式)
2. 関数呼び出し: expr(args)
3. メンバアクセス: expr.member
4. インデックス: expr[index]
5. 単項演算: not expr, -expr
6. 乗除: * / %
7. 加減: + -
8. 比較: < > <= >= == !=
9. 論理積: and
10. 論理和: or
11. peek式: peek expr { ... }
【結合規則】
- 算術演算子: 左結合
- 比較演算子: 非結合（a < b < c は不可）
- 論理演算子: 左結合
【式の種類】
```
Expression ::=
| Literal
| Identifier
| "me"
| Expression "." Identifier // メンバアクセス
| Expression "[" Expression "]" // インデックス
| Expression "(" ExprList? ")" // 関数呼び出し
| "new" Identifier "(" ExprList? ")" // インスタンス生成
| "fn" "(" ParamList? ")" Block // 関数Box
| PeekExpression
| BinaryOp
| UnaryOp
| "(" Expression ")"
```
【peek式】
```
PeekExpression ::=
"peek" Expression "{"
PeekArm*
"else" "=>" (Expression | Block)
"}"
PeekArm ::=
Pattern "=>" (Expression | Block)
Pattern ::=
| Literal // 現在はリテラルのみ
| Pattern "|" Pattern // 将来: 複数パターン
```
================================================================================
3. 文構文（Statement Grammar）
================================================================================
```
Statement ::=
| Expression // 式文
| "local" IdentList ("=" ExprList)? // 変数宣言
| Identifier "=" Expression // 代入
| "if" Expression Block ("else" (Block | Statement))?
| "loop" "(" Expression ")" Block
| "break"
| "continue"
| "return" Expression?
| BoxDeclaration
| FunctionDeclaration
| "import" StringLiteral ("as" Identifier)?
Block ::= "{" Statement* "}"
BoxDeclaration ::=
"box" Identifier ("from" IdentList)? "{"
FieldDeclaration*
MethodDeclaration*
"}"
FieldDeclaration ::=
("public")? Identifier ":" Identifier ("=" Expression)?
MethodDeclaration ::=
("public")? (Identifier | "birth") "(" ParamList? ")" Block
```
================================================================================
4. 名前解決規則
================================================================================
【スコープ】
1. グローバルスコープ（box、関数定義）
2. Box内スコープ（フィールド、メソッド）
3. 関数スコープ（引数、local変数）
4. ブロックスコープ（{}内のlocal）
【シャドーイング】
- 内側のスコープが外側を隠蔽
- 同一スコープ内での再定義は不可
【meの解決】
- Box内: 現在のBoxインスタンス
- fn{}内: 関数Box自身
- それ以外: エラー
【from Parent.method()の解決】
- 現在のBoxがParentにデリゲートしているか確認
- Parent::method()も同様
================================================================================
5. 曖昧性と解決策
================================================================================
【左再帰なし】
- 全て右再帰または反復で記述
【最長一致】
- トークナイザーレベルで最長一致
- 例: ">=" は2文字演算子として認識
【バックトラック不要】
- LL(1)またはLL(2)で解析可能
- peekトークンで次の構文要素を判別
【曖昧箇所】
1. 関数呼び出し vs 変数
- 解決: "("の有無で判別
2. {} がブロックか関数Boxか
- 解決: 直前のfnキーワードで判別
3. セミコロン自動挿入
- 改行時に次が中置演算子でない場合挿入
- 例外: 行末が不完全な式の場合は挿入しない
================================================================================
6. エラー処理
================================================================================
【期待トークンエラー】
```
Expected 'token' but found 'actual'
at line X, column Y
```
【回復戦略】
1. 文レベル: 次の文開始トークンまでスキップ
2. ブロックレベル: 対応する}までスキップ
3. Box/関数レベル: 次のbox/fnまでスキップ
【行・列の追跡】
- 各トークンに位置情報を付与
- エラー時は該当箇所を表示
【エラーメッセージ例】
```
Error: Missing 'else' in peek expression
--> program.nyash:10:5
|
10 | peek value {
| ^^^^ peek expression requires 'else' branch
```
================================================================================
7. 将来拡張の余地
================================================================================
【予約済み位置】
- @ 記号: 将来の属性用
- # 記号: 将来のマクロ用
- ` 記号: 将来のテンプレート用
【拡張可能な構文】
- Pattern: 現在はリテラルのみ、将来は構造体パターン等
- 型注釈: 現在は : Type のみ、将来はジェネリクス等
【前方互換性】
- 未知の @ で始まる行は読み飛ばし
- box内の未知セクションは警告のみ
================================================================================
8. 既存実装への差分最小化
================================================================================
【tokenizer.rs への変更】
1. 予約語リストにpeek, continue, birthを追加
2. => を2文字演算子として追加
3. :: を2文字演算子として追加
【parser.rs への変更】
1. parse_when() → parse_peek() に改名
2. parse_field_declaration() を追加（name: Type形式）
3. parse_fn_literal() を追加（fn式のため）
4. continue文の処理追加
5. birthキーワードの特殊処理
【AST変更】
```rust
// 追加
enum Expr {
// ...
Peek {
scrutinee: Box<Expr>,
arms: Vec<(Pattern, BlockOrExpr)>,
else_arm: Box<BlockOrExpr>,
},
FnLiteral {
params: Vec<String>,
body: Block,
},
}
enum Stmt {
// ...
Continue,
}
```
【セマンティクス】
- peekは式として値を返す
- else必須のバリデーション追加
- returnは最内関数スコープから脱出
================================================================================

153
docs/private/roadmap/phases/phase-12.7/implementation/ANCP-IMPLEMENTATION-PLAN.md Normal file
View File

@ -0,0 +1,153 @@
# ANCP実装計画 - 統合ドキュメント
Date: 2025-09-03
Status: Implementation Ready
## 🎯 概要
ANCP (AI-Nyash Compact Notation Protocol) - 90%可逆圧縮技法の実装計画。
3人のAIアドバイザー（ChatGPT5、Claude、Gemini）の知見を統合。
## 📊 三者の評価まとめ
| アドバイザー | 評価 | 重要アドバイス |
|-------------|------|----------------|
| ChatGPT5 | 全面支持・即実行推奨 | 段階導入・ガードレール・事故防止 |
| Claude | 革命的発明 | 実装順序・技術チェックリスト |
| Gemini | パラダイムシフト | IDE統合・段階的導入・学術価値 |
| Codex | 技術的厳密性重視 | AST正規化・トークン最適化・検証 |
## 🚀 統合実装計画（4週間）
### Week 1: 最小実装（P↔C）
**ChatGPT5案 + Codex技術仕様**
```bash
# 実装内容
- 固定辞書20語（ASCII記号マッピング）
- トークンベース変換（正規表現不使用）
- AST正規化（P*）ルール確立
- nyashc CLI基本実装
```
**成果物**：
- [ ] BNF/EBNF仕様書
- [ ] 最小エンコーダー/デコーダー
- [ ] ラウンドトリップテスト
- [ ] sourcemap.json生成
### Week 2: スマート化
**Gemini提案 + ChatGPT5安全策**
```bash
# 機能追加
- 文字列/コメント保護
- セミコロン自動挿入
- プロジェクト辞書（.ancprc）
- エラー位置逆引き
```
**成果物**：
- [ ] 非変換ゾーン認識
- [ ] 衝突検出メカニズム
- [ ] LLMパック機能
- [ ] デバッグ体験改善
### Week 3: F層導入（読み込み専用）
**Codex仕様 + ChatGPT5段階導入**
```bash
# F層実装
- 入力専用モード
- MIR直行デコーダー
- 等価性検証（MIRハッシュ）
- 文法圧縮（Re-Pair/Sequitur）
```
**成果物**：
- [ ] F層パーサー
- [ ] MIR等価性テスト
- [ ] 圧縮率90%達成
- [ ] Property-based testing
### Week 4: ツール・統合
**Gemini IDE統合 + Codex CLI設計**
```bash
# 開発ツール
- VS Code拡張（ホバー表示）
- フォーマッター統合
- ベンチマーク自動化
- CI/CD統合
```
**成果物**：
- [ ] VS Code拡張α版
- [ ] nyash fmt統合
- [ ] ベンチマークCSV
- [ ] ドキュメント完成
## ⚠️ 設計原則（赤線）
### ChatGPT5の三原則
1. **常にPを正典** - C/Fは生成物
2. **トークン変換で可逆** - 正規表現は使わない
3. **Fはまず入力専用** - 段階的に拡張
### Codexの技術要件
1. **AST正規化必須** - P*の厳密定義
2. **トークン最適化** - GPT/Claude向け
3. **MIR等価性証明** - ハッシュ一致
### Geminiの実用要件
1. **IDE統合最優先** - 開発体験重視
2. **段階的導入** - fusion{}ブロック
3. **意味論的圧縮** - 将来への道筋
## 📈 測定指標（KPI）
| 指標 | 目標 | 測定方法 |
|------|------|----------|
| 圧縮率 | 90% | トークン数比較 |
| 可逆性 | 100% | ラウンドトリップテスト |
| MIR等価 | 100% | ハッシュ一致率 |
| 変換速度 | <100ms/1000行 | ベンチマーク |
| LLM効率 | 2-3倍 | コンテキスト拡張率 |
## 🛠️ 実装優先順位
### 今すぐ（Day 1-3）
1. BNF/EBNF仕様書作成
2. 20語辞書決定
3. 最小プロトタイプ
### 第1週（Day 4-7）
1. トークナイザー拡張
2. 基本CLI実装
3. CIテスト準備
### 第2週以降
- Week 2-4の計画通り実行
## 📚 関連ドキュメント
### 設計・仕様
- [grammar-reform-final-decision.txt](archive/grammar-reform-final-decision.txt)
- [extreme-sugar-proposals.txt](extreme-sugar-proposals.txt)
- [ULTIMATE-AI-CODING-GUIDE.md](ULTIMATE-AI-CODING-GUIDE.md)
### AIフィードバック
- [ChatGPT5実装アドバイス](ai-feedback/chatgpt5-ancp-implementation-advice.md)
- [Claude技術分析](ai-feedback/codex-ancp-response.md)
- [Gemini革命的評価](ai-feedback/gemini-ancp-response.md)
### 実装ガイド
- [即座実装ガイド](ai-feedback/quick-implementation-guide.md)
- [技術チェックリスト](ai-feedback/technical-checklist.md)
- [実用的洞察](ai-feedback/actionable-insights.md)
## 🎉 結論
**全AIアドバイザーが「今すぐやるべき」と評価！**
ChatGPT5の事故防止ガードレール、Codexの技術的厳密性、Geminiの実用性を統合し、**4週間で90%圧縮を実現**する。
---
**次のアクション**: BNF/EBNF仕様書作成開始！

68
docs/private/roadmap/phases/phase-12.7/implementation/README.md Normal file
View File

@ -0,0 +1,68 @@
# 実装ガイド・計画
このフォルダには、Phase 12.7の実装に関する計画とチェックリストが含まれています。
## 📄 ドキュメント一覧
### 🚀 実装計画
- **[ANCP-IMPLEMENTATION-PLAN.md](ANCP-IMPLEMENTATION-PLAN.md)** - 統合実装計画
- 4週間の段階的実装スケジュール
- 全AIアドバイザーの知見を統合
- KPI（測定指標）の定義
- リスクと対策
### 🔧 チェックリスト
- **[implementation-final-checklist.txt](implementation-final-checklist.txt)** - 実装チェックリスト
- 文法改革の実装項目
- ANCP実装の必須タスク
- テスト・検証項目
- ツール統合タスク
## 📅 実装スケジュール概要
### Week 1: 基礎実装（P↔C）
- [ ] BNF/EBNF仕様書完成
- [ ] 20語の固定辞書実装
- [ ] トークンベース変換器
- [ ] 基本的なCLI（nyashc）
- [ ] ラウンドトリップテスト
### Week 2: スマート化
- [ ] 文字列・コメント保護
- [ ] セミコロン自動挿入
- [ ] プロジェクト辞書（.ancprc）
- [ ] エラー位置逆引き
- [ ] LLMパック機能
### Week 3: F層導入
- [ ] Fusion層パーサー（読み込み専用）
- [ ] MIR直行デコーダー
- [ ] 等価性検証（MIRハッシュ）
- [ ] 90%圧縮達成
- [ ] Property-based testing
### Week 4: ツール統合
- [ ] VS Code拡張（ホバー表示）
- [ ] フォーマッター統合
- [ ] ベンチマーク自動化
- [ ] CI/CD統合
- [ ] ドキュメント完成
## 🎯 次のアクション
1. **ANCP-Token-Specification-v1.md** に基づくトークナイザー実装
2. テストケース（OK/NG 30本）の作成
3. 最小プロトタイプの開発開始
## 📊 成功指標
| 指標 | 目標値 | 測定方法 |
|------|--------|----------|
| 圧縮率 | 90% | トークン数比較 |
| 可逆性 | 100% | ラウンドトリップテスト |
| MIR等価 | 100% | ハッシュ一致率 |
| 変換速度 | <100ms/1000行 | ベンチマーク |
---
実装を開始する前に、必ずANCP-IMPLEMENTATION-PLAN.mdを熟読してください。

259
docs/private/roadmap/phases/phase-12.7/implementation/implementation-final-checklist.txt Normal file
View File

@ -0,0 +1,259 @@
================================================================================
Phase 12.7 文法改革 - 実装前最終チェックリスト
2025-09-03
================================================================================
【ChatGPT5さんからの重要指摘への対応】
================================================================================
1. トークナイザー実装の注意点
================================================================================
【既存の問題】
- 現在のARROWトークンが '>>' になっている → これを修正！
【対応】
```rust
// tokenizer.rs での修正
// 削除または未使用化
// ARROW => ">>" // これは間違い！
// 新規追加
FAT_ARROW => "=>" // peek構文用
DOUBLE_COLON => "::" // Parent::method用（P1だがトークンは今追加）
```
【追加する予約語（P0）】
- peek
- continue
- birth
（publicは後述の特殊対応）
================================================================================
2. 値の扱いの明確化
================================================================================
【空ブロックの値】
- 空ブロック {} の値は **VoidBox** とする
- 最後の式がない場合もVoidBox
【peek式の値規約】
```nyash
// 単一式の値
peek x {
1 => "one" // StringBoxを返す
else => "other"
}
// ブロックの値（最後の式）
peek x {
1 => {
print("got one")
"one" // これが値
}
else => {
// 空ブロックはVoidBox
}
}
// 関数Boxの値（P0では単純に関数オブジェクト）
peek op {
"add" => fn(a, b) { return a + b } // 関数Boxを返す
else => fn() { return 0 }
}
```
================================================================================
3. 等値比較の詳細規約
================================================================================
【peek内のパターンマッチング（P0）】
- StringBox: 完全一致、大文字小文字を区別
- IntegerBox: == による数値比較
- BoolBox: true/false の完全一致
- VoidBox/null: null との一致
【typeof との組み合わせ】
```nyash
peek typeof(value) {
"StringBox" => processString(value)
"IntegerBox" => processInt(value)
else => processOther(value)
}
```
※ typeof は既存実装の型名文字列をそのまま返す
================================================================================
4. publicキーワードの扱い
================================================================================
【現状との調整】
- 既存: public { field1, field2 } ブロック形式
- 新規: public field: Type 個別指定形式
【P0での対応】
```rust
// 両方をサポート（移行期間）
box Example {
// 新形式
public name: StringBox
count: IntegerBox
// 旧形式（レガシー、警告付きでサポート）
public { oldField1, oldField2 }
}
```
【実装方針】
- publicを「文脈依存キーワード」として扱う
- Box内でのみ特別な意味を持つ
- それ以外では識別子として使える（後方互換性）
================================================================================
5. フィールド宣言の段階実装
================================================================================
【P0（今回）】
- パースのみ: name: Type
- publicプレフィックス対応
- デフォルト値なし（= expr はP1へ）
【P1（次回）】
- デフォルト値: name: Type = expr
- birth内での自動初期化
【現在の回避策】
```nyash
box Counter {
count: IntegerBox
cache: MapBox // デフォルト値はP1まで待つ
birth() {
me.count = 0
me.cache = new MapBox() // birth内で明示的に初期化
}
}
```
================================================================================
6. デシュガー戦略（P0）
================================================================================
【peek → if-else連鎖】
```nyash
// Nyashコード
peek animal {
"dog" => bark()
"cat" => meow()
else => silent()
}
// デシュガー後（概念的）
if animal == "dog" {
bark()
} else if animal == "cat" {
meow()
} else {
silent()
}
```
【実装の簡単さ優先】
- VM/MIRは既存のif-else処理をそのまま利用
- 最適化（ジャンプテーブル等）はP1以降
================================================================================
7. 最小限のテストケース（P0）
================================================================================
```nyash
// test_peek_basic.nyash
local animal = "cat"
local sound = peek animal {
"dog" => "woof"
"cat" => "meow"
else => "..."
}
print(sound) // "meow"
// test_peek_block.nyash
local result = peek x {
1 => {
local temp = "one"
temp // 値
}
else => "other"
}
// test_continue.nyash
local i = 0
local sum = 0
loop(i < 5) {
i = i + 1
if i == 3 {
continue
}
sum = sum + i
}
print(sum) // 12 (1+2+4+5, 3はスキップ)
// test_field_declaration.nyash
box Point {
public x: IntegerBox
public y: IntegerBox
private z: IntegerBox
birth(x, y) {
me.x = x
me.y = y
me.z = 0
}
}
```
================================================================================
8. 実装順序（推奨）
================================================================================
1. tokenizer.rs
- FAT_ARROW, DOUBLE_COLON追加
- peek, continue, birth を予約語追加
2. parser/expressions.rs
- parse_peek_expr() 実装
- else必須チェック
3. parser/statements.rs
- Continue文追加
- フィールド宣言パース追加
4. ast.rs
- PeekExpr, ContinueStmt追加
- Field構造体に型情報追加
5. interpreter/evaluator.rs
- peek式の評価（if-elseとして）
- continue処理（既存のControlFlow利用）
================================================================================
9. P1に回すもの（今回は実装しない）
================================================================================
- import文の完全実装
- Parent::method() 記法（トークンのみ追加）
- fn{} クロージャの完全実装（環境キャプチャ等）
- フィールドのデフォルト値
- @override等の属性
================================================================================
10. 合意事項の最終確認
================================================================================
✓ peekは「式」として値を返す
✓ else節は必須（コンパイルエラー）
✓ 空ブロックの値はVoidBox
✓ publicは文脈依存キーワード（互換性維持）
✓ フィールドのデフォルト値はP1送り
✓ デシュガーでシンプル実装（最適化は後回し）
================================================================================

43
docs/private/roadmap/phases/phase-12.7/予定.txt Normal file
View File

@ -0,0 +1,43 @@
Phase 12.7-B 基本糖衣構文・最小導入 予定
目的
- セルフホスティング前に、安全な最小糖衣（basic）を段階導入。
- 挙動は正規ASTへ正規化してから既存パイプラインに渡す（可逆前提）。
範囲（basic 初期スコープ）
- 追加トークン: `|>`, `?.`, `??`, `+=`, `-=`, `*=`, `/=`, `..`
- 正規化ルール:
- `x |> f` → `f(x)`
- `x?.y` → `tmp=x; tmp!=null ? tmp.y : null`
- `x ?? y` → `x!=null ? x : y`
- `a += b` 等 → `a = a + b` 等
- `a..b` → Range（ArrayBox生成）に正規化（最小仕様）
- 高階演算子（`/:`, `\:`, `//`）は衝突回避のため当面見送り
実装タスク（Week 1）
1) tokenizer: 2文字演算子を長い順優先で追加（`??`, `?.`, `|>`, `+=`, …, `..`）
2) parser/sugar.rs: `apply_sugar(ast, &SugarConfig)` の骨組み＋上記4種の正規化
3) config: `nyash.toml [syntax] sugar_level=none|basic|full` 読み込み→`SugarConfig`
4) パーサ統合: `NyashParser` → 生成後に `apply_sugar` を呼ぶ（basicのみON）
5) テスト: `tests/sugar_basic_test.rs` と `tools/smoke_vm_jit.sh` に `NYASH_SYNTAX_SUGAR_LEVEL=basic`
6) ドキュメント: phase-12.7 README に basic 実装済みの注記
実装タスク（Week 2）
7) 分割代入（最小）: Map/Array への展開のみ、正規ASTへ分解
8) ラベル付き引数: ひとまず MapBox 経由へ正規化（将来のキーワード引数に備える）
9) ANCP トランスコーダ（別ツール）雛形: encode/decode、文字列/コメント保護、位置マッピング
安全策
- 既定: `sugar_level=none`（明示のみ）。開発では `basic` を個別ON。
- 可逆性: `SpanMapping` を保持（エラー位置を元コードへ戻す）
- E2E 影響なし: 正規ASTに落としてから既存実装へ渡す
完了条件（basic）
- `|>`, `?.`, `??`, 複合代入、`..` の正規化が安定
- ON/OFF で `tools/smoke_vm_jit.sh` が通過
- sugar 基本テストが通る（正規実行結果が一致）
注意
- `//` はコメントと衝突するため、初期スコープでは採用しない
- パイプラインのメソッド呼出し規約（`data |> me.f` など）はドキュメントで明示

149
docs/private/roadmap/phases/phase-12/BREAKTHROUGH_CONCLUSION.md Normal file
View File

@ -0,0 +1,149 @@
# Phase 12: 究極のブレイクスルー - ユーザー箱とプラグイン箱の境界消滅
## 📅 2025-09-02 - ChatGPT5先生からの最終結論
### 🌟 結論
> **「ユーザー箱とプラグイン箱の境界をなくす」「Nyash ABIで拡張する」は綺麗に箱化して実装できます。既存のVM/PIC/vtable下地があるので、無理なく段階導入できます。**
## 🎯 これが意味すること
### 1. Everything is Box の究極形
```nyash
// もはや区別がない世界
box MyCustomBox { // ユーザー定義
// 自動的にプラグインとしても使える！
}
// C ABIプラグイン
extern box FileBox { // プラグイン
// ユーザーBoxと同じように扱える！
}
// 完全に透明な相互運用
local processor = new MyCustomBox()
processor.processFile(new FileBox("data.txt"))
```
### 2. 実装の現実性
既存インフラが整っている：
- **VM**: すでにBoxCallを統一的に処理
- **PIC**: Polymorphic Inline Cacheで高速化済み
- **vtable**: 動的ディスパッチ基盤完成
### 3. 段階的導入計画
#### Phase 1: 境界の曖昧化（1週間）
```nyash
// ユーザーBoxに自動エクスポート機能
@export
box DataProcessor {
process(data) { ... }
}
```
#### Phase 2: 統一レジストリ（2週間）
```c
// すべてのBoxが同じレジストリに登録
NyRegisterBox(spec, ORIGIN_USER); // ユーザー定義
NyRegisterBox(spec, ORIGIN_PLUGIN); // プラグイン
NyRegisterBox(spec, ORIGIN_BUILTIN); // ビルトイン
```
#### Phase 3: 完全統合（1ヶ月）
- ユーザーBoxの自動C ABI生成
- AOT時の最適化統一
- 実行時の完全な相互運用性
## 🚀 技術的実現方法
### 1. ユーザーBox → プラグイン変換
```rust
// コンパイル時に自動生成
impl UserBoxToPlugin for DataProcessor {
fn generate_c_abi() -> NyashTypeBox {
NyashTypeBox {
create: |args| Box::new(DataProcessor::new(args)),
invoke_id: |self, id, args| {
match id {
1 => self.process(args[0]),
_ => NyResult::Error("Unknown method")
}
},
// ...
}
}
}
```
### 2. 既存vtableの活用
```rust
// 現在のVMコード（すでに統一的！）
match value {
VMValue::BoxRef(b) => {
// ユーザーBox、プラグインBox、ビルトインBox
// すべて同じ経路で処理される！
self.call_box_method(b, method, args)
}
}
```
### 3. PIC最適化の共有
```rust
// 既存のPICがそのまま使える
struct PolymorphicInlineCache {
entries: [(TypeId, MethodId, FnPtr); 4],
}
// ユーザーBoxもプラグインBoxも同じ最適化を受ける
```
## 💡 革命的な利点
### 1. 開発体験の統一
- Nyashだけ書けばプラグインになる
- C/Rustの知識不要
- デバッグが容易
### 2. パフォーマンスの両立
- 開発時: インタープリター実行
- 本番時: AOT/JIT最適化
- 同じコードで両方可能
### 3. エコシステムの爆発的成長
- 誰でもプラグイン作者に
- Nyashで書いたBoxが他言語から使える
- 真の言語間相互運用性
## 📊 実装優先順位
1. **即実装可能**（既存基盤で動く）
- ユーザーBox登録API拡張
- 統一レジストリ実装
- 基本的な相互運用テスト
2. **短期実装**（軽微な修正）
- @exportアノテーション
- 自動C ABI生成
- ドキュメント整備
3. **中期実装**（最適化）
- AOT時の統一最適化
- クロスランゲージデバッガ
- パッケージマネージャー統合
## 🎯 結論
**「箱の境界をなくす」は、単なる理想ではなく、現在のNyashアーキテクチャで実現可能な次のステップです。**
既存のVM/PIC/vtable基盤があるため、追加実装は最小限で済みます。これこそが「Everything is Box」哲学の究極の実現です。
## 📚 参照
- [統一TypeBox ABI](./unified-typebox-abi.md)
- [ユーザー定義Box統合](./unified-typebox-user-box.md)
- [AI先生たちの技術検討](./ai-consultation-unified-typebox.md)

208
docs/private/roadmap/phases/phase-12/IMPLEMENTATION_ROADMAP.md Normal file
View File

@ -0,0 +1,208 @@
# Phase 12: 統一TypeBox ABI - 実装ロードマップ
## 🎯 概要
このドキュメントは、統一TypeBox ABIの実装を段階的に進めるための詳細なロードマップです。
## 📅 タイムライン
```
2025年9月（Week 1-2）: 基礎実装
2025年9月（Week 3-4）: 最適化・性能向上
2025年10月（Week 1-2）: 移行ツール・互換性
2025年10月（Week 3-4）: 完全移行・テスト
2025年11月：リリース準備
```
## 🚀 Phase 12.0: 基礎実装（Week 1-2）
### Week 1: コア構造体とAPI
#### タスク
- [ ] `include/nyash/typebox.h` ヘッダー定義
- [ ] NyashTypeBox構造体
- [ ] NyBoxHeader構造体
- [ ] NyValue統一表現
- [ ] 基本的なヘルパーマクロ
- [ ] `src/runtime/typebox_registry.rs` 実装
- [ ] Type ID管理システム
- [ ] register_user_box基本実装
- [ ] メソッドテーブル管理
- [ ] 基本的なテストケース
- [ ] ユーザーBox登録テスト
- [ ] メソッド呼び出しテスト
- [ ] 参照カウントテスト
#### 成果物
- 動作する最小限のTypeBox登録・呼び出し
- ドキュメント化されたAPI
### Week 2: 互換レイヤー
#### タスク
- [ ] 既存C ABIとの互換レイヤー
- [ ] 旧形式→TypeBox自動変換
- [ ] フォールバックメカニズム
- [ ] 警告・移行推奨メッセージ
- [ ] 主要プラグインの動作確認
- [ ] FileBox
- [ ] StringBox
- [ ] MapBox
- [ ] ArrayBox
#### 成果物
- 既存プラグインが新システムで動作
- 移行ガイドの初版
## ⚡ Phase 12.1: 最適化（Week 3-4）
### Week 3: メソッドID最適化
#### タスク
- [ ] メソッド名→ID解決システム
- [ ] ハッシュテーブル実装
- [ ] スロット割り当てアルゴリズム
- [ ] キャッシュ機構
- [ ] パフォーマンス測定
- [ ] ベンチマークスイート作成
- [ ] 旧方式との比較測定
- [ ] ボトルネック分析
#### 成果物
- 10倍以上の高速化を確認
- パフォーマンスレポート
### Week 4: JIT/AOT統合
#### タスク
- [ ] インラインキャッシング基礎
- [ ] Monomorphic IC実装
- [ ] キャッシュヒット率測定
- [ ] Deoptimizationフック
- [ ] JIT統合準備
- [ ] メソッドポインタ直接呼び出し
- [ ] 型情報の静的解析連携
- [ ] AOT向け最適化ヒント
#### 成果物
- IC有効時30倍高速化を達成
- JIT統合設計書
## 🔄 Phase 12.2: 移行ツール（Week 5-6）
### Week 5: ツール開発
#### タスク
- [ ] `ny-abi-gen` コード生成ツール
- [ ] Cヘッダーからの自動生成
- [ ] nyash.toml更新機能
- [ ] ドキュメント生成
- [ ] `ny-abi-check` 検証ツール
- [ ] ABI互換性チェック
- [ ] 署名検証
- [ ] セキュリティ監査
#### 成果物
- 使いやすい移行ツール群
- 自動化されたCI/CDパイプライン
### Week 6: プラグイン移行
#### タスク
- [ ] コアプラグインの移行
- [ ] すべてのビルトインBoxをTypeBox化
- [ ] サードパーティプラグインサポート
- [ ] 移行スクリプト提供
- [ ] ドキュメント整備
- [ ] 移行ガイド完成版
- [ ] APIリファレンス
- [ ] サンプルコード集
#### 成果物
- 90%以上のプラグインが新ABI対応
- 完全なドキュメント
## ✅ Phase 12.3: 完全移行（Week 7-8）
### Week 7: 統合テスト
#### タスク
- [ ] エンドツーエンドテスト
- [ ] 実アプリケーションでの動作確認
- [ ] パフォーマンス回帰テスト
- [ ] メモリリークチェック
- [ ] セキュリティ監査
- [ ] Wasmサンドボックステスト
- [ ] 権限管理システム検証
- [ ] ファジングテスト
#### 成果物
- グリーンなテストスイート
- セキュリティレポート
### Week 8: リリース準備
#### タスク
- [ ] 最終調整
- [ ] パフォーマンスチューニング
- [ ] メモリ使用量最適化
- [ ] エラーメッセージ改善
- [ ] リリース準備
- [ ] CHANGELOG作成
- [ ] アップグレードガイド
- [ ] ブログ記事・アナウンス
#### 成果物
- リリース候補版
- 完全なリリースノート
## 📊 成功指標
### パフォーマンス
- メソッド呼び出し: 50倍高速化（目標）
- メモリ使用量: 現状維持または改善
- 起動時間: 10%以内の増加
### 互換性
- 既存プラグイン: 100%動作
- 新規API採用率: 80%以上
- 移行完了率: 90%以上
### 品質
- テストカバレッジ: 90%以上
- ドキュメント完成度: 100%
- バグ報告: クリティカル0件
## 🚨 リスクと対策
### 技術的リスク
- **ABI破壊的変更**: 段階的移行と互換レイヤーで対応
- **パフォーマンス劣化**: 継続的なベンチマークで早期発見
- **メモリリーク**: 自動テストとValgrind検証
### スケジュールリスク
- **遅延**: 2週間のバッファを確保
- **スコープクリープ**: 機能は段階的リリース
- **リソース不足**: コミュニティ協力を促進
## 🎯 次のステップ
1. このロードマップのレビューと承認
2. Week 1タスクの詳細化
3. 開発環境のセットアップ
4. キックオフミーティング
## 📚 参照
- [技術的決定事項](./TECHNICAL_DECISIONS.md)
- [統一TypeBox ABI仕様](./unified-typebox-abi.md)
- [AI先生たちの技術検討](./ai-consultation-unified-typebox.md)

62
docs/private/roadmap/phases/phase-12/PLAN.md Normal file
View File

@ -0,0 +1,62 @@
# Phase 12: ユーザー箱とプラグイン箱の境界撤廃 + Nyash ABI 導入計画（下準備）
目的
- 境界撤廃: ユーザー箱／プラグイン箱／内蔵箱を「TypeBox + Instance」に統一。
- Nyash ABI: vtable（slot優先）で高速・型安全に呼び出し、未対応は現行C ABI(TLV)へフォールバック。
- 綺麗な箱化: VM/JIT/LLVM/WASMが同一ディスパッチ構造を共有できる形へ段階導入。
- 同一実行: Nyashコードが VM と JIT で「意味・結果・副作用」が一致（同値性がテストで担保）。
非スコープ（当面）
- 既存C ABIの破壊的変更。段階導入のためC ABIは維持（fallback専用）。
- 直ちに全プラグインを移行すること（まずは1プラグインでPoC）。
設計の要点（サマリ）
- TypeBox（静的メタ）: 型名、メソッドslot→関数ポインタ、属性（可変/不変など）。
- Instance（実体）: type_id + 実体ハンドル（ユーザー/プラグイン/内蔵いずれも統一の箱）。
- VMディスパッチ: method_id/slotがあれば vtable 直呼び。なければ name→slot 解決→vtable／PIC→C ABI。
- JIT: まずはホストコールthunkでTypeBox vtable呼び出し→後続でモノモーフィック直埋め最適化。
- GC/Barrier: BoxCall(setField)/ArraySetでWrite Barrier発火（既存fast-path維持）。
トグル（管理棟に集約予定）
- NYASH_ABI_VTABLE=1 … vtable経路を有効化（既定OFF）
- NYASH_ABI_STRICT=1 … vtable未登録メソッド時にC ABIフォールバック禁止（実験）
段階導入（Tier）
1) Tier-0（雛形）
- 追加: `src/runtime/type_box_abi.rs`（NyrtValue/TypeBox/関数ポインタ型、最小API）
- 追加: `src/runtime/type_registry.rs`（TypeId→TypeBox参照）
- VM: `execute_boxcall` に vtable 優先のstubを追加（`NYASH_ABI_VTABLE=1`時のみ）
- Docs/CI: 仕様追記・スモーク追加準備（まだvtableは未実装でもOK）
2) Tier-1（実証）
- 1プラグイン（例: MapBox.getS）を Nyash ABI で動作させる（VM→vtable→関数ポインタ）
- JIT: vtable呼び出しthunk追加（VM側レジストリから関数ポインタ取得）
- テスト: C ABI とNyash ABIの同等性（差分テスト）
3) Tier-2（拡張）
- 内蔵箱のTypeBox化（Array/String/Mapの主要メソッド）
- ユーザー箱（InstanceBox）をTypeBox上に還元（Rust関数を関数ポインタで包む）
- name→slot化の徹底（slot_registry と連携強化）
4) Tier-3（セルフホスティング準備）
- Nyash ABI のC実装を開始（Rust⇔C シム）
- JIT: モノモーフィックサイトで vtable_slot 直呼び最適化
完了条件（Phase 12の下準備）
- PLAN/TASKS/TECHNICAL_DECISIONS に統一方針と段階計画が明記されている。
- `NYASH_ABI_VTABLE` トグルの導入方針が定義済み（まだコードは雛形で可）。
- VM側にvtable優先呼び出しstubの追加計画が固まり、レジストリ/TypeBox ABIの最小構成が決まっている。
- Cross-backend同値テストの設計方針が固まっている（VM/JITを同条件で走らせ、結果/ログ/副作用を比較する仕組み）。
次アクション（このPR/コミット範囲外の実装）
- TypeBox ABIモジュール雛形の追加、VM vtable stub の実装（既定OFF）。
- MapBoxで最小PoC（getS）を先行導入（C ABIと同じ結果を返す）。
- docs/TASKSのTier-0チェックを更新、CIスモークの草案を追加。
検証（同一実行）の方針
- テストハーネス: 同一 Nyash プログラムを VM と JIT で実行し、以下を比較
- 戻り値の等価（NyashValue同値: int/float/bool/string/null/void）
- Box状態の差分（対象: Map/Array/Instance の代表ケース）
- ログイベントの正規化比較（必要最小限）
- スコープ: array/field/arithmetic/extern_call を最小セットにし、段階的に拡張
- CI連携: `consistency` ラベルのテストジョブを追加（将来）
参考ドキュメント
- Nyash ABI Minimal Coreと進化戦略: `docs/reference/abi/NYASH_ABI_MIN_CORE.md`

271
docs/private/roadmap/phases/phase-12/README.md Normal file
View File

@ -0,0 +1,271 @@
# Phase 12: Nyashコード共有エコシステム - Everything is Box の実現
> Status note (Phase‑15): このフォルダは「統一TypeBox ABI」の長期設計（青写真）です。現在の main 実装は最小の v2 ABI に収束しており、実用重視で段階導入中です。現行仕様は `docs/reference/plugin-abi/nyash_abi_v2.md` を参照してください。Phase‑12 の要素（create/destroy、型メタ、NyValue、vtable/RC/GC）は前方互換を維持しつつ段階追加予定です。
## 🌟 最新ブレイクスルー (2025-09-02) - 統一TypeBox ABI誕生！
### 🚨 究極の発見：ユーザー定義Boxもプラグインに！
**AI先生たちの深い技術的検討により、革命的なアイデアが実現可能と判明！**
```c
// ユーザーBoxもプラグインとして動的登録
NyashTypeBox* register_user_box(const char* name,
NyashBoxMethods* methods);
```
**これにより実現すること**：
- 🎯 **すべての箱をC ABI上で一つで管理**
- 🔄 **ユーザー定義Box ↔ プラグインBox 完全相互運用**
- 🚀 **Nyash側から見ると完全に統一された世界観**
詳細：[ユーザー定義Box統合](./unified-typebox-user-box.md) 🆕
### 🔥 究極の統合：すべてのプラグインがTypeBoxになる！
「Everything is Box」哲学の完成形：**C ABIもNyash ABIも統一TypeBoxに統合**！
```c
// 統一TypeBox - すべてのプラグインがこの形式に！
typedef struct {
uint32_t abi_tag; // 'TYBX' - すべて同じ
uint16_t version; // APIバージョン
const char* name; // "StringBox", "FileBox", etc.
// 基本操作（旧C ABI互換）
void* (*create)(void* args);
void (*destroy)(void* self);
// 高速メソッドディスパッチ（新機能）
uint32_t (*resolve)(const char* name); // 名前→ID変換
NyResult (*invoke_id)(void* self, // ID呼び出し（JIT最適化）
uint32_t method_id,
NyValue* args, int argc);
// メタ情報
uint64_t capabilities; // THREAD_SAFE | ASYNC_SAFE等
} NyashTypeBox;
```
**3大AI専門家の統合案への評価**:
- **Gemini**: 「技術的妥当性は非常に高い。単なるアイデアではなく、堅牢なアーキテクチャ」
- **Codex**: 「TypeBox統合は実現可能で有益。JIT最適化で33倍高速化も可能」
- **ChatGPT5**: 「『Everything is Box』哲学に最も適した設計」（設計に反映済み）
### 🎯 なぜ統合するのか？
以前は2つのシステムが混在していました：
- **C ABI**：シンプルだが拡張性に限界
- **TypeBox**：プラグイン間連携は可能だが別システム
**統合により実現したこと**：
1. **概念の統一**：すべてがTypeBoxという1つの形式
2. **プラグイン間連携が標準装備**：どのプラグインも他のBoxを作れる
3. **JIT/AOT最適化**：メソッドID化で最大33倍高速化
4. **段階的移行**：既存資産を保護しながら進化
## 🎯 重要な変更 (2025-09-01)
Phase 12の議論とビルトインBox廃止により、プラグインシステムが進化：
**新しい3層プラグインシステムが確立されました！**
```nyash
# Nyashスクリプトプラグイン（ユーザー定義Box）
box DataProcessor {
init {
me.file = new FileBox() # C ABIプラグイン使用
me.math = new MathBox() # C ABIプラグイン使用
me.cache = new MapBox() # これもC ABIプラグイン（ビルトイン廃止）
}
process(data) {
local result = me.math.sin(data)
me.file.write("log.txt", result.toString())
return result
}
}
# 使用例
local processor = new DataProcessor()
processor.process(3.14) # すべてプラグインで動作！
```
## 📝 なぜ誤解が生まれたのか
「プラグイン」という言葉から、特別な仕組みが必要だと考えてしまいましたが、Nyashの「Everything is Box」哲学により、ユーザー定義Boxこそが最高のプラグインシステムでした。
詳細な分析：[なぜ天才AIたちは間違えたのか](./design/WHY-AIS-FAILED.md)
## 🚀 Phase 12の真の価値：コード共有エコシステム（同一実行の確立）
最終ゴールは「Nyashコード → VM → JIT の同一実行」。同じプログラムがVMとJITで同じ意味・結果・副作用になるよう、ディスパッチ/ABI/Barrier/Safepointの規約を共有し、差分をなくします。テストハーネスで同値性を比較できるように整備します。
### 本当に必要なもの
1. **export/import構文**
```nyash
# math_utils.ny
export box MathUtils {
factorial(n) { ... }
fibonacci(n) { ... }
}
# main.ny
import { MathUtils } from "math_utils.ny"
local utils = new MathUtils()
```
2. **パッケージマネージャー**
```bash
nyash install awesome-math-utils
nyash publish my-cool-box
```
3. **ドキュメント生成**
```nyash
# @doc 素晴らしい数学ユーティリティ
# @param n 計算したい数値
# @return 階乗の結果
export box MathUtils { ... }
```
## 📊 新しい統一プラグインシステム
```
Nyashエコシステム（統一TypeBox ABI採用後）：
├── Nyashスクリプトプラグイン ← .nyashファイル（純粋なNyashコード）
└── 統一TypeBoxプラグイン ← .so/.dll（ネイティブ実装）
├── 基本機能（旧C ABI互換）
├── 高速ディスパッチ（JIT最適化）
└── プラグイン間連携（標準装備）
```
### 🔄 移行パス
- **既存C ABIプラグイン** → そのまま動作（互換レイヤー経由）
- **新規プラグイン** → 統一TypeBox形式で作成
- **段階的移行** → ツールで自動変換支援
### 📚 プラグインシステムドキュメント
- **[統一TypeBox ABI](./unified-typebox-abi.md)** 🆕 - すべてのプラグインの統一仕様
- **[移行ガイド](./migration-guide.md)** 🆕 - 既存プラグインの移行方法
- **[Nyashスクリプトプラグイン](./nyash-script-plugins.md)** - 純粋なNyashコードのプラグイン
### 📦 レガシードキュメント（参考用）
- [旧C ABI仕様](./archive/legacy-abi-docs/c-abi.md)
- [旧Nyash ABI仕様](./archive/legacy-abi-docs/nyash-abi.md)
### 💡 TypeBox：シンプルなプラグイン間連携
MapBox.keys()がArrayBoxを返したい場合：
```c
// TypeBox構造体（型情報をBoxとして扱う）
typedef struct {
uint32_t abi_tag; // 'TYBX'
const char* name; // "ArrayBox"
void* (*create)(void); // Box生成関数
} NyrtTypeBox;
// MapBox.keys()実装
void* map_keys(void* self, void* array_type_box) {
NyrtTypeBox* array_type = (NyrtTypeBox*)array_type_box;
void* array = array_type->create(); // ArrayBox生成
// ... キーを追加
return array;
}
```
詳細: [C ABI TypeBox設計仕様書](./archive/legacy-abi-docs/C-ABI-BOX-FACTORY-DESIGN.md)
### プラグイン選択の指針
- **C ABIで済むなら、C ABIを使う**（シンプルイズベスト）
- Nyash ABIは以下の場合のみ：
- 他言語（Python/Go等）からの呼び出し
- 複雑な型の相互運用が必要
- 将来の拡張性を重視する場合
### 📝 MIR命令統合（Phase 12での変更）
- **PluginInvoke → BoxCall 統合**
- ビルトインBox廃止によりフォールバックがなくなる
- BoxCallとPluginInvokeの区別が不要に
- VM層でC ABI/Nyash ABI/Scriptを自動判定
- Core-15 → Core-14 へ（命令数削減）
## 🛣️ 実装ロードマップ（統一TypeBox ABI版）
### Phase 12.0: 統一TypeBox ABI実装（1週間）🆕
- [ ] nyash_typebox.h完全ヘッダー定義
- [ ] メソッドID解決・キャッシング機構
- [ ] NyValue統一値表現の実装
- [ ] 互換レイヤー（既存C ABI→TypeBox）
- 📄 **[統一TypeBox ABI仕様](./unified-typebox-abi.md)**
### Phase 12.0.5: 移行ツール開発（2週間）🔧
- [ ] プラグイン自動変換ツール
- [ ] 検証・テストツール
- [ ] パフォーマンスベンチマーク
- [ ] サンプルプラグイン集
- 📄 **[移行ガイド](./migration-guide.md)**
---
## 現状サマリ（2025-09-02）
- C ABI（TLV: 1/2/3/5/6/7/8）でのプラグイン呼び出しはVMで安定運用中。`returns_result` も `nyash.toml` で制御可能。
- JIT は VM と同じBox境界で動作（フォールバック含む）。Cranelift AOT のオブジェクト出力は未配線（スケルトン）。
- MapBox を拡張（stringキー、remove/clear/getOr/keysStr/valuesStr/toJson）。`keys()/values()` はランタイムシムで暫定提供。
- Phase 12 設計（TypeBox + Unified Dispatch）は破壊的変更不要で段階導入可能と判断。
詳細タスクは [TASKS.md](./TASKS.md) を参照。
### Phase 12.1: export/import構文（2週間）
- [ ] exportキーワードのパーサー実装
- [ ] importステートメントの実装
- [ ] モジュール解決システム
- 📄 **[詳細仕様書](./export-import-spec.md)**
### Phase 12.2: パッケージ管理（3週間）
- [ ] nyash.tomlのdependencies対応
- [ ] 中央リポジトリ設計
- [ ] CLIツール（install/publish）
- 📄 **[パッケージマネージャー設計書](./package-manager-design.md)**
### Phase 12.3: 開発者体験向上（継続的）
- [ ] ドキュメント生成ツール
- [ ] VSCode拡張（補完・定義ジャンプ）
- [ ] サンプルパッケージ作成
## 📚 関連ドキュメント
### 🎯 プラグインシステムガイド（メインドキュメント）
- **[統一TypeBox ABI](./unified-typebox-abi.md)** ← 🌟🆕 すべてのプラグインの新仕様！
- **[ユーザー定義Box統合](./unified-typebox-user-box.md)** ← 🔥🆕 革命的な完全統合！
- **[AI先生たちの技術的検討](./ai-consultation-unified-typebox.md)** ← 🤖🆕 深い分析と提言（Codex詳細版追加）
- **[技術的決定事項](./TECHNICAL_DECISIONS.md)** ← 📋🆕 確定した技術仕様まとめ
- **[実装ロードマップ](./IMPLEMENTATION_ROADMAP.md)** ← 📅🆕 詳細な実装計画
- **[移行ガイド](./migration-guide.md)** ← 🆕 既存プラグインを新形式へ
- **[Nyashスクリプトプラグイン](./nyash-script-plugins.md)** ← 純粋なNyashコードのプラグイン
### 📐 設計ドキュメント（design/）
- **[統合ABI設計仕様書](./design/UNIFIED-ABI-DESIGN.md)** ← 統合の詳細設計
- **[C ABI TypeBox設計仕様書](./archive/legacy-abi-docs/C-ABI-BOX-FACTORY-DESIGN.md)** ← TypeBoxの原点
- **[Nyash ABI C実装設計書](./design/NYASH-ABI-C-IMPLEMENTATION.md)** ← セルフホスティング構想
- **[なぜ天才AIたちは間違えたのか](./design/WHY-AIS-FAILED.md)** ← 設計プロセスの教訓
### 📋 仕様書（specs/）
- **[export/import仕様](./specs/export-import-spec.md)** ← モジュールシステムの詳細仕様
- **[パッケージマネージャー設計](./specs/package-manager-design.md)** ← パッケージ管理の設計
### 💬 議論の過程（discussions/）
- **ABI戦略議論**: `discussions/abi-strategy-discussion/`
- **Nyash ABI詳細**: `discussions/nyash-abi-discussion/`
### 📦 アーカイブ
- **初期提案**: `archive/` ← 過去の提案や古いドキュメント
---
*AIたちがなぜ複雑な解決策を提案したのか、その議論の過程は `archive/` ディレクトリに保存されています。良い教訓として残しておきます。*

66
docs/private/roadmap/phases/phase-12/TASKS.md Normal file
View File

@ -0,0 +1,66 @@
# Phase 12 Task Board (v2 - セルフホスティング対応)
Status: Tier-0 完了（vtable雛形 + レジストリ + VM優先経路）。次は Tier-1 の最小Nyash ABIサンプル実装へ。
目的: C ABI を壊さず、TypeBox + 統一ディスパッチで Nyash ABI を段階導入。MIR→VM→JIT を「綺麗な箱」で統一。**最終的にRust依存を排除し、セルフホスティングを実現。**
## Tier-0（直近・安全に積める）
- [x] MapBoxの実用拡張（stringキー/便利API）
- [x] `keys()/values()` 実装（ArrayBox返却に更新）
- [x] TypeBoxレジストリ（雛形）
- Box名/FQN、type_id、メソッド表（静的スロット）を登録（`src/runtime/type_registry.rs`）
- 既存 `nyash.toml` → TypeBoxInfo 変換層は別途（未着手）
- [x] 統一ディスパッチ層（VM・雛形）
- `NYASH_ABI_VTABLE=1` で vtable優先のVM経路を有効化（fallbackはC ABI/TLV）。
- Array/Map/String/Instance の主要メソッドを最小カバレッジで処理（`try_boxcall_vtable_stub`）。
- 所有権・セーフポイントのガードは既存Barrier呼び出しで一部対応（MAY_BLOCK等は今後拡張）。
- [x] プラグインテスター更新（v2ローダに対応）: `src/bin/test_plugin_loader_v2.rs`
## Tier-1（実証）
- [ ] Nyash ABI vtable の最小サンプル（1プラグイン・1メソッド）
- 例: MapBox.getS(name) を Nyash ABI で直接返却
- 単体テスト（VM/JIT）
- [ ] JIT側：統一ディスパッチthunkを呼ぶ経路を追加（フォールバックでも可）
- [ ] 互換テスト: C ABI と Nyash ABI が同一結果になる差分テスト
## Tier-2（強化）
- [ ] NyashValueインライン（i64/bool）の高速化
- [ ] 例外/エラーの完全変換（panic→nyrt_err）
- [ ] 所有権契約の遵守（TRANSFER/BORROW/CLONE）
- [x] `keys()/values()` の正式実装（ArrayBox返却）
- 採用: ランタイムで ArrayBox を構築（`src/boxes/map_box.rs`）
## Tier-3（セルフホスティング）🔥新規
- [ ] Nyash ABI C実装の開始
- [ ] nyash_abi_provider.h定義（16バイトアライメント）
- [ ] C Shim実装（Rust FFI経由）
- [ ] 基本型実装（Tagged Pointers対応）
- [ ] アトミック参照カウント実装
- [ ] 弱参照による循環参照対策
- [ ] セレクターキャッシング実装
- [ ] lookup_selector API
- [ ] JIT統合（vtable_slot直接呼び出し）
- [ ] 適合性テストスイート構築
- [ ] Rust/C実装の差分テスト
- [ ] パフォーマンス測定（1.5x以内）
## ドキュメント/管理
- [ ] UNIFIED-ABI-DESIGN.md の「最小導入プロファイル」明記
- [ ] VM/JIT実装メモ（統一ディスパッチの呼出し順）
- [ ] リファクタリング計画（>1000行ファイルの分割方針）
## 既知のやり残し（Phase 12 関連）
- TypeBoxレジストリ/統一ディスパッチのコード未導入
- Nyash ABI vtableの実装サンプル未着手
- 既存プラグインの対応（TypeBox vtable移行 or 互換レイヤ継続）
- GCセーフポイントのMAY_BLOCK以外の一般化
- keys()/values() の正式ArrayBox返却（現状はシム）
- AOT(LLVM)のbuild失敗（nyrt借用修正、後回し方針）
- Nyash ABI C実装（セルフホスティングの要）🔥新規
## Doneの定義（Phase 12 - 更新版）
1) TypeBoxレジストリと統一ディスパッチがVMに入り、C ABI互換で全プラグインが動作
2) 1プラグインでNyash ABIの成功パスが通る（VM/JIT）
3) keys()/values() が ArrayBox 返却で安定
4) 基本の所有権・セーフポイントルールが守られる
5) **Nyash ABI C実装の基礎が動作し、セルフホスティングへの道筋が明確**🔥新規

143
docs/private/roadmap/phases/phase-12/TECHNICAL_DECISIONS.md Normal file
View File

@ -0,0 +1,143 @@
# Phase 12: 統一TypeBox ABI - 技術的決定事項
## 📅 最終更新: 2025-09-02
このドキュメントは、3人のAI専門家（Gemini、Codex、ChatGPT5）の深い技術検討を経て決定された、統一TypeBox ABIの技術的決定事項をまとめたものです。
## 🎯 核心的決定事項
### 1. 統一TypeBox構造体の確定
```c
typedef struct NyashTypeBox {
// === ヘッダー情報（不変のバイナリ契約）===
uint32_t abi_tag; // 'TYBX' (0x54594258) - 必須
uint16_t version; // APIバージョン（現在: 1）
uint16_t struct_size; // 構造体サイズ（前方互換性）
const char* name; // Box型名："StringBox"
// === 基本操作（COM互換）===
void* (*create)(void* args); // インスタンス生成
void (*destroy)(void* self); // インスタンス破棄
void (*retain)(void* self); // 参照カウント増加（新規）
void (*release)(void* self); // 参照カウント減少（新規）
// === 高速メソッドディスパッチ ===
uint32_t (*resolve)(const char* name); // メソッド名→ID変換
NyResult (*invoke_id)(void* self, // ID指定の高速呼び出し
uint32_t method_id,
NyValue* args,
int argc);
// === メタ情報 ===
const char* (*get_type_info)(void); // JSON形式の型情報
uint64_t capabilities; // 機能フラグ
// === 将来拡張用 ===
void* reserved[4]; // NULL初期化必須
} NyashTypeBox;
```
### 2. Type ID管理戦略
64-bit構造: `[8b domain | 8b vendor | 16b category | 32b serial]`
- **0x00xxxxxx**: Core/Built-in types
- **0x40xxxxxx**: First-party plugins
- **0x80xxxxxx**: User-defined boxes (動的登録)
- **0xC0xxxxxx**: Experimental/Debug
### 3. メモリ管理統一方針
#### 参照カウント（必須）
- アトミック操作（`_Atomic uint64_t`）
- retain/releaseはCOM互換の固定位置
- 循環参照対策：Trial Deletion + Weak Boundary
#### GC協調（オプション）
- traceメソッドの提供（プラグイン必須）
- 世代別GCとの協調動作
### 4. パフォーマンス目標値
- **メソッド呼び出し**: 旧50-150ns → 新1-3ns（最大50倍高速化）
- **インラインキャッシング**: Monomorphic IC標準装備
- **JIT統合**: ウォームアップ後の直接インライン化
### 5. セキュリティレベル定義
1. **trusted**: 同一プロセス内、直接関数呼び出し
2. **sandboxed**: Wasm/別プロセスで実行
3. **restricted**: 限定的な権限のみ
## 🔧 実装上の決定事項
### メソッドディスパッチ戦略
1. **新規プラグイン**: invoke_id優先（高速パス）
2. **既存プラグイン**: method経由でフォールバック
3. **移行期間**: 両方サポート、段階的に新方式へ
### NyValue統一表現
```c
typedef struct __attribute__((aligned(16))) {
uint64_t type_tag; // 型識別子
union {
int64_t i64; // 整数
double f64; // 浮動小数点
void* ptr; // ポインタ（Box/String等）
uint64_t bits; // ビットパターン（NaN-box/SMI）
} payload;
} NyValue;
```
### API互換性保証
- `NyBoxHeader.header_size`による前方互換
- vtableの先頭3メソッドは不変（COM準拠）
- 新機能は`capabilities`フラグで判定
## 📊 移行戦略
### Phase 1: 基礎実装（1週間）
- NyashTypeBox構造体定義
- 基本的なregister_user_box実装
- 互換レイヤー（既存C ABI→TypeBox）
### Phase 2: 最適化（2週間）
- メソッドID解決機構
- インラインキャッシング基礎
- JIT統合準備
### Phase 3: 完全移行（1ヶ月）
- すべてのビルトインBoxをTypeBox化
- パフォーマンスベンチマーク
- 移行ツール完成
## ✅ 合意済み事項
1. **Everything is Box哲学の完全実現**
- すべてのBox（ビルトイン、プラグイン、ユーザー定義）が統一ABI
- NyValue経由ですべて扱える
2. **段階的移行の保証**
- 既存プラグインは動作継続
- 新規開発は新ABIを推奨
3. **パフォーマンス優先**
- メソッドIDによる高速化は必須
- JIT/AOTとの密接な統合
## 🚫 却下された提案
1. **完全な動的型システム**: 静的解析を困難にするため
2. **プロセス間通信ベース**: オーバーヘッドが大きすぎる
3. **Rustネイティブ統合**: C ABIの安定性を優先
## 📚 参考資料
- [AI先生たちの技術的検討](./ai-consultation-unified-typebox.md)
- [統一TypeBox ABI仕様](./unified-typebox-abi.md)
- [ユーザー定義Box統合](./unified-typebox-user-box.md)
- [Nyash ABI Minimal Coreと進化戦略](../../../../reference/abi/NYASH_ABI_MIN_CORE.md)

154
docs/private/roadmap/phases/phase-12/USER_BOX_FFI_CHALLENGE.md Normal file
View File

@ -0,0 +1,154 @@
# ユーザーBoxをC ABIで渡す技術的課題
## 🚨 現在の実装の問題点
### 1. ユーザーBoxの内部構造
```rust
pub struct InstanceBox {
// フィールドはHashMapで管理
pub fields_ng: Arc<Mutex<HashMap<String, NyashValue>>>,
// メソッドはASTノードのまま！
pub methods: Arc<HashMap<String, ASTNode>>,
}
```
**問題**: これらはRust固有の構造で、C ABIで直接渡せない
### 2. C ABIが期待する構造
```c
typedef struct {
// 固定的な関数ポインタが必要
void* (*create)(void* args);
void (*destroy)(void* self);
NyResult (*invoke_id)(void* self, uint32_t method_id,
NyValue* args, int argc);
} NyashTypeBox;
```
## 🔧 必要な変換層
### 1. メソッドのコンパイル
```rust
// 現在: ASTNode（インタープリター実行）
methods: HashMap<String, ASTNode>
// 必要: 関数ポインタ or トランポリン
methods: HashMap<u32, fn(self, args) -> Result>
```
### 2. フィールドアクセスの標準化
```c
// C側から見えるインターフェース
typedef struct {
void* (*get_field)(void* self, const char* name);
void (*set_field)(void* self, const char* name, void* value);
} FieldAccessor;
```
### 3. トランポリン関数の生成
```rust
// ユーザーBoxごとに自動生成する必要がある
extern "C" fn user_box_invoke(
self_ptr: *mut c_void,
method_id: u32,
args: *mut NyValue,
argc: c_int
) -> NyResult {
// 1. self_ptrからInstanceBoxを復元
let instance = unsafe { &mut *(self_ptr as *mut InstanceBox) };
// 2. method_idからメソッド名を解決
let method_name = resolve_method_name(method_id);
// 3. ASTNodeを取得
let ast = instance.methods.get(&method_name)?;
// 4. インタープリターで実行（遅い！）
let result = interpreter.execute_method(instance, ast, args);
// 5. 結果をC ABIに変換
to_ny_result(result)
}
```
## 🚀 解決策の提案
### 案1: JITコンパイル（理想的だが複雑）
```rust
// ユーザーBox登録時にJITコンパイル
fn register_user_box(spec: &BoxSpec) -> TypeBox {
let compiled_methods = jit_compile_methods(&spec.methods);
TypeBox {
invoke_id: |self, id, args| {
compiled_methods[id](self, args)
}
}
}
```
### 案2: インタープリタートランポリン（現実的）
```rust
// グローバルなインタープリター参照を保持
static INTERPRETER: OnceCell<Arc<Interpreter>> = OnceCell::new();
extern "C" fn universal_user_box_invoke(
handle: u64, // ハンドル経由
method_id: u32,
args: *mut NyValue,
argc: c_int
) -> NyResult {
// ハンドルからBoxを取得
let registry = HANDLE_REGISTRY.read();
let instance = registry.get(handle)?;
// インタープリター経由で実行
INTERPRETER.get().unwrap().invoke_method(
instance, method_id, args, argc
)
}
```
### 案3: ハイブリッドアプローチ（段階的）
1. **Phase 1**: インタープリタートランポリン（すぐ実装可能）
2. **Phase 2**: 頻繁に呼ばれるメソッドをキャッシュ
3. **Phase 3**: AOT時にネイティブコード生成
## 📊 パフォーマンスへの影響
```
ビルトインBox呼び出し: 1-3ns
プラグインBox呼び出し: 10-15ns
ユーザーBox（トランポリン）: 100-200ns
ユーザーBox（JIT後）: 15-20ns
```
## 🎯 実装優先順位
1. **最小実装**（1週間）
- ハンドル経由のトランポリン
- グローバルインタープリター参照
- 基本的なメソッド呼び出し
2. **最適化**（2週間）
- メソッドIDキャッシュ
- 引数変換の効率化
- エラーハンドリング
3. **高速化**（1ヶ月）
- 簡易JITコンパイル
- AOT対応
- ネイティブコード生成
## 結論
ユーザーBoxをC ABIで渡すには、**インタープリター実行をトランポリン関数でラップ**する必要があります。これは性能上のオーバーヘッドがありますが、段階的に最適化可能です。

290
docs/private/roadmap/phases/phase-12/ai-consultation-unified-typebox.md Normal file
View File

@ -0,0 +1,290 @@
# 統一TypeBox ABI - AI先生たちの深い技術的検討
このドキュメントは、Gemini先生とCodex先生による統一TypeBox ABIの技術的検討をまとめたものです。
## 🎯 検討テーマ
ユーザー定義Boxをプラグインシステムに統合し、すべてのBoxをC ABI上で統一的に管理する提案について。
## 📅 相談日時
2025-09-02
## 🤖 Gemini先生の回答
### 総評：提案されたアプローチの技術的健全性
まず結論から申し上げると、提案されている「ユーザー定義Boxを動的に登録し、プラグインBoxと統一的に扱うABI」というアプローチは、**技術的に非常に健全（sound）**です。これは、COM（Component Object Model）、Rustの`dyn Trait`オブジェクト、PythonのC APIなど、多くの成功した言語やフレームワークで採用されている**動的ディスパッチ（vtable）**の仕組みを、FFI（Foreign Function Interface）に応用した古典的かつ堅牢な設計パターンです。
このアプローチにより、「Everything is Box」というNyashの美しい設計哲学を、言語の境界を越えたC ABIレベルまで一貫して適用することが可能になります。
### 技術的検討事項の詳細分析
#### 1. メモリ管理：誰がBoxの命を握るか？
* **課題**: NyashのVM（おそらくガベージコレクタ(GC)を持つ）と、Cで書かれたプラグイン側とで、Boxインスタンスの所有権をどう管理し、いつメモリを解放するかが最大の課題です。
* **解決策**: **参照カウント（Reference Counting）**が最も現実的で実績のある解決策です。
* **実装**:
1. `NyashTypeBox`構造体の先頭に参照カウンタ（`ref_count`）を持たせます。
2. NyashのVMがBoxへの参照を生成したとき、またはFFIを通じてプラグインにBoxのポインタを渡すときに、カウンタをインクリメントする`retain`関数（または`add_ref`）を呼び出します。
3. プラグイン側でBoxが不要になったとき、またはVMが参照を破棄するときに、カウンタをデクリメントする`release`関数を呼び出します。
4. `release`関数内でカウンタが0になったら、そのBoxが使用していたメモリを解放する処理（デストラクタの呼び出しなど）を実行します。
* **注意点**:
* **スレッド安全性**: マルチスレッド環境をサポートする場合、参照カウンタのインクリメント/デクリメントは**アトミック操作**である必要があります（例: C11の`_Atomic`やGCCの`__atomic_*`組み込み関数）。
* **循環参照**: 参照カウント方式の宿命ですが、2つのBoxが互いに参照し合うと、カウンタが0にならずメモリリークが発生します。これを解決するには**弱参照（Weak Reference）**の仕組みを併せて導入する必要があります。
#### 2. 型安全性：動的な世界で秩序を保てるか？
* **課題**: `void*`のような型消去されたポインタをやり取りするため、誤った型として扱ってしまう危険性（type confusion）があります。
* **解決策**: **実行時型情報（RTTI）**を導入します。
* **実装**:
1. 提案にある通り、各Boxに一意な`type_id`を割り当てます。このIDは、実行時に登録されるユーザー定義Boxも含め、衝突しないように動的に生成・管理されるべきです（例: 単純なカウンタやアドレスのハッシュなど）。
2. `NyashTypeBox`に`type_id`フィールドを持たせます。
3. 特定のBox型へのダウンキャストを行いたい場合は、まず`type_id`を比較する安全なAPI（例: `nyash_box_downcast_as_mybox(box)`）を提供します。このAPIは、IDが一致しない場合は`NULL`を返すようにします。これにより、危険な強制キャストを防ぎます。
* **哲学**: これは静的型付け言語のコンパイル時型チェックを、動的言語の実行時チェックで代替する考え方であり、Nyashの動的な性質と整合性が取れています。
#### 3. パフォーマンス：動的ディスパッチの代償は？
* **課題**: メソッドを呼び出すたびにメソッドテーブル（vtable）を介して間接的に呼び出すため、静的な関数呼び出しに比べてオーバーヘッドが生じます。
* **評価**:
* **許容範囲内**: このオーバーヘッドは通常、1回の呼び出しあたり数ナノ秒程度です。FFI呼び出し自体のコスト（引数のマーシャリングなど）や、プラグインが行うであろう処理（I/O、複雑な計算など）と比較すれば、**無視できるレベル**であることがほとんどです。
* **最適化**: NyashがJITコンパイラを持つ場合、呼び出しが単一の型に集中するようなホットスポットでは、投機的にインライン化（de-virtualization）することで、このオーバーヘッドを削減することも理論的には可能です。
* **結論**: 動的言語であるNyashにとって、このパフォーマンスコストは、得られる柔軟性と拡張性というメリットを考えれば、十分に許容できるトレードオフです。
#### 4. セキュリティ：信頼できないコードからの保護
* **課題**: 悪意のある、あるいはバグのあるユーザーBox/プラグインが、不正なメソッドポインタを登録することで、VMの内部状態を破壊したり、任意のコード実行（RCE）に繋がる可能性があります。
* **対策（多層防御）**:
1. **サンドボックス**: 最も強力な対策は、プラグインの実行環境をサンドボックス化することです。**WebAssembly (Wasm)** はこの目的で設計されており、優れた選択肢です。NyashのプラグインをWasmモジュールとしてコンパイルし、Wasmランタイム上で実行すれば、メモリ安全性が保証され、外部へのアクセスも厳密に制御できます。
2. **検証**: 登録されるメソッドテーブルの内容をある程度検証します。例えば、関数ポインタが実行可能メモリ領域を指しているかなどをチェックしますが、完全な対策にはなりません。
3. **権限モデル（Capability-based Security）**: プラグイン登録時に、そのプラグインがアクセスできるAPIやリソースを制限する権限セットを要求・付与する仕組みを導入します。
#### 5. 実装複雑度：既存システムとの調和
* **課題**: 既存のVM、GC、型システム、プラグインローダーと、この新しい統一ABIをスムーズに統合する必要があります。
* **評価**: **実装の複雑度は高い**です。特に以下の点が難所となります。
* **GCとの連携**: 参照カウントとGCを共存させる場合、両者の間でオブジェクトの生存情報を正しく伝達する必要があります。GCがオブジェクトを走査する際に、FFI境界を越えてプラグイン側にある参照を認識できるようにしなければなりません。
* **ABIの安定化**: 一度公開したC ABI（構造体のレイアウトや関数のシグネチャ）は、後方互換性を維持するために慎重に設計・管理する必要があります。
* **エラーハンドリング**: FFI境界を越えてエラー情報をどう伝播させるか、一貫した戦略が必要です（例: エラーコードを返す、`get_last_error`のような関数を用意する）。
### ご質問への回答
#### 1. この統一管理アプローチは技術的に健全か？
はい、前述の通り**極めて健全**です。実績のある設計パターンであり、Nyashの哲学を強化する正しい方向性です。
#### 2. 他の言語での類似実装例はあるか？
多数あります。これらは実装の際の優れた参考資料となります。
* **Python C API**: 全てのPythonオブジェクトは`PyObject*`としてCから扱われます。`PyObject`は参照カウントと型オブジェクトへのポインタ(`ob_type`)を持ち、この`ob_type`がメソッドテーブル（vtable）などを含む構造体を指しています。ユーザーがCで新しい型を定義し、Pythonの型システムに動的に登録する仕組みは、今回の提案と非常によく似ています。
* **Microsoft COM (Component Object Model)**: C++やVBなど異なる言語間でオブジェクトをやり取りするためのバイナリ互換仕様です。全てのインターフェースは`IUnknown`を継承し、`QueryInterface`（型キャスト）、`AddRef`（参照カウント増）、`Release`（参照カウント減）の3つのメソッドを必ず持ちます。
* **Rust `dyn Trait`**: Rustのトレイトオブジェクトは、データへのポインタとvtableへのポインタからなる「ファットポインタ」として実現されます。これをC ABIで表現しようとすると、手動でデータポインタとvtable構造体ポインタをペアにした構造体を作ることになり、本提案と同じ形になります。
#### 3. 実装上の注意点・落とし穴は？
* **ABIの厳密な定義**: 構造体のパディングやアライメント、呼び出し規約（calling convention）などをCレベルで厳密に定義し、ドキュメント化することが不可欠です。
* **参照カウントのバグ**: `retain`/`release`のペアが崩れると、即座にメモリリークやクラッシュに繋がります。デバッグを支援する仕組み（例: 環境変数を設定すると`retain`/`release`の呼び出しをログに出力するなど）が有効です。
* **スレッド安全性**: 最初からスレッドセーフに設計しないと、後からの修正は非常に困難です。`Arc<Mutex<...>>`のようなアトミック参照カウントと内部可変性のパターンを検討してください。
#### 4. より良い代替案はあるか？
* **WebAssembly (Wasm) ベースのプラグインシステム**: 前述の通り、セキュリティとポータビリティを最優先するならば、これが最良の選択肢かもしれません。NyashのBoxをWasmのメモリ空間とホスト（VM）間でやり取りするためのシリアライズ/デシリアライズ層が必要になりますが、Wasm Interface Typesなどの標準化も進んでおり、将来性が高いです。
* **IPC (プロセス間通信)**: プラグインを別プロセスとして実行し、ソケットやパイプで通信します。最も安全ですが、パフォーマンスのオーバーヘッドが大きいため、用途が限られます。
提案されているABI方式は、パフォーマンスと安全性のバランスが取れた優れた案であり、「より良い」というよりは「異なるトレードオフを持つ」代替案と言えます。
#### 5. Everything is Box哲学との整合性は完璧か？
**はい、完璧に整合します。**
この統一ABIは、「組み込みのBox」と「ユーザー定義のBox」という実装上の区別をユーザーやプラグイン開発者から完全に隠蔽します。全てのBoxが同じインターフェース（`NyashTypeBox*`）を通じて、同じ規則（参照カウント、動的ディスパッチ）に従って扱われる世界を実現します。これは、**「Everything is Box」という哲学を、言語仕様からABI、そしてエコシステム全体へと貫くための、論理的かつ必然的なステップ**と言えるでしょう。この実装が完了すれば、Nyashはより一貫性があり、強力で、拡張性の高い言語へと進化するはずです。
---
## 🤖 Codex先生の回答（タイムアウトしたが貴重な洞察）
Codex先生は深い分析を行い、以下の重要な洞察を提供しました：
### 主要な技術的提案
1. **ホスト管理型ハンドル**
- registry_id + instance_id のペアで管理
- 高ビットでホスト/プラグイン区別
2. **段階的実装戦略**
- Phase 1: 基本的な動的登録機能
- Phase 2: GCとの統合
- Phase 3: 完全な相互運用性
3. **セキュリティ考慮**
- ケイパビリティベースの権限管理
- finalizer IDによるライフサイクル管理
4. **ABI安定性**
- バージョニング戦略の重要性
- 既存プラグインとの互換性維持
---
## 🤖 Codex先生の深い技術検討（2025-09-02 詳細版）
### 統一TypeBox ABIの包括的技術設計
以下は「統一TypeBox ABI」を中核に据えた、Nyash Phase 12の技術的検討まとめです。C ABI上でBoxの一元管理を行い、Nyash ABIの基盤としてユーザーBoxまでカバーする実装方針を、実装設計・性能・安全性・移行計画まで通して具体化します。
### 📐 提案レイアウト（縮約）
#### NyBoxHeader（常に先頭・不変のバイナリ契約）
```c
struct NyBoxHeader {
uint64_t type_id; // 予約域＋種別域＋連番
_Atomic uint64_t refcnt; // 0で解放、MAXでpin
const NyTypeVTable* vtable; // 不変ポインタ
uint32_t flags; // immediate/extern/sandbox/trusted/traceable 等
uint32_t header_size; // 前方互換: 拡張時にサイズ確認
};
```
#### NyTypeVTable（固定順序・拡張可能）
- `retain(self)`, `release(self)`, `query(self, iface_id, out)`
- `trace(self, visitor)`（GC連携必須）
- `method_dispatch(self, method_id, args, ctx, out)`（最低限）
- `const NyMethod* methods` + `uint32_t method_count`
- `const NyField* fields`（任意）
#### NyMethod（C ABI呼び出し用）
- `uint32_t id`（スロット）、`NyCallSig sig_id`、`NyFnPtr fn`
#### NyValue（Everything is Boxの統一ハンドル）
- `union { NyBoxHeader* ptr; uint64_t tagged; }`（NaN-box/SMI対応）
- APIは常に`NyValue`で受け渡し
### 1. ユーザーBox動的登録
#### register_user_box()
```c
NyRegisterUserBox(const NyTypeSpec*, const NyMethodSpec*,
const NySecuritySpec*, NyTypeId* out_type_id)
```
- **TypeSpec**: サイズ、アライン、デストラクタ、トレース関数、初期化子
- **MethodSpec**: 名前→署名ID→関数ポインタの連想（登録時にスロット化）
- **SecuritySpec**: 信頼レベル、サンドボックス種類、許可シグネチャ群
#### Type ID管理
64-bit構造: `[8b domain | 8b vendor | 16b category | 32b serial]`
- **domain**:
- 0x00 = host(core)
- 0x40 = plugin(first-party)
- 0x80 = user(third-party)
- 0xC0 = experimental
- **vendor**: プラグイン/ユーザーのnamespace（nyash.tomlで予約・配布）
#### メソッドテーブル動的生成
- 登録時に「名前→署名ID→固定スロット」へ展開し、`NyTypeVTable.methods`を配列化
- 呼び出し側は「method_id（スロット）で直接インデックス」→ハッシュ探索不要
- 互換性: 古いプラグインは`method_dispatch`へフォールバック
### 2. メモリ管理の統一
#### 参照カウント（RC）
- `retain/release`はC ABIの最初の3メソッドとして固定（COM類似）
- `_Atomic u64`でインクリメント/デクリメント（Acquire/Releaseセマンティクス）
- 巨大グラフ/ホット経路は「ローカル借用カウント」最適化
#### GC協調
- `trace(self, visitor)`で内部参照列挙（プラグインも必須）
- NyRTは「世代別トレーサ＋RC」のハイブリッド
- 若世代: write barrier + remembered set、遅延スキャン
- 老世代: 主にRC管理、traceは周期的
#### 循環参照の検出・解決
- ベース: Trial Deletion（Bacon & Rajan）をバックグラウンドで実施
- 代替: 一部型に弱参照境界（Weak boundary）を要求
- プラグイン契約: traceの完全列挙必須
### 3. パフォーマンス最適化
#### メソッドID事前解決（33倍の根拠）
- **旧**: 名前→ハッシュ→テーブル探索→関数ポインタ（〜50-150ns）
- **新**: `methods[slot]`直参照（〜1-3ns）
- さらに分岐予測命中とICヒットで関数ポインタ直呼び（〜1ns台）
- 実測はワークロード依存だが、20-50×の改善が典型的
#### インラインキャッシング（IC）
- Monomorphic IC: `(type_id, method_sig)`→`fn*`をコールサイトに1エントリキャッシュ
- PIC（2-4型）で多相最適化、ミス時はスローペスへ
- Deopt hookあり（型再定義・ホットパッチ時に失効）
#### JIT連携
- コールサイトにパッチャブルスロットを持つ（NY_JITCALL）
- ウォームアップ後、`fn*`を直接inlining or tailcall化
- 署名IDに基づき引数マシャリング削減
### 4. セキュリティと安全性
#### 信頼レベル
- `trusted`（同プロセス・直接関数）
- `sandboxed`（Wasm/別プロセス）
- `restricted`（機能限定）
#### Wasmサンドボックス統合
- ユーザーBoxはWasmで実装→ホストは`NyTypeVTable`にWasmトランポリンを挿入
- メモリは共有しない（コピーor借用ハンドル）
- traceはホスト側のプロキシBoxで管理
#### メソッドポインタ検証
- 登録時: `fn*`が許可セクション（.text/EXEC）内か確認
- 実行時: CFIライト版（`type_id`一致＋`sig_id`一致＋レンジチェック）
- W^X徹底、PLT経由の間接跳躍制限、RELRO推奨
### 5. 実装の段階的アプローチ
#### 互換レイヤー
- 既存C ABIの`ny_*`関数は`method_dispatch`へフォールバック
- 新ABIでは事前解決スロットがあれば直参照
#### 移行ツール
- `ny-abi-gen`: ヘッダからスケルトン生成
- `ny-abi-check`: ローディング時にABIバージョン/署名整合性を検証
#### バージョニング
- `NY_ABI_VERSION`（major.minor.patch）
- `NyBoxHeader.header_size`で前方互換
- nyash.tomlに`min_abi`,`max_abi`を記載
### 技術的健全性の評価
**結論**: 技術的に健全。コアはCPython(PyObject)＋COM(IUnknown)＋Rust vtableの良いとこ取り
- 先頭に`refcnt`/`type`/`vtable`を固定し、関数テーブルによる静的ディスパッチを基本とする設計は長期安定性が高い
- GC協調には必須の`trace`を型契約に含め「逃げ道のない」完全列挙を強制
- `NyValue`（tagged/immediate）導入で「Everything is Box」を性能劣化なく実現可能
### 最大の課題
1. **ABI安定と最適化の両立**
- vtable拡張、署名IDの仕様固定、JITパッチ互換などを「一度決めて長期維持」する難しさ
2. **GC協調の完全性**
- プラグインのtrace不備がリーク/サイクル残留を引き起こす
3. **多様な信頼レベル混在**
- 同一プロセスのtrusted高速経路とWasm隔離経路の整合性
### 他言語との比較・ベストプラクティス
- **Python（CPython）**: ob_refcnt/ob_type/型メソッドテーブルは強力な実績
- **COM**: IUnknownの3メソッド固定は安定ABIの黄金則
- **Rust dyn Trait**: ABI非安定。NyashはC ABIでvtableを固定公開
### Everything is Boxの実現性
可能。推奨アプローチは二段：
- **実体**: `NyBoxHeader*`を持つヒープBox
- **即値**: NaN-box/SMIで`NyValue.tagged`にエンコード
APIは常に`NyValue`受け渡し。VM/JITは即値→ヒープBox化を必要時のみ実施
### 具体API（抄）
```c
extern "C" NyStatus NyRegisterUserBox(const NyTypeSpec*, const NyMethodSpec*,
const NySecuritySpec*, NyTypeId*);
extern "C" NyStatus NyResolveMethodSlot(NyTypeId, NySigId, uint32_t* out_slot);
extern "C" NyStatus NyCallSlot(NyValue self, uint32_t slot, const NyValue* args,
uint32_t argc, NyValue* out, NyCallCtx*);
extern "C" void NyRetain(NyValue);
extern "C" void NyRelease(NyValue); // 即値はno-op
```
### 次アクション案
1. `nyabi.h`ドラフトと最小実装
2. `register_user_box()`の仮実装＋スモーク
3. `ny-abi-gen`簡易版（署名→スロット表生成）
4. ICのmonomorphic実装→PIC→JITパッチの順に段階導入

195
docs/private/roadmap/phases/phase-12/archive/01_roadmap_final.md Normal file
View File

@ -0,0 +1,195 @@
# 埋め込みVM実装ロードマップ
## 🎯 目標：スクリプトプラグインのC ABI化
**Nyashスクリプト → C ABIプラグイン変換の完全自動化**
## 📊 技術スタック
```
[Nyashスクリプト]
↓ パース・型チェック
[MIR (中間表現)]
↓ 最適化・定数畳み込み
[MIRバイトコード]
↓ 埋め込み
[Cソースコード] ← nyash-to-c ツール
↓ コンパイル (cc/clang/gcc)
[.so/.dll/.a] ← 通常のプラグイン！
```
## 🚀 実装フェーズ
### Phase 12.1: 最小埋め込みVM（2-3週間）
#### 1. MIRバイトコード設計
```rust
// mir_bytecode.rs
pub enum CompactInstruction {
// 1バイト命令（頻出）
LoadLocal(u8), // 0x00-0x7F
StoreLocal(u8), // 0x80-0xFF
// 2バイト命令
LoadConst(u8), // 0x01 XX
Call(u8), // 0x02 XX
// 可変長
LoadString, // 0x03 [len:u16] [data]
Jump, // 0x04 [offset:i16]
}
```
#### 2. 埋め込みVMコア
```c
// nyash_embedded_vm.h
typedef struct {
const uint8_t* bytecode;
size_t bytecode_len;
// 実行時状態（最小）
void* stack[256];
int sp;
void* locals[16];
} NyashEmbeddedVM;
int32_t nyash_embedded_execute(
const uint8_t* bytecode,
size_t bytecode_len,
uint32_t method_id,
const uint8_t* args,
size_t args_len,
uint8_t* result,
size_t* result_len
);
```
### Phase 12.2: Nyash→Cトランスパイラー（3-4週間）
#### 1. 基本変換
```bash
$ nyash-to-c math_plugin.ny -o math_plugin.c
Generating C plugin from Nyash script...
- Parsing... OK
- Type checking... OK
- MIR generation... OK
- Bytecode emission... OK
- C code generation... OK
Output: math_plugin.c (2.3KB)
```
#### 2. 生成コード例
```c
// Generated from: math_plugin.ny
#include <nyash_embedded.h>
// MIRバイトコード（最適化済み）
static const uint8_t BYTECODE[] = {
0x01, 0x00, // Version 1.0
0x01, 0x00, // 1 function
// Function: cached_sin
0x00, 0x08, // Function header
0x80, 0x00, // StoreLocal 0 (x)
0x02, 0x10, // Call sin
0x90, // Return
};
// プラグインエントリポイント
extern "C" int32_t nyplug_math_plugin_invoke(
uint32_t type_id,
uint32_t method_id,
uint32_t instance_id,
const uint8_t* args,
size_t args_len,
uint8_t* result,
size_t* result_len
) {
return nyash_embedded_execute(
BYTECODE, sizeof(BYTECODE),
method_id,
args, args_len,
result, result_len
);
}
```
### Phase 12.3: 最適化とツールチェーン（4-6週間）
#### 1. ビルドシステム統合
```toml
# nyash.toml
[[plugins]]
name = "math_plugin"
source = "plugins/math_plugin.ny" # Nyashソース
type = "script" # 自動的にC変換
[[plugins]]
name = "file_plugin"
source = "plugins/file_plugin/Cargo.toml"
type = "native" # 従来のRustプラグイン
```
#### 2. 自動ビルドパイプライン
```bash
$ nyash build --plugins
Building plugins...
[1/2] math_plugin (script)
- Transpiling to C... OK
- Compiling... OK
- Output: target/plugins/libmath_plugin.so
[2/2] file_plugin (native)
- Building with cargo... OK
- Output: target/plugins/libfile_plugin.so
Done!
```
## 📈 パフォーマンス目標
| 操作 | ネイティブ | 埋め込みVM | 目標比率 |
|------|-----------|------------|----------|
| 単純計算 | 10ns | 50ns | 5x |
| メソッド呼び出し | 20ns | 100ns | 5x |
| 文字列操作 | 100ns | 200ns | 2x |
| I/O操作 | 10μs | 10.1μs | 1.01x |
## 🔧 開発ツール
### 1. デバッガ
```bash
$ nyash-debug math_plugin.ny --method cached_sin --args "[3.14]"
Executing cached_sin(3.14)...
[PC:0000] LoadLocal 0 ; x = 3.14
[PC:0002] Call sin ; sin(3.14)
[PC:0004] Return ; 0.0015926...
Result: 0.0015926
```
### 2. プロファイラ
```bash
$ nyash-profile math_plugin.so
Method statistics:
- cached_sin: 1000 calls, avg 120ns
- cached_cos: 500 calls, avg 115ns
Bottlenecks: None detected
```
## 🎉 最終形
```bash
# 開発者の体験
$ cat my_plugin.ny
export box MyPlugin {
init { cache = new MapBox() }
process(x) { return x * 2 }
}
$ nyash build my_plugin.ny
✓ Generated: my_plugin.so
$ nyash run --plugin my_plugin.so test.ny
✓ Plugin loaded (C ABI)
✓ Result: 42
```
**Nyashで書いて、どこでも動く！**

164
docs/private/roadmap/phases/phase-12/archive/02_spec_embedded_vm.md Normal file
View File

@ -0,0 +1,164 @@
# 解決策：埋め込みVMによるスクリプトプラグイン実現
## 💡 発想の転換
**制約は「リンク時にC ABIが必要」だけ。つまり、C ABI関数の中でVMを動かせばいい！**
## 🎯 アーキテクチャ
```c
// C ABI関数（静的リンク可能）
extern "C" int32_t nyplug_custom_math_invoke(
uint32_t method_id,
const uint8_t* args,
size_t args_len,
uint8_t* result,
size_t* result_len
) {
// 埋め込みVM起動
static NyashVM* embedded_vm = NULL;
if (!embedded_vm) {
embedded_vm = nyash_vm_create_minimal();
nyash_vm_load_script(embedded_vm, EMBEDDED_SCRIPT);
}
// スクリプト実行
return nyash_vm_invoke(embedded_vm, method_id, args, args_len, result, result_len);
}
// スクリプトは文字列リテラルとして埋め込み
static const char* EMBEDDED_SCRIPT = R"(
export box CustomMath {
cached_sin(x) {
// Nyashコード
}
}
)";
```
## 🔄 実現方法
### 1. Nyash→C トランスパイラー
```bash
# Nyashスクリプト → C関数
nyash-to-c custom_math.ny > custom_math_plugin.c
# 生成されるC
// custom_math_plugin.c
#include "nyash_embedded_vm.h"
static const char* SCRIPT = "..."; // Nyashコード埋め込み
extern "C" int32_t nyplug_custom_math_invoke(...) {
return nyash_embedded_invoke(SCRIPT, method_id, ...);
}
```
### 2. 最小VM実装
```rust
// crates/nyash-embedded-vm
pub struct EmbeddedVM {
// 最小限の実行環境
values: Vec<VMValue>,
// スクリプトはプリコンパイル済みMIR
mir: MirModule,
}
#[no_mangle]
pub extern "C" fn nyash_embedded_invoke(
script: *const c_char,
method_id: u32,
// ... TLV args/result
) -> i32 {
// MIR実行（インタープリター）
}
```
## 📊 利点と制約
### ✅ 可能になること
- **スクリプトプラグインがEXEに埋め込み可能**
- **JIT/AOTから呼び出し可能**（C ABI経由）
- **既存のプラグインシステムと完全互換**
### ⚠️ 制約
- **パフォーマンス**: 埋め込みVMのオーバーヘッド
- **サイズ**: 最小VMランタイムが必要（~500KB?）
- **機能制限**: フルVMの一部機能のみ
## 🚀 段階的実装
### Phase 1: 最小埋め込みVM
```rust
// 必要最小限の機能
- MIR実行（インタープリター）
- 基本型（Integer, String, Bool）
- メソッド呼び出し
- TLVエンコード/デコード
```
### Phase 2: Nyash→Cトランスパイラー
```nyash
// input: custom_math.ny
export box CustomMath {
sin(x) { ... }
}
// output: custom_math_plugin.c
extern "C" int32_t nyplug_custom_math_invoke(...) {
static const uint8_t MIR_BYTECODE[] = { ... };
return nyash_embedded_execute(MIR_BYTECODE, ...);
}
```
### Phase 3: 最適化
- MIRプリコンパイル
- 頻出パスのネイティブ化
- 選択的JITコンパイル
## 💡 実装例
```c
// 生成されたプラグイン
#include <nyash_embedded.h>
// MIRバイトコード（事前コンパイル）
static const uint8_t CUSTOM_MATH_MIR[] = {
0x01, 0x00, // version
0x10, 0x00, // function count
// ... MIR instructions
};
extern "C" int32_t nyplug_custom_math_abi_version() {
return 1;
}
extern "C" int32_t nyplug_custom_math_invoke(
uint32_t method_id,
const uint8_t* args,
size_t args_len,
uint8_t* result,
size_t* result_len
) {
// 埋め込みVM実行
return nyash_mir_execute(
CUSTOM_MATH_MIR,
sizeof(CUSTOM_MATH_MIR),
method_id,
args, args_len,
result, result_len
);
}
```
## 🎯 結論
**「リンク時にC ABI」という制約は、埋め込みVMで解決可能！**
- Nyashスクリプト → MIR → Cコード → ネイティブプラグイン
- 開発の容易さ（Nyash）と配布の利便性（C ABI）を両立
- 既存のプラグインエコシステムと完全互換
これで「Everything is Box」が真に実現する！

142
docs/private/roadmap/phases/phase-12/archive/03_spec_box_arguments.md Normal file
View File

@ -0,0 +1,142 @@
# 埋め込みVMでの箱引数サポート
## 🎯 結論：完全にサポート可能
現在のMIR/VM/JIT/プラグインすべてで**箱は箱を引数にできる**仕組みが確立されており、埋め込みVMでも同じパターンで実装可能です。
## 📊 各層での箱引数の扱い
### 1. Nyashスクリプトレベル
```nyash
// 箱を引数に取るメソッド
box Processor {
process(inputBox, configBox) {
// inputBoxもconfigBoxも箱インスタンス
local data = inputBox.getData()
local settings = configBox.getSettings()
return me.transform(data, settings)
}
}
```
### 2. MIRレベル
```
; box1.process(box2, box3)
%4 = BoxCall %1.process(%2, %3)
```
### 3. 埋め込みVMでの実装
#### バイトコード表現
```c
// BoxCall命令: [op][dst][recv][method_id:2][argc][args...]
// 例: box1.process(box2, box3)
0x20 // OP_BOXCALL
0x04 // dst: %4
0x01 // recv: %1 (box1)
0x00 0x10 // method_id: 16 (process)
0x02 // argc: 2
0x02 // arg[0]: %2 (box2)
0x03 // arg[1]: %3 (box3)
```
#### 実行時処理
```c
// 埋め込みVMでの箱引数処理
int nyvm_execute_boxcall(NyashEmbeddedVM* vm, ...) {
// レシーバー取得
NyVMValue* recv = &vm->values[recv_idx];
// 引数をTLVエンコード
for (int i = 0; i < argc; i++) {
NyVMValue* arg = &vm->values[args[i]];
if (arg->type == NYVM_TYPE_HANDLE) {
// 箱引数はハンドルとしてエンコード
uint32_t type_id = get_type_id_from_handle(arg->value.h);
uint32_t inst_id = get_instance_id_from_handle(arg->value.h);
encode_handle(&tlv, type_id, inst_id);
} else {
// プリミティブ値
encode_primitive(&tlv, arg);
}
}
// C ABIプラグイン呼び出し
return nyash_plugin_invoke(...);
}
```
## 🔄 ハンドル管理の詳細
### 1. ハンドルレジストリ
```c
// グローバルハンドルテーブル
typedef struct {
uint32_t type_id; // Box型ID
uint32_t instance_id; // インスタンスID
uint8_t flags; // GC/所有権フラグ
} HandleEntry;
static HandleEntry g_handles[MAX_HANDLES];
// 新しい箱インスタンスの登録
uint64_t register_box_handle(uint32_t type_id, uint32_t instance_id) {
uint64_t handle = allocate_handle();
g_handles[handle] = (HandleEntry){
.type_id = type_id,
.instance_id = instance_id,
.flags = HANDLE_OWNED
};
return handle;
}
```
### 2. プラグイン間の箱共有
```c
// プラグインAが箱を返す
int plugin_a_create_box(uint8_t* result, size_t* result_len) {
// 新しい箱を作成
uint32_t type_id = 100; // CustomBox
uint32_t inst_id = create_instance();
// TLVエンコード
encode_handle(result, type_id, inst_id);
return 0;
}
// プラグインBが箱を受け取る
int plugin_b_process(const uint8_t* args, size_t args_len) {
// TLVデコード
uint32_t type_id, inst_id;
decode_handle(args, &type_id, &inst_id);
// 箱を使用
process_box(type_id, inst_id);
return 0;
}
```
## 💡 重要なポイント
### 1. 型安全性
- ハンドルには型情報（type_id）が含まれる
- 実行時の型チェックが可能
### 2. 所有権管理
- ハンドルは参照カウント or GC管理
- プラグイン間で安全に共有
### 3. 相互運用性
- ネイティブBox ↔ スクリプトBox間で透過的
- 同じハンドル機構を使用
## 🎯 結論
埋め込みVMでも：
1. **箱は箱を引数に取れる**（ハンドル経由）
2. **型情報を保持**（type_id）
3. **プラグイン間で共有可能**（instance_id）
4. **C ABIと完全互換**（TLVエンコード）
これにより、Nyashスクリプトで書いた高度なBoxコンポジションも、C ABIプラグインとして動作します！

115
docs/private/roadmap/phases/phase-12/archive/CRITICAL-ISSUE.md Normal file
View File

@ -0,0 +1,115 @@
# 🚨 AI議論の誤解：存在しない問題を解決しようとした記録
## 誤解の本質
**この文書は、AIたちが「スクリプトプラグイン」という存在しない問題を作り出し、複雑な解決策を提案した記録です。**
### 実際の事実
- Nyashスクリプト = 普通のユーザー定義Box
- ユーザー定義Boxは既に完璧に動作している
- 特別な仕組みは一切不要
## なぜこんな誤解をしたのか
**「プラグイン」という言葉に引っ張られて、C ABIの外部DLLのような特別な仕組みが必要だと思い込んでしまった。**
```
現実のフロー:
MIR → JIT → C関数呼び出し（固定アドレス）→ ネイティブコード実行
MIR → AOT → EXE内のC関数（静的リンク）→ ネイティブコード実行
不可能なフロー:
MIR → ??? → Nyashスクリプト実行（インタープリター必要）
```
## なぜスクリプトプラグインは動作しないのか
### 1. インタープリター依存
```nyash
// スクリプトプラグイン
export box CustomMath {
sin(x) { return me._math.sin(x) }
}
```
↓
**実行にはNyash VMが必要** → EXEに埋め込めない
### 2. 動的型システム
- C ABI: 静的型（i32, i64, double等）
- Nyashスクリプト: 動的型（Box）
- 型変換にはランタイムが必要
### 3. メモリ管理
- C ABI: 手動管理またはシンプルなGC
- Nyashスクリプト: Arc<Mutex<dyn NyashBox>>
- GC/参照カウント管理にランタイムが必要
## 実例：なぜFileBoxはC ABIなのか
```rust
// FileBoxプラグイン（ネイティブ）
#[no_mangle]
pub extern "C" fn nyash_plugin_invoke(...) -> i32 {
// 直接システムコール可能
// VMなしで動作
// EXEに静的リンク可能
}
```
対して、Nyashスクリプトは：
- VM必須
- 動的評価
- EXEに埋め込み不可
## 結論：Phase 12の方向転換が必要
### ❌ 不可能なこと
- スクリプトプラグインをJIT/AOTから直接呼び出し
- スクリプトプラグインをEXEに埋め込み
- ネイティブプラグインと完全に透過的な利用
### ✅ 可能なこと
1. **インタープリターモード限定**
- スクリプトプラグインはインタープリター実行時のみ
- 開発/プロトタイピング用途
2. **トランスパイル方式**
- Nyashスクリプト → C/Rust → ネイティブプラグイン
- ビルドステップが必要
3. **ハイブリッド実行**
- 開発時: スクリプトプラグイン（高速イテレーション）
- 本番時: ネイティブプラグイン（高性能）
## 修正された価値提案
### 開発フローの改善
```
1. アイデア → Nyashスクリプトでプロトタイプ
2. 動作確認 → インタープリターでテスト
3. 性能要求 → Rust/Cで再実装
4. 配布 → ネイティブプラグインとして
```
### 制限事項の明確化
- **JIT/AOT**: ネイティブプラグインのみ
- **インタープリター**: スクリプトプラグインも可
- **EXE生成**: ネイティブプラグインのみ含む
## 推奨アクション
1. **Phase 12の再定義**
- 「開発支援ツール」として位置づけ
- JIT/AOT統合は諦める
2. **ドキュメント修正**
- 制限事項を明確に記載
- 誤解を招く「透過的利用」を削除
3. **代替案の検討**
- Nyash→Rustトランスパイラー
- プラグインテンプレート生成ツール
---
**重要な教訓：C ABIの制約は、システムプログラミングの本質的な制約である。**

207
docs/private/roadmap/phases/phase-12/archive/EMBEDDED-VM-BOX-HANDLING.md Normal file
View File

@ -0,0 +1,207 @@
# 埋め込みVMでのBox処理設計
## 🎯 核心：MIRレベルでのBox処理を再現
### 現在のMIR/VMでのBox処理フロー
```
1. MIR: BoxCall/PluginInvoke命令
↓
2. VM: ValueId → VMValue変換
↓
3. VMValue → Box<dyn NyashBox> or TLVエンコード
↓
4. メソッド実行
↓
5. 結果をVMValueに戻す
```
## 📊 埋め込みVMの設計
### 1. 軽量VMValue定義
```c
// 埋め込みVM用の値表現
typedef enum {
NYVM_TYPE_INT,
NYVM_TYPE_FLOAT,
NYVM_TYPE_BOOL,
NYVM_TYPE_STRING,
NYVM_TYPE_HANDLE, // Box参照（ハンドル）
NYVM_TYPE_VOID
} NyVMType;
typedef struct {
NyVMType type;
union {
int64_t i;
double f;
uint8_t b;
struct { const char* data; size_t len; } s;
uint64_t h; // ハンドル（Box参照）
} value;
} NyVMValue;
```
### 2. MIRバイトコード形式
```c
// BoxCall命令のエンコード
enum {
OP_BOXCALL = 0x20,
OP_PLUGIN_INVOKE = 0x21,
// ...
};
// BoxCall: [op:1] [dst:1] [box_val:1] [method_id:2] [argc:1] [args...]
// 例: BoxCall %2 = %1.toString()
// → 0x20 0x02 0x01 0x00 0x00 0x00
```
### 3. 埋め込みVMでのBoxCall実行
```c
int nyvm_execute_boxcall(
NyashEmbeddedVM* vm,
uint8_t dst,
uint8_t box_val,
uint16_t method_id,
uint8_t argc,
uint8_t* args
) {
// 1. レシーバー取得
NyVMValue* recv = &vm->values[box_val];
// 2. プリミティブ型の場合
if (recv->type != NYVM_TYPE_HANDLE) {
// プリミティブ→TLV変換
uint8_t tlv_buf[256];
size_t tlv_len = encode_primitive_to_tlv(recv, tlv_buf);
// 組み込み実装を呼び出し
return call_builtin_method(recv->type, method_id, tlv_buf, tlv_len);
}
// 3. Box（ハンドル）の場合
uint64_t handle = recv->value.h;
// 引数をTLVエンコード
uint8_t args_tlv[1024];
size_t args_len = 0;
for (int i = 0; i < argc; i++) {
NyVMValue* arg = &vm->values[args[i]];
args_len += encode_value_to_tlv(arg, &args_tlv[args_len]);
}
// 4. プラグイン呼び出し（C ABI）
uint8_t result[4096];
size_t result_len = sizeof(result);
int rc = nyash_plugin_invoke(
get_type_id_from_handle(handle),
method_id,
get_instance_id_from_handle(handle),
args_tlv, args_len,
result, &result_len
);
// 5. 結果をVMValueに変換
if (rc == 0) {
decode_tlv_to_value(result, result_len, &vm->values[dst]);
}
return rc;
}
```
## 🔄 Box引数の処理
### 現在のVM（Rust）
```rust
// VMValue → Box<dyn NyashBox>変換
let val = self.get_value(*arg)?;
Ok(val.to_nyash_box())
```
### 埋め込みVM（C）
```c
// NyVMValue → TLVエンコード
switch (value->type) {
case NYVM_TYPE_INT:
encode_i64(tlv, value->value.i);
break;
case NYVM_TYPE_HANDLE:
encode_handle(tlv,
get_type_id_from_handle(value->value.h),
get_instance_id_from_handle(value->value.h)
);
break;
// ...
}
```
## 💡 実装のポイント
### 1. ハンドル管理
```c
// グローバルハンドルテーブル
typedef struct {
uint32_t type_id;
uint32_t instance_id;
void* native_ptr; // 実際のBoxポインタ（必要な場合）
} HandleEntry;
static HandleEntry g_handles[MAX_HANDLES];
static uint64_t g_next_handle = 1;
uint64_t register_handle(uint32_t type_id, uint32_t instance_id) {
uint64_t h = g_next_handle++;
g_handles[h].type_id = type_id;
g_handles[h].instance_id = instance_id;
return h;
}
```
### 2. 組み込みメソッド
```c
// 頻出メソッドは埋め込みVMに直接実装
int call_builtin_method(NyVMType type, uint16_t method_id, ...) {
switch (type) {
case NYVM_TYPE_INT:
if (method_id == 0) { // toString
// 整数→文字列変換
}
break;
// ...
}
}
```
### 3. プラグインとの統合
```c
// 生成されるCコード
extern "C" int32_t nyplug_mybox_invoke(...) {
// MIRバイトコード実行
NyashEmbeddedVM vm;
nyvm_init(&vm, BYTECODE, sizeof(BYTECODE));
// 引数をVMスタックに設定
nyvm_decode_args(&vm, args, args_len);
// メソッド実行
nyvm_execute_method(&vm, method_id);
// 結果をTLVエンコード
return nyvm_encode_result(&vm, result, result_len);
}
```
## 🎯 結論
埋め込みVMは：
1. **MIRのBoxCall/PluginInvoke命令を忠実に実装**
2. **TLVエンコード/デコードでC ABIと通信**
3. **ハンドルでBox参照を管理**
4. **頻出処理は最適化実装**
これにより、Nyashスクリプトで書いたプラグインも、ネイティブプラグインと同じC ABIで動作します！

102
docs/private/roadmap/phases/phase-12/archive/PLUGIN-BOX-ARG-DECLARATION.md Normal file
View File

@ -0,0 +1,102 @@
# プラグインBoxの箱引数宣言方法
## 📊 nyash_box.tomlでの宣言
### 1. 基本的な箱引数の宣言
```toml
[HttpRequestBox.methods.respond]
id = 3
args = [ { name = "resp", type = "box" } ] # type = "box" で箱引数を宣言
returns = { type = "void" }
```
### 2. 引数の型一覧
| 型指定 | 説明 | TLVタグ |
|--------|------|---------|
| `"i64"` | 64ビット整数 | 3 |
| `"f64"` | 64ビット浮動小数点 | 5 |
| `"string"` | UTF-8文字列 | 6 |
| `"bool"` | 真偽値 | 1 |
| `"box"` | **箱（ハンドル）** | 8 |
### 3. 実際の使用例
#### NetプラグインのHttpRequestBox
```toml
[HttpRequestBox]
type_id = 21
[HttpRequestBox.methods.respond]
id = 3
args = [ { name = "resp", type = "box" } ] # HttpResponseBoxを受け取る
returns = { type = "void" }
```
使用方法（Nyash）：
```nyash
local request = server.accept() // HttpRequestBox
local response = new HttpResponseBox() // 別のプラグインBox
response.setStatus(200)
request.respond(response) // 箱を引数として渡す！
```
#### 戻り値が箱の例
```toml
[HttpServerBox.methods.accept]
id = 3
args = []
returns = { type = "box" } # HttpRequestBoxを返す
```
## 🔧 C実装側での処理
### TLVデコード
```c
// HttpRequestBox.respondの実装例
case 3: { // respond
// 引数をデコード
if (args_len < 12) return -1; // header(4) + handle(8)
// TLVタグチェック
uint8_t tag = args[4];
if (tag != 8) return -1; // TAG_HANDLE = 8
// ハンドルデータ取得
uint32_t resp_type_id = *(uint32_t*)&args[8];
uint32_t resp_instance_id = *(uint32_t*)&args[12];
// HttpResponseBox（type_id=22）であることを確認
if (resp_type_id != 22) return -1;
// レスポンス処理...
}
```
## 💡 重要なポイント
### 1. 型安全性
- `type = "box"`は任意の箱を受け取れる
- 実装側で`type_id`チェックにより型安全性を確保
### 2. 相互運用性
- 異なるプラグイン間でも箱の受け渡しが可能
- ハンドル（type_id + instance_id）により参照
### 3. 宣言の簡潔さ
```toml
# シンプルな宣言
args = [ { name = "box_arg", type = "box" } ]
# 複数の箱引数も可能
args = [
{ name = "box1", type = "box" },
{ name = "box2", type = "box" },
{ name = "count", type = "i64" }
]
```
## 🎯 結論
プラグインBoxは`nyash_box.toml`で`type = "box"`と宣言するだけで、他の箱を引数に取ることができます。C ABIレベルではTLVハンドル（タグ8）として処理され、完全な相互運用性が実現されています。

115
docs/private/roadmap/phases/phase-12/archive/PLUGIN-BOX-HANDLE-SUPPORT.md Normal file
View File

@ -0,0 +1,115 @@
# プラグインBoxは既に箱を引数に取れる！
## 🎯 重要な発見
**プラグインBoxは既にC ABIレベルで箱を引数に取ることができます！**
## 📊 実装の詳細
### 1. TLVプロトコルでのハンドルサポート
```rust
// TLVタグ定義
const TAG_HANDLE: u8 = 8; // プラグインハンドル用
// ハンドルエンコード関数
pub fn plugin_handle(buf: &mut Vec<u8>, type_id: u32, instance_id: u32) {
buf.push(TAG_HANDLE);
buf.push(0u8); // reserved
buf.extend_from_slice(&(8u16).to_le_bytes()); // size = 8
buf.extend_from_slice(&type_id.to_le_bytes()); // 4 bytes
buf.extend_from_slice(&instance_id.to_le_bytes()); // 4 bytes
}
```
### 2. プラグイン呼び出し時の処理
```rust
// Nyashコード
box1.process(box2, box3)
// ↓ VM/プラグインローダーでの処理
for arg in args {
if let Some(p) = arg.as_any().downcast_ref::<PluginBoxV2>() {
// 箱引数はハンドルとしてエンコード
encode::plugin_handle(&mut tlv, p.type_id, p.instance_id);
}
// ... 他の型の処理
}
// ↓ C ABIプラグイン側
int32_t nyash_plugin_invoke(
uint32_t type_id,
uint32_t method_id,
uint32_t instance_id,
const uint8_t* args, // TLVエンコードされた引数
size_t args_len,
uint8_t* result,
size_t* result_len
) {
// TLVデコード
uint8_t tag;
uint32_t arg_type_id, arg_instance_id;
if (decode_handle(args, &tag, &arg_type_id, &arg_instance_id)) {
// ハンドル引数を処理
// arg_type_id と arg_instance_id で箱を特定
}
}
```
## 🔄 実際の使用例
### Nyashレベル
```nyash
// FileBoxがStringBoxを引数に取る例
local file = new FileBox()
local path = new StringBox("/tmp/test.txt")
file.open(path) // StringBox（プラグインBox）を引数に！
// ArrayBoxがMapBoxを引数に取る例
local array = new ArrayBox()
local map = new MapBox()
array.push(map) // MapBox（プラグインBox）を引数に！
```
### プラグイン間の相互運用
```nyash
// NetBoxがJSONBoxを引数に取る例
local net = new NetBox()
local json = new JSONBox()
json.set("url", "https://api.example.com")
net.post(json) // JSONBoxを引数として渡す
```
## 💡 重要なポイント
### 1. ハンドルによる間接参照
- 箱の実体は渡さない（メモリ安全性）
- `(type_id, instance_id)`のペアで識別
- プラグイン側でハンドルから実体にアクセス
### 2. 型安全性
- `type_id`で型を識別可能
- 不正な型の場合はエラー返却
### 3. 所有権管理
- インスタンスIDで参照管理
- プラグイン間でも安全に共有
## 🎯 結論
**C ABIの制約があっても、ハンドル機構により箱は箱を引数に取れる！**
これは既に実装済みの機能であり、プラグイン間での高度な連携が可能です。
### 埋め込みVMへの示唆
既存のTLVハンドル機構をそのまま使えば、埋め込みVMでも同じように箱引数をサポートできます：
1. Nyashスクリプト内で箱を引数に使用
2. MIRバイトコードにBoxCall命令を含める
3. 埋め込みVMがTLVエンコードでC ABIプラグインを呼び出し
4. ハンドル経由で箱を渡す
**Everything is Box、そしてC ABIでも箱は箱を扱える！**

232
docs/private/roadmap/phases/phase-12/archive/README.md Normal file
View File

@ -0,0 +1,232 @@
# Phase 12: プラグインシステムの進化 - 既存C ABIとの共存戦略
## 🚀 概要
**重要**: 既存のC ABIプラグインはそのまま使い続けられます！その上で、以下の2つの新機能を追加：
1. **Nyash ABIサポート** - より型安全で拡張性の高い新しいABI（オプション）
2. **Nyashスクリプトプラグイン** - ビルド不要でプラグイン作成可能
### なぜ既存C ABIを残すのか？
- **実績と安定性**: 現在動いているFileBox、NetBox等はそのまま
- **ゼロオーバーヘッド**: 高頻度呼び出しには最速のC ABI
- **段階的移行**: 必要に応じて選択的にNyash ABIへ移行可能
## 💡 発見の経緯
include/export仕様の検討中に、以下の重要な気づきが：
```nyash
# custom_math_plugin.ny
export box CustomMathPlugin {
init {
_math = new MathBox() # 既存プラグイン活用
_cache = new MapBox() # 結果キャッシュ
}
// カスタム拡張
cached_sin(x) {
local key = x.toString()
if me._cache.has(key) {
return me._cache.get(key)
}
local result = me._math.sin(x)
me._cache.set(key, result)
return result
}
}
```
これにより、Rust/C++のビルドなしでプラグイン開発が可能に！
## 🎯 ABI共存戦略 - 適材適所の選択
### 三層構造のプラグインエコシステム
```
1. C ABIプラグイン（既存・継続）
- FileBox, NetBox, MathBox等
- 高速・安定・実績あり
- 変更なし！そのまま使える
2. Nyash ABIプラグイン（新規追加）
- 型安全・拡張性重視の新規開発向け
- async/await対応などの将来機能
3. Nyashスクリプトプラグイン（革命的）
- ビルド不要・即座に開発
- 上記1,2を組み合わせて利用可能
```
### 使い分けの指針
| 用途 | 推奨ABI | 理由 |
|------|---------|------|
| 数値計算（高頻度） | C ABI | ゼロオーバーヘッド |
| ファイルI/O | C ABI | 既存実装が安定 |
| 複雑な型操作 | Nyash ABI | 型安全性重視 |
| プロトタイプ | Nyashスクリプト | 即座に試せる |
### 設定例（nyash.toml v2.1）
```toml
# nyash.toml v2.1
[plugin.math]
path = "plugins/math.so"
abi = "c" # 高速・安定（デフォルト）
[plugin.advanced_math]
path = "plugins/advanced_math.so"
abi = "nyash" # 型安全・拡張性
```
### BoxCall拡張による実装
**重要な発見**：MIR層の変更は不要！VM実行時の型判定で十分。
**Phase 12での追加発見**：PluginInvokeも不要！BoxCallに統合可能。
```rust
// MIR層：変更なし → さらにシンプルに（14命令へ）
MirInstruction::BoxCall {
receiver: Value,
method: String,
args: Vec<Value>,
}
// PluginInvoke は廃止（BoxCallに統合）
// VM層：賢い判定
fn execute_boxcall(...) {
let type_info = get_plugin_info(receiver.type_id);
match type_info.abi {
"c" => call_c_abi(...), // 既存プラグイン
"nyash" => call_nyash_abi(...), // 新プラグイン
}
}
```
### Nyash ABI仕様
```c
// 3×u64構造体による型安全な値渡し
typedef struct NyashValue {
uint64_t type_id; // 型識別子
uint64_t box_handle; // Boxハンドル
uint64_t metadata; // 拡張用（async flag等）
} NyashValue;
// 統一関数シグネチャ
typedef NyashValue (*NyashFunc)(
uint32_t argc,
NyashValue* args,
void* context
);
```
### 基本インターフェース（内部）
```rust
// Rust側の統一インターフェース
trait BoxInterface {
fn invoke(&self, method_id: u32, args: NyashValue) -> NyashValue;
fn get_methods(&self) -> Vec<MethodInfo>;
fn init(&mut self, ctx: Context);
fn drop(&mut self);
}
```
### Nyashスクリプトプラグインの要件
```nyash
export box MyPlugin {
// 必須：初期化
init { ... }
// 推奨：FFI互換インターフェース
invoke(method_id, args) {
// method_idに基づいてディスパッチ
}
// オプション：メソッド情報
get_methods() {
return [
{ name: "method1", id: 1 },
{ name: "method2", id: 2 }
]
}
}
```
## 📊 エコシステムへの影響
### 開発の民主化
- **参入障壁の劇的低下**: Rust/C++環境不要
- **即座の開発**: ビルド待ち時間ゼロ
- **コミュニティ拡大**: より多くの開発者が参加可能
### 新しい開発パターン
1. **プラグインの合成**: 複数のネイティブプラグインを組み合わせ
2. **ラピッドプロトタイピング**: アイデアを即座に実装
3. **ホットリロード**: 実行中の更新が可能
## 🛣️ 実装ロードマップ（2025-09-01更新）
**重要**: 既存のC ABIプラグインは一切変更不要！追加機能として実装します。
### Phase 12.1: ABI共存基盤（1週間）
- [ ] nyash.toml v2.1仕様（abi fieldサポート、デフォルト="c"）
- [ ] プラグインローダーのABI判定実装（後方互換性保証）
- [ ] VM execute_boxcallのABI分岐追加（C ABIは現状維持）
- [ ] 同一機能のC ABI / Nyash ABI比較ベンチマーク
### Phase 12.2: Nyash ABI基盤（2週間）
- [ ] NyashValue構造体定義（crates/nyrt/include/nyash_abi.h）
- [ ] pack/unpack関数実装
- [ ] 既存プラグイン1つをNyash ABI移行（実証実験）
- [ ] JIT最適化（型既知時の特化コード生成）
### Phase 12.3: スクリプトプラグイン対応（3週間）
- [ ] export box構文のパーサー実装
- [ ] BoxInterface trait実装
- [ ] NyashスクリプトのVM内実行環境
- [ ] 相互運用テスト（C/Nyash/Script混在）
### Phase 12.4: 動的機能とエコシステム（継続的）
- [ ] ホットリロード対応
- [ ] プラグイン間依存関係管理
- [ ] プラグインマーケットプレイス構想
- [ ] セキュリティサンドボックス
### 実装優先順位（短期）
1. **Week 1**: nyash.tomlのabi field + VM分岐（動作確認）
2. **Week 2**: 性能測定 + 方向性判断
3. **Week 3**: 本格実装 or 方針転換
## 📚 関連ドキュメント
### 初期設計
- [Gemini先生の分析](./gemini-analysis-script-plugins.md)
- [Codex先生の技術提案](./codex-technical-proposal.md)
- [統合分析まとめ](./synthesis-script-plugin-revolution.md)
### ABI戦略議論（2025-09-01）
- [議論まとめ](./abi-strategy-discussion/README.md)
- [Gemini先生のABI分析](./abi-strategy-discussion/gemini-abi-analysis.md)
- [Codex先生のABI実装戦略](./abi-strategy-discussion/codex-abi-implementation.md)
- [Codex先生のBoxCall拡張分析](./abi-strategy-discussion/codex-boxcall-extension-analysis.md)
- [深い分析と結論](./abi-strategy-discussion/deep-analysis-synthesis.md)
- [最終実装決定](./abi-strategy-discussion/final-implementation-decision.md)
## 🎯 次のアクション（優先順位順）
1. nyash.toml v2.1パーサーに`abi` field追加（Day 1-2）
2. VM execute_boxcallでABI判定分岐実装（Day 3-4）
3. SimpleMathプラグインで両ABI比較テスト（Day 5-6）
4. ベンチマーク結果に基づく方向性判断（Day 7）
### 将来的なアクション
- Nyash ABI仕様書（nyash_abi.h）作成
- export box構文の実装
- プラグインSDK（#[nyash_plugin]マクロ）開発
---
*Everything is Box - そしてプラグインもBoxになる！*

147
docs/private/roadmap/phases/phase-12/archive/REVISED-PROPOSAL.md Normal file
View File

@ -0,0 +1,147 @@
# Phase 12（改訂版）：Nyashスクリプトプラグイン - 開発支援ツールとして
## 🎯 現実的な位置づけ
**スクリプトプラグインは、JIT/AOT/EXEとは独立した開発支援機能として実装する。**
## 📊 制約と可能性の整理
### ❌ できないこと（技術的制約）
- MIR/VM/JIT/AOTからのスクリプトプラグイン呼び出し
- スクリプトプラグインのEXE埋め込み
- ネイティブプラグインとの完全な相互運用性
### ✅ できること（現実的な価値）
- インタープリターモードでの高速プロトタイピング
- 既存プラグインの組み合わせによる新機能開発
- ビルド不要な機能拡張（開発時のみ）
## 🔄 修正された開発フロー
```
┌─────────────────┐
│ アイデア/要件 │
└────────┬────────┘
↓
┌─────────────────┐
│ Nyashスクリプト │ ← 高速イテレーション
│ プラグイン作成 │ ビルド不要
└────────┬────────┘
↓
┌─────────────────┐
│ インタープリター│
│ でテスト/検証 │
└────────┬────────┘
↓
性能要求？
↙ ↘
No Yes
↓ ↓
そのまま Rust/Cで
使用 再実装
↓
ネイティブ
プラグイン
↓
JIT/AOT/EXE
```
## 📝 実装方針
### 1. インタープリター専用機能として実装
```nyash
// script_plugin.ny
export box CustomLogic {
init {
_math = new MathBox() // ネイティブプラグイン利用
_cache = new MapBox()
}
process(data) {
// 複雑なビジネスロジック
// インタープリターでのみ実行
}
}
```
### 2. 明確な使用場面の区別
```nyash
// development.ny（開発時）
local plugin = include("custom_logic.ny") // ✅ OK
// production.ny（本番時）
local plugin = new CustomLogicBox() // ネイティブ版を使用
```
### 3. トランスパイル支援ツール（将来）
```bash
# Nyashスクリプト → Rustテンプレート生成
nyash-to-rust custom_logic.ny > custom_logic_plugin/src/lib.rs
```
## 🎯 価値提案（修正版）
### 開発者にとっての価値
1. **探索的プログラミング** - アイデアを即座に試せる
2. **プロトタイピング** - ビルドなしで機能検証
3. **学習曲線の緩和** - Rust/C知識不要で拡張開発
### エコシステムへの貢献
1. **アイデアの具現化** - スクリプトで検証→ネイティブで実装
2. **コミュニティ参加** - より多くの開発者が貢献可能
3. **ベストプラクティス** - 成功パターンの蓄積
## 🚀 実装計画（現実的版）
### Phase 12.1: 基盤構築（2週間）
- [ ] export box構文（インタープリター専用）
- [ ] include()関数の拡張
- [ ] 基本的なプラグインレジストリ
### Phase 12.2: 開発体験向上（3週間）
- [ ] ホットリロード（開発モード）
- [ ] エラーメッセージ改善
- [ ] デバッグ支援機能
### Phase 12.3: 移行支援（4週間）
- [ ] パフォーマンス分析ツール
- [ ] Rust変換テンプレート
- [ ] 移行ガイドライン
## 📚 ドキュメント戦略
### 明確な制約の説明
```markdown
# Nyashスクリプトプラグイン
⚠️ **重要な制約**
- インタープリターモードでのみ動作
- JIT/AOT/EXEでは使用不可
- 本番環境ではネイティブプラグインへの移行推奨
```
### 使用例の充実
- プロトタイピング例
- ネイティブ移行例
- パフォーマンス比較
## 🎉 期待される成果（現実的版）
### 短期（3ヶ月）
- 開発効率の向上（プロトタイピング時間80%削減）
- 新規開発者の参入（Rust不要）
- アイデア検証の高速化
### 中期（1年）
- 成功パターンの確立
- ネイティブプラグインの品質向上
- コミュニティ主導の機能提案増加
## 結論
**スクリプトプラグインは、C ABIの制約を認識した上で、開発支援ツールとして大きな価値を提供できる。**
「Everything is Box」の哲学は、実行時の制約はあれど、開発時の自由度として実現される。

175
docs/private/roadmap/phases/phase-12/archive/c-abi-compatibility.md Normal file
View File

@ -0,0 +1,175 @@
# C ABIとの整合性：Phase 12スクリプトプラグインシステム
## 🚨 重要な発見
Phase 10.1で既に**C ABI v0**が定義されており、これとPhase 12の提案を整合させる必要があります。
## 📊 現状のC ABI（Phase 10.1）
### 既存のBID-FFI（プラグイン用）
```c
// 現在のプラグインFFI（TLVベース）
extern "C" fn nyash_plugin_invoke(
type_id: u32,
method_id: u32,
instance_id: u32,
args: *const u8, // TLVエンコード
args_len: usize,
result: *mut u8, // TLVエンコード
result_len: *mut usize,
) -> i32
```
### 新しいNyRT C ABI v0
```c
// コア関数
int32_t nyrt_abi_version(void);
NyBox nyrt_box_new(uint64_t typeid, uint64_t size);
void nyrt_box_free(NyBox b);
// プラグイン関数（例：Array）
int32_t nyplug_array_abi_version(void);
NyBox nyplug_array_new(void);
int32_t nyplug_array_get(NyBox arr, uint64_t i, NyBox* out);
```
## 🎯 Phase 12の修正案
### 問題点
- Gemini/Codexの提案した`BoxInterface`トレイトは**Rust専用**
- C ABIとの相互運用性が考慮されていない
- TLVエンコーディングとの整合性が不明
### 解決策：C ABIラッパー戦略
```rust
// ❌ 元の提案（Rust専用）
trait BoxInterface {
fn invoke(&self, method_id: u32, args: NyashValue) -> NyashValue;
}
// ✅ 修正案（C ABI互換）
pub struct ScriptPluginWrapper {
// Nyashスクリプトインスタンス
script_box: NyashValue,
// C ABI互換性のためのFFI関数
ffi_invoke: extern "C" fn(
type_id: u32,
method_id: u32,
instance_id: u32,
args: *const u8,
args_len: usize,
result: *mut u8,
result_len: *mut usize,
) -> i32,
}
impl ScriptPluginWrapper {
// 既存のBID-FFIと完全互換
pub extern "C" fn invoke_ffi(
&self,
type_id: u32,
method_id: u32,
instance_id: u32,
args: *const u8,
args_len: usize,
result: *mut u8,
result_len: *mut usize,
) -> i32 {
// 1. TLVデコード
let nyash_args = decode_tlv(args, args_len);
// 2. Nyashスクリプト呼び出し
let result_value = self.script_box.invoke(method_id, nyash_args);
// 3. TLVエンコード
encode_tlv(result_value, result, result_len)
}
}
```
## 🔄 統合アーキテクチャ
```
[JIT/AOT] ---> C ABI (nyrt_*/nyplug_*) --+--> [ネイティブプラグイン]
|
+--> [ScriptPluginWrapper] --> [Nyashスクリプト]
```
### 利点
1. **完全な後方互換性** - 既存のプラグインがそのまま動作
2. **統一されたFFI** - JIT/AOT/プラグインすべて同じC ABI
3. **透過的な利用** - 呼び出し側はネイティブ/スクリプトを区別しない
## 📝 実装修正案
### Phase 12.1（修正版）
1. **ScriptPluginWrapperの実装**
- BID-FFI互換のC関数エクスポート
- TLVエンコード/デコード処理
- Nyashスクリプトへの橋渡し
2. **プラグインレジストリ拡張**
```rust
pub struct PluginRegistry {
// 既存のネイティブプラグイン（C ABI）
native_plugins: HashMap<u32, PluginHandle>,
// スクリプトプラグイン（C ABIラッパー経由）
script_plugins: HashMap<u32, ScriptPluginWrapper>,
}
```
3. **export box構文の実装**
```nyash
export box CustomMathPlugin {
// BID-FFI互換のためのメタ情報
__type_id__ = 100 // 動的割り当てor設定ファイル
__methods__ = {
"cached_sin": 1,
"cached_cos": 2
}
// 通常のNyashコード
init { ... }
cached_sin(x) { ... }
}
```
## 🚀 移行パス
### 段階1：既存プラグインの動作確認
- FileBox、NetBox等がC ABI経由で正常動作
- パフォーマンステスト
### 段階2：簡単なスクリプトプラグイン
- MathBoxの一部機能をNyashで再実装
- C ABIラッパー経由での動作確認
### 段階3：高度な統合
- ネイティブとスクリプトの混在
- 動的ロード/アンロード
## ⚡ パフォーマンス影響
```
呼び出しチェーン:
1. JIT → C ABI関数呼び出し（既存）
2. C ABI → ScriptPluginWrapper（追加）
3. Wrapper → TLVデコード（追加）
4. Wrapper → Nyashスクリプト実行（追加）
5. Wrapper → TLVエンコード（追加）
予想オーバーヘッド: 100-500ns/呼び出し
```
## 🎯 結論
Phase 12のスクリプトプラグインシステムは、**C ABIを尊重**しつつ実装可能です。
- BoxInterfaceトレイトは内部実装詳細に留める
- 外部インターフェースは既存のC ABI（BID-FFI）を維持
- ScriptPluginWrapperがブリッジとして機能
これにより、**「Everything is Plugin」**の哲学を保ちながら、スクリプトプラグインを実現できます。

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