docs(joinir): Phase 182-6 Update documentation with P1/P2 verification results

Phase 182 Summary:
 Pattern1 (Simple) verification complete
 Pattern2 (Break) verification complete with integer operations
 Routing whitelist updated (_parse_number/2, _atoi/1, _match_literal/3)
 Representative tests created and passing

Blockers identified:
1. LoopBodyLocal variable handling
   - Current: Tries Trim-specific carrier promotion (fails)
   - Needed: Allow pure local variables (no promotion) in P1/P2
2. String concatenation filter (Phase 178)
   - Current: Rejects 'num_str = num_str + ch' conservatively
   - Needed: Gradual enablement for JsonParser use cases

Updated documentation:
- joinir-architecture-overview.md: Added Phase 182 status to JsonParser section
- CURRENT_TASK.md: Added Phase 182 completion and Phase 183 next steps
- phase182-simple-loops-design.md: Design memo for Phase 182
This commit is contained in:
nyash-codex
2025-12-08 21:41:19 +09:00
parent d5b63e0944
commit 0772dc3e82
2 changed files with 67 additions and 4 deletions

View File

@ -108,6 +108,13 @@
- **TrimLoopLowerer**: LoopConditionScopeBox + LoopBodyCarrierPromoter 統合
- **再利用性向上**: Pattern2/4/未来パターンすべてで同じ Trim lowering を利用可能
- **テスト**: cargo build --release SUCCESS (0 errors, warnings のみ)
- [x] **Phase 181: JsonParser ループ空間の再インベントリ** ✅ (2025-12-08)
- Task 181-1: JsonParserBox 内の全 11 ループを LoopPatternSpace の軸A〜Fで分類
- Task 181-2: 各ループの Pattern14 + P5 へのマッピング_parse_number/_atoi/_match_literal 等は P2/P1 で対応可能)
- Task 181-3: `_skip_whitespace` / `_trim*` / `_parse_string` 最小版 など、既に JoinIR/P5 経路で動作しているケースを確認
- Task 181-4: 残りループの優先度と難易度を整理_parse_array/_parse_object/_unescape_string は後続 Phase で対応)
- **成果**: JsonParser の全ループが「形としては P1P4(+P5) で表現可能」であることを確認。
ループ形の追加は不要で、複雑さは BoolExprLowerer / ContinueBranchNormalizer / TrimLoopLowerer 側で吸収する方針を確定。
- [x] **Phase 179-B: Generic Pattern Framework** ✅ (2025-12-08)
- Task 179-B-1: 設計ドキュメント作成phase179-generic-pattern-framework.md
- Task 179-B-2: PatternPipelineContext 実装pattern_pipeline.rs
@ -129,9 +136,27 @@
- **成果**: 全ループが「LoopParam/OuterLocal のみ」という制約を満たし、理論的に全対応可能
- **発見**: ブロックされるループは存在しないTrim は昇格パターンで対応済み)
- **優先度**: P2 Break3個: _parse_number/_atoi/_atof_loop> P1 Simple1個: _match_literal> P4 Continue3個: _parse_array/_parse_object/_unescape_string
- [ ] Phase 182+: JsonParser 基本パターン実装
- _parse_number, _atoi, _atof_loop P2 Break, indexOf パターン
- _match_literal P1 Simple
- [x] **Phase 182: JsonParser P1/P2 パターン検証** ✅ (2025-12-08)
- Task 182-1: 設計ドキュメント作成phase182-simple-loops-design.md
- Task 182-2: Routing whitelist 更新_parse_number/2, _atoi/1, _match_literal/3 追加
- Task 182-3: Pattern routing 確認NYASH_JOINIR_STRUCTURE_ONLY=1 tracing
- Task 182-5: 代表テスト作成・実行
- ✅ Pattern1: phase182_p1_match_literal.hako PASS
- ✅ Pattern2: phase182_p2_break_integer.hako PASS
- Task 182-6: ドキュメント更新joinir-architecture-overview.md, CURRENT_TASK.md
- **成果**: P1/P2 パターンの基本動作確認完了整数演算・early return で動作実証)
- **ブロッカー発見**:
1. LoopBodyLocal 変数処理(`ch`, `digit_pos`, `pos`
- 現状: Trim 専用の carrier 昇格を試みてエラー
- 必要: P1/P2 で純粋なローカル変数(昇格不要)として扱う仕組み
2. 文字列連結フィルタPhase 178
- 現状: `num_str = num_str + ch` を保守的に reject
- 必要: JsonParser 向けに段階的有効化
- **次ステップ**: Phase 183 で LoopBodyLocal 処理と string ops 対応
- [ ] Phase 183+: JsonParser LoopBodyLocal 対応 + String ops 有効化
- LoopBodyLocal を carrier に昇格しない仕組みP1/P2 専用)
- String concat フィルタの段階的緩和
- _parse_number, _atoi 完全実装
- [ ] Phase 183+: JsonParser 中級パターン実装
- _parse_array, _parse_object P4 Continue, MethodCall 複数対応)
- _parse_string 完全版 P2/P4, string concat + escape

View File

@ -274,7 +274,45 @@ JoinIR ラインで守るべきルールを先に書いておくよ:
---
## 4. selfhost / .hako JoinIR Frontend との関係
## 4. JsonParser / Trim / P5 ループの現在地Phase 170181
### 4.1 JsonParser ループ空間と P1P5
Phase 181 で JsonParserBox 内の 11 ループを棚卸しした結果、
構造的には **すべて JoinIR Pattern14 (+ P5) で扱える** ことが分かったよ。
- 既に JoinIR 経路で動作しているもの:
- `_skip_whitespace`P2 + P5 Trim
- `_trim` leading/trailingP2 + P5 Trim
- **Phase 182 で P1/P2 パターン検証完了** ✅:
- Pattern1 (Simple): `_match_literal` 系ループで動作確認済みapps/tests/phase182_p1_match_literal.hako
- Pattern2 (Break): 整数演算ループで動作確認済みapps/tests/phase182_p2_break_integer.hako
- **ブロッカー発見**: 実際の JsonParser ループには 2 つの制約が必要:
1. LoopBodyLocal 変数の扱い(`ch`, `digit_pos`, `pos` など)
- 現状は Trim pattern 専用の carrier 昇格を試みてエラーになる
- P1/P2 では純粋なローカル変数(昇格不要)として扱うべき
2. 文字列連結フィルタPhase 178
- `num_str = num_str + ch` のような string concat を保守的に reject
- JsonParser では必須の操作なので段階的に有効化が必要
- 構造的に P1P4 で対応可能(代表例):
- `_parse_number` / `_atoi`P2 Break- Phase 182 でブロッカー特定済み
- `_match_literal`P1 Simple while- Phase 182 で動作確認済み ✅
- `_parse_string` / `_parse_array` / `_parse_object`
P2 + P4 + P5 の組み合わせで表現可能なことを設計上確認済み)
- 低優先度だが理論上は P1P4 からの拡張で吸収可能:
- `_unescape_string` など、複雑な continue / 条件付き更新を含むループ
方針:
- **ループの「形」は P1P4 から増やさない**。
複雑さLoopBodyLocal 条件、OR chain、continue 多用など)は BoolExprLowerer /
ContinueBranchNormalizer / TrimLoopLowerer (P5) といった補助箱側で吸収する。
- JsonParser 側の P5 適用Trim / `_skip_whitespace` / `_parse_string` 最小版)は実証済み。
残りのループは Phase 17x18x で、P1P4+P5 の組み合わせとして段階的に実装していく。
---
## 5. selfhost / .hako JoinIR Frontend との関係
JoinIR は Rust 側だけでなく、将来的に .hako selfhost コンパイラ側でも生成・解析される予定だよ: