grammar(P0): add peek expression, continue statement, and field type annotations acceptance; add sample apps and interpreter path\n\n- tokenizer: add keywords (peek, continue), tokens (=> as FatArrow, :: as DoubleColon), keep >> as Arrow\n- parser: implement peek as expression (literal patterns only, else required), add continue; accept field 'name: Type' (discard type P0)\n- interpreter: evaluate PeekExpr; add Continue control flow handling\n- apps: add peek-demo, loop-continue-demo, adjust field-decl demo; use ConsoleBox instead of env.console for interpreter backend\n- docs: CURRENT_TASK updated earlier for Phase 12.7 P0\n\nNOTE: peek arms currently single-expression (no block expr yet); VM/MIR path does not lower PeekExpr yet; use --backend interpreter for demos

docs/development/roadmap/phases/phase-12.7/when-syntax-deep-consultation.txt

@@ -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個厳守ではなく、必要なものは追加する方針です。
+
+プログラミング言語設計の観点から、この設計の妥当性と改善案をお聞かせください。