fix(joinir): Phase 241-EX - Remove hardcoded 'sum' check from Pattern3
Remove legacy hardcoded 'sum' carrier validation that was blocking array_filter patterns with different accumulator names (e.g., 'out'). Before: Pattern3 required carrier named 'sum' to exist After: Pattern3 uses carrier_info generically (any carrier name works) Test results: - phase49_joinir_array_filter_smoke: PASS ✅ - phase49_joinir_array_filter_fallback: PASS ✅ - phase49_joinir_array_filter_ab_comparison: PASS ✅ - Full suite: 909/909 PASS, 0 FAIL Also: Archive old roadmap documentation (67k lines moved to docs/archive/) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
nyash-codex
67
docs/archive/roadmap/phases/phase-16/README.md
Normal file
67
docs/archive/roadmap/phases/phase-16/README.md
Normal file
@ -0,0 +1,67 @@
|
||||
# Phase 16: 折りたたみ言語（FoldLang）- Box世界の合成最適化
|
||||
|
||||
## 📋 概要
|
||||
|
||||
セルフホスティング達成後の次なる進化フェーズ。
|
||||
Nyashの「Everything is Box」哲学を維持しながら、実用的な実行速度を実現する革新的最適化層。
|
||||
|
||||
## 🎯 フェーズの目的
|
||||
|
||||
1. **Box境界を越えた最適化**: 複数のBox操作を1つに融合
|
||||
2. **デバッグ容易性の維持**: unfoldでいつでも元に戻せる
|
||||
3. **実用速度の実現**: 30-40%の性能改善
|
||||
4. **MIR15の単純性維持**: 命令追加なしで最適化
|
||||
|
||||
## 📊 主要成果物
|
||||
|
||||
- [ ] 純度属性システム（#[ny.pure]等）
|
||||
- [ ] FoldPass実装（BoxCall融合エンジン）
|
||||
- [ ] Fold Inspector（可視化ツール）
|
||||
- [ ] unfoldデバッグモード
|
||||
- [ ] 性能ベンチマークスイート
|
||||
|
||||
## 🔧 技術的アプローチ
|
||||
|
||||
### 中核アイデア
|
||||
```
|
||||
従来: Box境界 = 最適化の壁
|
||||
FoldLang: Box境界 = 最適化の単位
|
||||
```
|
||||
|
||||
### 実装例
|
||||
```nyash
|
||||
# ユーザーコード（変わらない）
|
||||
result = data.map(f).filter(p).map(g)
|
||||
|
||||
# 内部で自動融合
|
||||
# 3回のループ → 1回のループ
|
||||
# 3回のアロケーション → 1回のアロケーション
|
||||
```
|
||||
|
||||
## 🔗 関連ドキュメント
|
||||
|
||||
- [折りたたみ言語設計詳細](fold-lang-design.txt)
|
||||
- [Phase 15: セルフホスティング](../phase-15/)
|
||||
- [Phase 12.5: 最適化戦略](../phase-12.5/)
|
||||
|
||||
## 📅 実施時期
|
||||
|
||||
- **開始条件**: Phase 15（セルフホスティング）完了後
|
||||
- **推定開始**: 2026年後半
|
||||
- **推定期間**: 3-4ヶ月
|
||||
|
||||
## 💡 期待される成果
|
||||
|
||||
1. **性能改善**: Array/String操作で30-40%高速化
|
||||
2. **メモリ効率**: 中間オブジェクト削減で50%改善
|
||||
3. **GC負荷軽減**: オブジェクト生成数1/3
|
||||
4. **開発体験**: デバッグ時は自動unfold
|
||||
|
||||
## 🌟 なぜPhase 15の後か？
|
||||
|
||||
1. **複雑性の分離**: まず動くものを、次に速いものを
|
||||
2. **ドッグフーディング**: Nyashで最適化を書く
|
||||
3. **明確な成功基準**: 各フェーズで達成感
|
||||
|
||||
> 「折りたたみ言語 = Box世界の合成最適化層」
|
||||
> ChatGPT5による革新的提案（2025-09-01）
|
||||
181
docs/archive/roadmap/phases/phase-16/fold-lang-design.txt
Normal file
181
docs/archive/roadmap/phases/phase-16/fold-lang-design.txt
Normal file
@ -0,0 +1,181 @@
|
||||
================================================================================
|
||||
Phase 16: 折りたたみ言語（FoldLang）設計 - ChatGPT5提案
|
||||
================================================================================
|
||||
|
||||
【概要】
|
||||
セルフホスティング達成後の次なる進化。
|
||||
"Everything is Box"を土台に、等価変換でプログラムを畳む/展開する最適化層。
|
||||
MIR15は増やさず、BoxCall列を書き換えるだけで実用速度を実現。
|
||||
|
||||
================================================================================
|
||||
1. コア思想（Fold = 等価変換の一段）
|
||||
================================================================================
|
||||
|
||||
■ 公理（Fold Laws）
|
||||
├─ 等価性: unfold(fold(P)) = P（trace_hash/heap_hash一致）
|
||||
├─ 安全点保持: 折畳み後もsafepoint（入口/背縁/await前後）を保存
|
||||
└─ 純度境界: #[ny.pure] / #[ny.readonly] / #[ny.nothrow] の範囲のみ自動融合
|
||||
|
||||
■ 層構造
|
||||
Nyash → MIR15 → (FoldPass/FIR) → {VM/Clif/LLVM/x86}
|
||||
└─ MIRは増やさず、BoxCall列を書き換えるだけ
|
||||
|
||||
================================================================================
|
||||
2. 何が畳める？（期待できる進化）
|
||||
================================================================================
|
||||
|
||||
■ A. データ・ストリーム融合（Map/Filter/Reduce）
|
||||
├─ 連鎖したBoxCallを1回に畳む（配列/文字列/マップ/JSON）
|
||||
├─ 例: arr.map(f).filter(p).map(g) → arr.fused([Map(f), Filter(p), Map(g)])
|
||||
└─ 効果: Box境界・アロケーション・バリア回数を削減（P95 -10〜40%期待）
|
||||
|
||||
■ B. 非同期の塊化（構造化並行）
|
||||
├─ TaskGroup.spawn(..)* → joinAll() を1グループ命令に畳む
|
||||
└─ await前後のsafepointは保持、キャンセル/タイムアウトを最短経路で扱う
|
||||
|
||||
■ C. GUI/シーン構築の一括ビルド
|
||||
├─ Scene.add(Button).add(Label).add(Grid…) → Scene.fused(buildlist)
|
||||
└─ 初期描画を1回に集約（レイアウト/フォント測定をまとめて実行）
|
||||
|
||||
■ D. I/Oバッチ化
|
||||
├─ FileBox.read(x).read(y).read(z) → FileBox.readv([x,y,z])
|
||||
└─ SocketBox.send(a).send(b) → sendv([a,b])
|
||||
|
||||
■ E. ループ域内の局所折りたたみ
|
||||
├─ ループ本体の純パスだけを畳み、背縁safepointを残す
|
||||
└─ 例: for x in arr { y = g(f(x)) } # g∘fを一体化
|
||||
|
||||
================================================================================
|
||||
3. 安全ガード（壊れないための制約）
|
||||
================================================================================
|
||||
|
||||
■ 副作用検出
|
||||
└─ #[ny.may_write(box=…)] 等の注釈が付いた経路は折畳み対象外
|
||||
|
||||
■ バリア規律
|
||||
└─ barrier_{read,write} の相対順序を保持（Lowererが再挿入可能）
|
||||
|
||||
■ 観測可能性
|
||||
└─ --unfold でいつでも展開実行に切替（デバッグ容易）
|
||||
|
||||
■ しきい値制御
|
||||
└─ P95 +3% を超えたら自動で折畳みOFF（Fold Budget）
|
||||
|
||||
================================================================================
|
||||
4. ツールとメトリクス
|
||||
================================================================================
|
||||
|
||||
■ Fold Inspector
|
||||
└─ before/after のBoxCall DAG・削減率・safepoint位置を可視化
|
||||
|
||||
■ Fold Budget
|
||||
└─ 実行時に効果を測って自動ON/OFF（回帰防止）
|
||||
|
||||
■ Unfold-on-error
|
||||
└─ 例外発生時は即展開で再実行（原因特定用）
|
||||
|
||||
================================================================================
|
||||
5. 実装ロードマップ（段階導入）
|
||||
================================================================================
|
||||
|
||||
■ v0（1–2週）
|
||||
├─ 対象: Array.map/filter/map など純関数パイプ（長さ≤3）
|
||||
├─ 仕組み: 属性タグ収集 → 連鎖検出 → fused([...]) 置換 → NyRT ny_array_fused へ
|
||||
└─ テスト: trace/heap_hash 一致、gc=sync/stress(k) 緑
|
||||
|
||||
■ v1
|
||||
├─ ループ内の局所折畳み（背縁safepointを保持）
|
||||
└─ I/Oのreadv/sendvバッチ化
|
||||
|
||||
■ v2
|
||||
├─ TaskGroup の塊化（spawn*→joinAll）
|
||||
├─ GUI初期構築の一括ビルド
|
||||
└─ --unfold と Inspector を標準同梱
|
||||
|
||||
================================================================================
|
||||
6. Nyash側APIの薄い拡張（MIRそのまま）
|
||||
================================================================================
|
||||
|
||||
■ 属性
|
||||
├─ #[ny.pure] # 副作用なし、参照透明
|
||||
├─ #[ny.readonly] # 読み取りのみ、状態変更なし
|
||||
├─ #[ny.nothrow] # 例外を投げない
|
||||
├─ #[ny.fold(barrier="keep")] # 折畳み制御
|
||||
└─ #[ny.unfold] # デバッグ用展開強制
|
||||
|
||||
■ FIR（内部表現）ノード
|
||||
└─ Fused(BoxId, [Op…])（ただのBoxCallの糖）
|
||||
|
||||
■ NyRT追加
|
||||
├─ ny_array_fused
|
||||
├─ ny_scene_fused
|
||||
└─ ny_io_readv/sendv
|
||||
|
||||
================================================================================
|
||||
7. 具体イメージ（最小のv0例）
|
||||
================================================================================
|
||||
|
||||
# ユーザーコード
|
||||
let out = arr.map(f).filter(p).map(g)
|
||||
|
||||
# MIR15（概念）
|
||||
%a1 = BoxCall Array.map [%arr, %f]
|
||||
%a2 = BoxCall Array.filter [%a1, %p]
|
||||
%a3 = BoxCall Array.map [%a2, %g]
|
||||
|
||||
# FoldPass v0
|
||||
%fused = BoxCall Array.fused [%arr, [Map(f), Filter(p), Map(g)]]
|
||||
|
||||
================================================================================
|
||||
8. 効果予測（現実的な数値）
|
||||
================================================================================
|
||||
|
||||
■ Array操作
|
||||
├─ アロケーション削減により30-40%高速化
|
||||
├─ メモリ使用量: 中間配列削除で50%削減
|
||||
└─ GC圧力: Box生成数が1/3になり、GC頻度低下
|
||||
|
||||
■ ループ処理
|
||||
├─ ループ回数削減により実行時間1/3
|
||||
└─ キャッシュ効率向上
|
||||
|
||||
■ 非同期処理
|
||||
├─ コンテキストスイッチ削減
|
||||
└─ レイテンシ改善
|
||||
|
||||
================================================================================
|
||||
9. セルフホスティング後に実装する理由
|
||||
================================================================================
|
||||
|
||||
1. 複雑性の分離
|
||||
- セルフホスティングは「動くこと」が最優先
|
||||
- 最適化は「速くすること」が目的
|
||||
- 混ぜると両方失敗するリスク
|
||||
|
||||
2. ドッグフーディング
|
||||
- Nyashで最適化パスを書く
|
||||
- 言語の表現力を証明
|
||||
- コミュニティが貢献しやすい
|
||||
|
||||
3. 段階的成功
|
||||
- Phase 15: 動くコンパイラ（15,000行）
|
||||
- Phase 16: 速いコンパイラ（+3,000行）
|
||||
- 各段階で明確な成果
|
||||
|
||||
================================================================================
|
||||
10. まとめ
|
||||
================================================================================
|
||||
|
||||
折りたたみ言語 = "Box世界の合成最適化層"
|
||||
|
||||
- MIR15は増やさない
|
||||
- BoxCall列を等価変換で融合
|
||||
- 必要ならいつでもunfold
|
||||
- 効果は速度×省メモリ×デバッグ容易
|
||||
|
||||
Nyashの「箱理論」を実用速度へ直結する次のステップ。
|
||||
セルフホスティング達成後の楽しみ！
|
||||
|
||||
================================================================================
|
||||
注記: ChatGPT5による革新的提案（2025-09-01）
|
||||
================================================================================
|
||||
139
docs/archive/roadmap/phases/phase-16/implementation-notes.txt
Normal file
139
docs/archive/roadmap/phases/phase-16/implementation-notes.txt
Normal file
@ -0,0 +1,139 @@
|
||||
================================================================================
|
||||
Phase 16: 折りたたみ言語 実装メモ
|
||||
================================================================================
|
||||
|
||||
【実装上の重要な判断】
|
||||
|
||||
1. セルフホスティング後に実装する理由
|
||||
- 混ぜると危険（複雑性の爆発）
|
||||
- 目標のブレを防ぐ
|
||||
- テストの組み合わせ爆発を避ける
|
||||
|
||||
2. Nyashで実装することの意義
|
||||
- ドッグフーディングの極致
|
||||
- 15,000行のコードベースなら理解しやすい
|
||||
- コミュニティが貢献しやすい
|
||||
|
||||
================================================================================
|
||||
実装の技術的詳細
|
||||
================================================================================
|
||||
|
||||
■ SimpleFoldPass（最小実装案）
|
||||
```rust
|
||||
// もしRustで書くなら（参考実装）
|
||||
pub struct SimpleFoldPass;
|
||||
|
||||
impl SimpleFoldPass {
|
||||
pub fn run(&mut self, mir: &mut MIRModule) -> bool {
|
||||
// Array.map().filter().map()だけを検出
|
||||
// 3連鎖まで
|
||||
// ArrayBoxのみ対象
|
||||
// 純関数判定は決め打ち
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
■ Nyashでの実装イメージ
|
||||
```nyash
|
||||
box FoldPass {
|
||||
init { patterns, purity_db }
|
||||
|
||||
detectChains(mir) {
|
||||
local chains
|
||||
chains = new ArrayBox()
|
||||
|
||||
# BoxCall列を走査して連鎖を検出
|
||||
for inst in mir.instructions {
|
||||
if me.isChainStart(inst) {
|
||||
local chain = me.buildChain(inst)
|
||||
if chain.length() <= 3 and me.allPure(chain) {
|
||||
chains.push(chain)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return chains
|
||||
}
|
||||
|
||||
foldChain(chain) {
|
||||
# 連鎖を1つのfused callに変換
|
||||
local ops = chain.map(inst => me.extractOp(inst))
|
||||
return new FusedCall(chain.first().array, ops)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
================================================================================
|
||||
段階的実装計画
|
||||
================================================================================
|
||||
|
||||
Step 1: 基盤整備（1週間）
|
||||
- 純度属性の構文設計
|
||||
- MIRへの属性伝播
|
||||
- テストフレームワーク
|
||||
|
||||
Step 2: Array融合（2週間）
|
||||
- map/filter連鎖の検出
|
||||
- fused call生成
|
||||
- VMサポート追加
|
||||
|
||||
Step 3: 効果測定（1週間）
|
||||
- ベンチマーク作成
|
||||
- メモリプロファイル
|
||||
- GC圧力測定
|
||||
|
||||
Step 4: 拡張（1ヶ月）
|
||||
- String操作
|
||||
- I/Oバッチ化
|
||||
- ループ最適化
|
||||
|
||||
================================================================================
|
||||
リスクと対策
|
||||
================================================================================
|
||||
|
||||
リスク1: 最適化バグでプログラムが壊れる
|
||||
対策: trace_hash/heap_hashで常に検証
|
||||
|
||||
リスク2: デバッグが困難になる
|
||||
対策: --unfoldオプションで即座に無効化
|
||||
|
||||
リスク3: 性能が逆に悪化する
|
||||
対策: Fold Budgetで自動OFF
|
||||
|
||||
================================================================================
|
||||
成功の測定基準
|
||||
================================================================================
|
||||
|
||||
1. 定量的指標
|
||||
- Array操作: 30%以上高速化
|
||||
- メモリ使用量: 50%削減
|
||||
- GC頻度: 1/3に削減
|
||||
|
||||
2. 定性的指標
|
||||
- コードの可読性維持
|
||||
- デバッグ容易性維持
|
||||
- ユーザーコード変更不要
|
||||
|
||||
================================================================================
|
||||
将来の拡張可能性
|
||||
================================================================================
|
||||
|
||||
- 非同期処理の融合
|
||||
- GUI構築の最適化
|
||||
- カスタム融合ルール
|
||||
- プラグインBox対応
|
||||
- JIT/AOTとの協調
|
||||
|
||||
================================================================================
|
||||
参考資料
|
||||
================================================================================
|
||||
|
||||
- Haskell: Stream Fusion
|
||||
- Rust: Iterator Fusion
|
||||
- Julia: Loop Fusion
|
||||
- Clojure: Transducers
|
||||
|
||||
ただし、Nyashの「Everything is Box」哲学に合わせて
|
||||
独自のアプローチを取る。
|
||||
|
||||
================================================================================
|
||||
Reference in New Issue
Block a user