Files
hakorune/docs/development/roadmap/phases/phase-12.7/ai-feedback/chatgpt5-ancp-implementation-advice.md
Moe Charm 6488b0542e Phase 12.7完了 + ChatGPT5によるVMリファクタリング
## 📚 Phase 12.7 ドキュメント整理
- ChatGPT5作成のANCP Token仕様書v1を整備
- フォルダ構造を機能別に再編成:
  - ancp-specs/ : ANCP圧縮技法仕様
  - grammar-specs/ : 文法改革仕様
  - implementation/ : 実装計画
  - ai-feedback/ : AIアドバイザーフィードバック
- 各フォルダにREADME.md作成で導線改善

## 🔧 ChatGPT5によるVMリファクタリング
- vm_instructions.rs (1927行) をモジュール分割:
  - boxcall.rs : Box呼び出し処理
  - call.rs : 関数呼び出し処理
  - extern_call.rs : 外部関数処理
  - function_new.rs : FunctionBox生成
  - newbox.rs : Box生成処理
  - plugin_invoke.rs : プラグイン呼び出し
- VM実行をファイル分割で整理:
  - vm_state.rs : 状態管理
  - vm_exec.rs : 実行エンジン
  - vm_control_flow.rs : 制御フロー
  - vm_gc.rs : GC処理
- plugin_loader_v2もモジュール化

##  新機能実装
- FunctionBox呼び出しのVM/MIR統一進捗
- ラムダ式のFunctionBox変換テスト追加
- 関数値の直接呼び出し基盤整備

次ステップ: ANCPプロトタイプ実装開始(Week 1)

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-09-04 03:41:02 +09:00

4.0 KiB
Raw Blame History

ChatGPT5先生のANCP実装アドバイス - 2025-09-03

🎯 総評:全面支持 + 事故防止のガードレール

「めっちゃ良い計画。やる価値デカいにゃ。」 「Phase 12のABI安定MIR最適化の上に載る"上物"で、下層を壊さない。」

📋 Go/No-Go評価

  • Go: 即座にAI効率が出る、下層を壊さない
  • 注意: 文法改革と圧縮を混ぜない。段階導入必須

成功条件(出荷時に断言できるライン)

  1. 完全可逆: P → C → P & P → C → F → C → P が常に一致
  2. コンパイラ等価: compile(P)compile(F) の MIRハッシュ一致
  3. 曖昧性ゼロ: 字句規則を形式化(最大貪欲+必要箇所のみセミコロン自動挿入)
  4. ソースマップ2.0: トークン単位の双方向マップ + BoxID
  5. 測定公開: 削減率・パース時間・LLMトークン消費を数字で提示

📅 4週間実装計画

Week 1Phase 12.7-A— 最小で回す

  • P↔C のトークンベース変換(正規表現は使わない)
  • 固定辞書20語から開始
  • nyashc --compact/--decompact + sourcemap.json
  • CI: 既存サンプル全ファイルで P→C→P 等価テスト

Week 212.7-B— スマート化

  • 文字列/コメント/正規表現リテラル非変換ゾーン認識
  • 自動セミコロン挿入の衝突検出
  • LLMパック: --llm-pack が最小仕様カード生成

Week 312.7-C— F層読み込み専用

  • FFusionを入力専用で導入出力はC
  • MIR直行デコーダ + 等価性検証
  • 代表5命令だけ実装して漸進展開

Week 412.7-D— ツール/拡張

  • VSCode拡張C表示⇄Pホバー
  • nyash fmt --mode=pretty|compact
  • ベンチ自動化CSV出力

🚨 設計の"赤線"(破ると事故る)

  1. Pは正典 - PR/レビューは常にPで行う
  2. 識別子衝突禁止 - 予約語→記号化でも曖昧にならない
  3. Unicode強制しない - 常にASCIIモード完備
  4. クロージャ/可変長演算 - ASTテンプレで可逆に

💡 記号マッピング実務案

ASCIIモードデフォルト

box → $        new → ~n      me → m
local → ~l     return → ~r   from → @
init → #       if → ?        else → :
loop → ~L

区切り規則

  • 記号トークンの左右に英数が来たら必ず1スペース自動挿入
  • ~[A-Za-z] は将来予約

🔧 実装の鍵

フォーマッタ可逆性

  • 変換はトークン列→トークン列
  • 文字列/テンプレ/正規表現の中身は一切触らない
  • 演算子の前置/後置/単項は個別トークン型
  • セミコロン自動挿入はスタック機械で判定

CLI設計

nyashc --compact --mode=ascii|uni --emit=code,sourcemap
nyashc --fusion --emit=fusion,mir --read-only
nyash fmt --mode=pretty|compact
nyash llm-pack <src-dir>

📊 KPI毎週測定

  • コード削減率P→C、P→F
  • パース/フォーマット時間ms/MB
  • MIR生成時間の差P vs C vs F
  • LLMトークン削減率
  • 等価テスト失敗率(%

🔐 互換性とバージョニング

  • ANCP v1: ancp://v1?mode=ascii|uni マジックコメント
  • 将来の記法変更は verfeature_bits で表明

⚠️ リスクと対処

リスク 対処
読みづらさ Pを正典・Cは生成物。編集は常にP
デバッグ困難 ソースマップ2.0で例外・ログをPへ逆引き
学習コスト VSCode拡張のホバー復元とQuick Toggle
LLMの誤解 llm-packに最小仕様カード必須付与

💬 結論

Phase 12.7 は"今やるべき"。 ただし「常にPを正典」「トークン変換で可逆」「Fはまず入力専用」の三原則を守れば、 90%圧縮×AI最適化の恩恵を"事故ゼロで"取りにいけるにゃ。

次の一歩: AncpTranscoderのトークン仕様書BNF/EBNF作成