Files
hakorune/docs
tomoaki 575a5d750f refactor(joinir): Phase 255 P2 - loop_invariants + var() unification + Phase 256 prep
## Task A: Loop Invariants Architecture (Option A - Boundary Extension)

Introduced explicit loop_invariants concept for variables that are:
- Used in loop body but never modified (e.g., substring needle in index_of)
- Need header PHI (all iterations use same value)
- Do NOT need exit PHI (not a LoopState)

Implementation:
- Added `loop_invariants: Vec<(String, ValueId)>` field to JoinInlineBoundary
- Added `with_loop_invariants()` method to JoinInlineBoundaryBuilder
- Modified Pattern 6 to use loop_invariants instead of ConditionOnly misuse
  * s (haystack) and ch (needle) now properly classified
  * exit_bindings simplified to only LoopState carriers
- Extended LoopHeaderPhiBuilder to generate invariant PHIs
  * Entry PHI: from host
  * Latch PHI: self-reference (same value every iteration)
- Updated instruction_rewriter to handle invariant latch incoming

Files Modified:
- src/mir/join_ir/lowering/inline_boundary.rs (structure + builder)
- src/mir/join_ir/lowering/inline_boundary_builder.rs (builder method)
- src/mir/builder/control_flow/joinir/patterns/pattern6_scan_with_init.rs
- src/mir/builder/control_flow/joinir/merge/loop_header_phi_builder.rs
- src/mir/builder/control_flow/joinir/merge/mod.rs
- src/mir/builder/control_flow/joinir/merge/instruction_rewriter.rs

## Task B: Code Quality - var() Helper Unification

Created common module to eliminate var() duplication:
- New module: src/mir/builder/control_flow/joinir/patterns/common/
- Centralized var() helper in ast_helpers.rs
- Updated Pattern 6 and Pattern 2 to use common var()
- Test code (5 occurrences) deferred to Phase 256+ per 80/20 rule

Result: Eliminated 2 duplicate var() functions, 5 test occurrences remain

Files Created:
- src/mir/builder/control_flow/joinir/patterns/common/ast_helpers.rs
- src/mir/builder/control_flow/joinir/patterns/common/mod.rs

Files Modified:
- src/mir/builder/control_flow/joinir/patterns/mod.rs
- src/mir/builder/control_flow/joinir/patterns/pattern6_scan_with_init.rs
- src/mir/builder/control_flow/joinir/patterns/policies/balanced_depth_scan_policy.rs

## Task C: Documentation - PostLoopEarlyReturnPlan Usage Examples

Enhanced post_loop_early_return_plan.rs with:
- Architecture explanation (exit PHI usage prevents DCE)
- Pattern 2 example (Less: balanced_depth_scan)
- Pattern 6 example (NotEqual: index_of)
- Builder defer decision: when 4+ patterns emerge, add builder

Files Modified:
- src/mir/builder/control_flow/joinir/patterns/policies/post_loop_early_return_plan.rs

## Task D: Phase 256 Preparation

Analyzed next failure from smoke tests:
- `StringUtils.split/2` with variable-step loop
- Not constant step (i += len or similar)
- Three implementation options identified

Created Phase 256 README with:
- Minimal reproduction code
- Root cause analysis
- Implementation options with trade-offs
- Clear next steps

Files Created:
- docs/development/current/main/phases/phase-256/README.md

## Verification Results

 All tests passing:
- pattern254_p0_index_of_vm.sh: PASS
- No regression in Pattern 1-5
- Smoke test progresses past json_lint_vm to next failure

 Architecture achievements:
- Semantic clarity: loop_invariants vs exit_bindings properly separated
- ConditionOnly misuse eliminated
- PHI generation correct for all carrier types
- Code quality: var() duplication reduced
- Next phase clearly defined

## Summary

Phase 255 P2 achieves root-cause fix for multi-param loop support:
- Boundary concept expanded (loop_invariants field)
- Pattern 6 architecture corrected (no ConditionOnly misuse)
- Code quality improved (var() centralized)
- Next pattern (variable-step) is now the challenge

 Box-first principles maintained: clean separation, explicit roles, minimal coupling

🧠 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2025-12-19 23:48:49 +09:00
..

📚 Nyash Documentation

🚀 はじめに(導線)

  • 現在のタスクと進行状況: ../CURRENT_TASK.md
  • コア概念の速習: reference/architecture/nyash_core_concepts.md
  • 設計ブループリント(文字列/文字コード): development/design/blueprints/strings-utf8-byte.md

📂 ドキュメント構造(指針)

📖 reference/ - 正式な技術仕様

  • language/ - 言語仕様構文、型システム、Box仕様
  • architecture/ - システムアーキテクチャMIR、VM、実行バックエンド
  • api/ - ビルトインBoxのAPI仕様
  • plugin-system/ - プラグインシステム、BID-FFI仕様
    • 🆕🔥 TypeBox ABI統合 + セルフホスティング - ABIすらBoxとして扱う革命的設計
    • まずはこちら: reference/boxes-system/plugin_lifecycle.mdPluginBoxV2のライフサイクル、singleton、nyash.tomlの要点

📚 guides/ - 利用者向けガイド

  • getting-started.md - はじめに(統一版)
  • tutorials/ - ステップバイステップのチュートリアル
  • examples/ - 実践的なサンプルコード
  • wasm-guide/ - WebAssemblyビルドガイド

🧩 how-to/ - 目的別ハウツー

  • 手順重視の短いガイド(前提→コマンド→検証)

🔧 development/ - 開発者向け

  • current/ - 現在進行中のタスクCURRENT_TASK.md等
  • roadmap/ - 開発計画
    • phases/ - Phase 812の詳細計画
    • phase-12/ - 🆕🔥 TypeBox統合ABI + Nyash ABI C実装セルフホスティング実現
    • native-plan/ - ネイティブビルド計画
  • proposals/ - RFC、新機能提案

🔌 Net PluginHTTP/TCP

  • 使い方と仕様: reference/plugin-system/net-plugin.md

🗄️ archive/ - アーカイブ

  • consultations/ - AI相談記録gemini/chatgpt/codex
  • decisions/ - 過去の設計決定
  • build-logs/ - ビルドログ、ベンチマーク結果
  • old-versions/ - 古いドキュメント

📌 Docs マップ(トップレベルとステータス)

新しくドキュメントを書くときや、どこに置くか迷ったときはこの表を基準にする。

パス 用途 主な対象 ステータス
reference/ 言語仕様・正式なリファレンス 利用者 / 実装者 Active / SSOT
guides/ チュートリアル・長めの読み物 利用者 / 新規開発者 Active
how-to/ 手順書・レシピ集 日常開発 Active
quick-reference/ コマンドやオプションの早見表 日常参照 Active
development/ Rust 実装側の設計・ロードマップ コア開発者 ActiveRust層
private/ 将来の整理待ちのメモ・長文案 コア開発者 Draft / Incubator
design/ 公開可能な安定寄り設計ノート 実装者 Active安定設計
architecture/ 全体アーキテクチャの俯瞰図 実装者 / 設計者 Active
abi/ Nyash/Hakorune ABI 関連 実装者 Active
specs/ 古めの仕様・実験的仕様 実装者 Legacy必要に応じ参照
checklists/ レビュー・設計チェックリスト 実装者 Active
tools/ ドキュメント生成・補助スクリプト 実装者 Active
updates/ リリースノート・変更履歴 利用者 / 実装者 Active
releases/ リリース関連ドキュメント 利用者 Active
archive/ 旧ドキュメント・歴史資料 研究・考古学用 Archived正本ではない
assets/ 画像などの共有アセット すべて Support
ENV_VARS.md 環境変数リファレンス 実装者 / 運用者 Active集約先

運用ルール(提案):

  • 新規仕様/設計: まずは private/ に置き、安定したら reference/ or design/ へ昇格する。
  • Rust 実装寄りの話: development/ 配下に置く(セルフホスト側は private/roadmap 等)。
  • 古い資料・置き換え済み: 内容を変えずに archive/ 以下へ移動し、先頭に「Archived / 新しい場所」の一行メモを書く。
  • ユーザー向けに見せたいもの: guides/, how-to/, quick-reference/, releases/ を優先する。

🎯 クイックアクセス

すぐ始める

  • guides/getting-started.md
  • guides/language-guide.md
  • guides/p2p-guide.md

技術リファレンス

  • reference/language/LANGUAGE_REFERENCE_2025.md
  • reference/language/EBNF.md演算子: ! 採用 / do-while 非採用)
  • reference/language/strings.mdUTF8/Byte 二本柱)
  • reference/architecture/TECHNICAL_ARCHITECTURE_2025.md
  • reference/architecture/execution-backends.md
  • reference/runtime/gc.md
  • reference/plugin-system/
  • tools/cli-options.mdCLI早見表

デザイン/ガイド

  • guides/language-core-and-sugar.mdコア最小糖衣
  • guides/loopform.mdループ正規化
  • guides/scopebox.md開発時の可視化
  • guides/dev-local-alias.md開発向け: 行頭 @name = expr → local 宣言糖衣)
  • guides/box-patterns.mdBoxパターン集Ownership/Lease/Cancel/Capability/Affinity/Observable
  • guides/box-design-checklist.mdBox 設計チェックリスト)
  • proposals/concurrency/boxes.md並行モデルのBox設計Routine/Channel/Select/Scope
  • reference/concurrency/semantics.mdブロッキング/close/select/観測の規約)
  • design/(設計ノート入口)
    • development/design/legacy/flow-blocks.md矢印フロー匿名ブロック・設計草案
    • development/proposals/scope-reuse.mdスコープ再利用ブロック・MVP提案
    • reference/language/match-guards.mdガード連鎖Range・CharClass設計
    • guides/core-principles.md最小構文・ゼロランタイム・可視化の原則

開発状況


📋 再編成について / フォルダの見分け方

ドキュメントは2025年8月20日に再編成されました。詳細はREORGANIZATION_REPORT.mdを参照してください。

旧パスから新パスへの主な変更:

  • 説明書/guides/reference/ に分割
  • 予定/development/roadmap/
  • 散在していたファイル → 適切なカテゴリに整理

補足:

  • reference/ は正本(仕様)。
  • guides/ は読み物、how-to/ は手順書。
  • design/ は公開できる設計ノート。
  • private/ は下書き保管庫(将来 reference//design/ に昇格)。

Nyash は「Everything is Box」哲学に基づく言語です。詳細はコア概念とガイドを参照してください。