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
2025-12-11 00:48:42 +09:00
parent a7dbc15878
commit 811dfebf98
387 changed files with 106 additions and 5551 deletions

View File

@ -0,0 +1,153 @@
# ANCP実装計画 - 統合ドキュメント
Date: 2025-09-03
Status: Implementation Ready
## 🎯 概要
ANCP (AI-Nyash Compact Notation Protocol) - 90%可逆圧縮技法の実装計画。
3人のAIアドバイザーChatGPT5、Claude、Geminiの知見を統合。
## 📊 三者の評価まとめ
| アドバイザー | 評価 | 重要アドバイス |
|-------------|------|----------------|
| ChatGPT5 | 全面支持・即実行推奨 | 段階導入・ガードレール・事故防止 |
| Claude | 革命的発明 | 実装順序・技術チェックリスト |
| Gemini | パラダイムシフト | IDE統合・段階的導入・学術価値 |
| Codex | 技術的厳密性重視 | AST正規化・トークン最適化・検証 |
## 🚀 統合実装計画4週間
### Week 1: 最小実装P↔C
**ChatGPT5案 + Codex技術仕様**
```bash
# 実装内容
- 固定辞書20語ASCII記号マッピング
- トークンベース変換(正規表現不使用)
- AST正規化P*)ルール確立
- nyashc CLI基本実装
```
**成果物**
- [ ] BNF/EBNF仕様書
- [ ] 最小エンコーダー/デコーダー
- [ ] ラウンドトリップテスト
- [ ] sourcemap.json生成
### Week 2: スマート化
**Gemini提案 + ChatGPT5安全策**
```bash
# 機能追加
- 文字列/コメント保護
- セミコロン自動挿入
- プロジェクト辞書(.ancprc
- エラー位置逆引き
```
**成果物**
- [ ] 非変換ゾーン認識
- [ ] 衝突検出メカニズム
- [ ] LLMパック機能
- [ ] デバッグ体験改善
### Week 3: F層導入読み込み専用
**Codex仕様 + ChatGPT5段階導入**
```bash
# F層実装
- 入力専用モード
- MIR直行デコーダー
- 等価性検証MIRハッシュ
- 文法圧縮Re-Pair/Sequitur
```
**成果物**
- [ ] F層パーサー
- [ ] MIR等価性テスト
- [ ] 圧縮率90%達成
- [ ] Property-based testing
### Week 4: ツール・統合
**Gemini IDE統合 + Codex CLI設計**
```bash
# 開発ツール
- VS Code拡張ホバー表示
- フォーマッター統合
- ベンチマーク自動化
- CI/CD統合
```
**成果物**
- [ ] VS Code拡張α
- [ ] nyash fmt統合
- [ ] ベンチマークCSV
- [ ] ドキュメント完成
## ⚠️ 設計原則(赤線)
### ChatGPT5の三原則
1. **常にPを正典** - C/Fは生成物
2. **トークン変換で可逆** - 正規表現は使わない
3. **Fはまず入力専用** - 段階的に拡張
### Codexの技術要件
1. **AST正規化必須** - P*の厳密定義
2. **トークン最適化** - GPT/Claude向け
3. **MIR等価性証明** - ハッシュ一致
### Geminiの実用要件
1. **IDE統合最優先** - 開発体験重視
2. **段階的導入** - fusion{}ブロック
3. **意味論的圧縮** - 将来への道筋
## 📈 測定指標KPI
| 指標 | 目標 | 測定方法 |
|------|------|----------|
| 圧縮率 | 90% | トークン数比較 |
| 可逆性 | 100% | ラウンドトリップテスト |
| MIR等価 | 100% | ハッシュ一致率 |
| 変換速度 | <100ms/1000行 | ベンチマーク |
| LLM効率 | 2-3倍 | コンテキスト拡張率 |
## 🛠️ 実装優先順位
### 今すぐDay 1-3
1. BNF/EBNF仕様書作成
2. 20語辞書決定
3. 最小プロトタイプ
### 第1週Day 4-7
1. トークナイザー拡張
2. 基本CLI実装
3. CIテスト準備
### 第2週以降
- Week 2-4の計画通り実行
## 📚 関連ドキュメント
### 設計・仕様
- [grammar-reform-final-decision.txt](archive/grammar-reform-final-decision.txt)
- [extreme-sugar-proposals.txt](extreme-sugar-proposals.txt)
- [ULTIMATE-AI-CODING-GUIDE.md](ULTIMATE-AI-CODING-GUIDE.md)
### AIフィードバック
- [ChatGPT5実装アドバイス](ai-feedback/chatgpt5-ancp-implementation-advice.md)
- [Claude技術分析](ai-feedback/codex-ancp-response.md)
- [Gemini革命的評価](ai-feedback/gemini-ancp-response.md)
### 実装ガイド
- [即座実装ガイド](ai-feedback/quick-implementation-guide.md)
- [技術チェックリスト](ai-feedback/technical-checklist.md)
- [実用的洞察](ai-feedback/actionable-insights.md)
## 🎉 結論
**全AIアドバイザーが「今すぐやるべき」と評価**
ChatGPT5の事故防止ガードレールCodexの技術的厳密性Geminiの実用性を統合し、**4週間で90%圧縮を実現**する
---
**次のアクション**: BNF/EBNF仕様書作成開始

View File

@ -0,0 +1,68 @@
# 実装ガイド・計画
このフォルダには、Phase 12.7の実装に関する計画とチェックリストが含まれています。
## 📄 ドキュメント一覧
### 🚀 実装計画
- **[ANCP-IMPLEMENTATION-PLAN.md](ANCP-IMPLEMENTATION-PLAN.md)** - 統合実装計画
- 4週間の段階的実装スケジュール
- 全AIアドバイザーの知見を統合
- KPI測定指標の定義
- リスクと対策
### 🔧 チェックリスト
- **[implementation-final-checklist.txt](implementation-final-checklist.txt)** - 実装チェックリスト
- 文法改革の実装項目
- ANCP実装の必須タスク
- テスト・検証項目
- ツール統合タスク
## 📅 実装スケジュール概要
### Week 1: 基礎実装P↔C
- [ ] BNF/EBNF仕様書完成
- [ ] 20語の固定辞書実装
- [ ] トークンベース変換器
- [ ] 基本的なCLInyashc
- [ ] ラウンドトリップテスト
### Week 2: スマート化
- [ ] 文字列・コメント保護
- [ ] セミコロン自動挿入
- [ ] プロジェクト辞書(.ancprc
- [ ] エラー位置逆引き
- [ ] LLMパック機能
### Week 3: F層導入
- [ ] Fusion層パーサー読み込み専用
- [ ] MIR直行デコーダー
- [ ] 等価性検証MIRハッシュ
- [ ] 90%圧縮達成
- [ ] Property-based testing
### Week 4: ツール統合
- [ ] VS Code拡張ホバー表示
- [ ] フォーマッター統合
- [ ] ベンチマーク自動化
- [ ] CI/CD統合
- [ ] ドキュメント完成
## 🎯 次のアクション
1. **ANCP-Token-Specification-v1.md** に基づくトークナイザー実装
2. テストケースOK/NG 30本の作成
3. 最小プロトタイプの開発開始
## 📊 成功指標
| 指標 | 目標値 | 測定方法 |
|------|--------|----------|
| 圧縮率 | 90% | トークン数比較 |
| 可逆性 | 100% | ラウンドトリップテスト |
| MIR等価 | 100% | ハッシュ一致率 |
| 変換速度 | <100ms/1000行 | ベンチマーク |
---
実装を開始する前に必ずANCP-IMPLEMENTATION-PLAN.mdを熟読してください

View File

@ -0,0 +1,259 @@
================================================================================
Phase 12.7 文法改革 - 実装前最終チェックリスト
2025-09-03
================================================================================
【ChatGPT5さんからの重要指摘への対応】
================================================================================
1. トークナイザー実装の注意点
================================================================================
【既存の問題】
- 現在のARROWトークンが '>>' になっている → これを修正!
【対応】
```rust
// tokenizer.rs での修正
// 削除または未使用化
// ARROW => ">>" // これは間違い!
// 新規追加
FAT_ARROW => "=>" // peek構文用
DOUBLE_COLON => "::" // Parent::method用P1だがトークンは今追加
```
【追加する予約語P0
- peek
- continue
- birth
publicは後述の特殊対応
================================================================================
2. 値の扱いの明確化
================================================================================
【空ブロックの値】
- 空ブロック {} の値は **VoidBox** とする
- 最後の式がない場合もVoidBox
【peek式の値規約】
```nyash
// 単一式の値
peek x {
1 => "one" // StringBoxを返す
else => "other"
}
// ブロックの値(最後の式)
peek x {
1 => {
print("got one")
"one" // これが値
}
else => {
// 空ブロックはVoidBox
}
}
// 関数Boxの値P0では単純に関数オブジェクト
peek op {
"add" => fn(a, b) { return a + b } // 関数Boxを返す
else => fn() { return 0 }
}
```
================================================================================
3. 等値比較の詳細規約
================================================================================
【peek内のパターンマッチングP0
- StringBox: 完全一致、大文字小文字を区別
- IntegerBox: == による数値比較
- BoolBox: true/false の完全一致
- VoidBox/null: null との一致
【typeof との組み合わせ】
```nyash
peek typeof(value) {
"StringBox" => processString(value)
"IntegerBox" => processInt(value)
else => processOther(value)
}
```
※ typeof は既存実装の型名文字列をそのまま返す
================================================================================
4. publicキーワードの扱い
================================================================================
【現状との調整】
- 既存: public { field1, field2 } ブロック形式
- 新規: public field: Type 個別指定形式
【P0での対応】
```rust
// 両方をサポート(移行期間)
box Example {
// 新形式
public name: StringBox
count: IntegerBox
// 旧形式(レガシー、警告付きでサポート)
public { oldField1, oldField2 }
}
```
【実装方針】
- publicを「文脈依存キーワード」として扱う
- Box内でのみ特別な意味を持つ
- それ以外では識別子として使える(後方互換性)
================================================================================
5. フィールド宣言の段階実装
================================================================================
【P0今回
- パースのみ: name: Type
- publicプレフィックス対応
- デフォルト値なし(= expr はP1へ
【P1次回
- デフォルト値: name: Type = expr
- birth内での自動初期化
【現在の回避策】
```nyash
box Counter {
count: IntegerBox
cache: MapBox // デフォルト値はP1まで待つ
birth() {
me.count = 0
me.cache = new MapBox() // birth内で明示的に初期化
}
}
```
================================================================================
6. デシュガー戦略P0
================================================================================
【peek → if-else連鎖】
```nyash
// Nyashコード
peek animal {
"dog" => bark()
"cat" => meow()
else => silent()
}
// デシュガー後(概念的)
if animal == "dog" {
bark()
} else if animal == "cat" {
meow()
} else {
silent()
}
```
【実装の簡単さ優先】
- VM/MIRは既存のif-else処理をそのまま利用
- 最適化ジャンプテーブル等はP1以降
================================================================================
7. 最小限のテストケースP0
================================================================================
```nyash
// test_peek_basic.hako
local animal = "cat"
local sound = peek animal {
"dog" => "woof"
"cat" => "meow"
else => "..."
}
print(sound) // "meow"
// test_peek_block.hako
local result = peek x {
1 => {
local temp = "one"
temp // 値
}
else => "other"
}
// test_continue.hako
local i = 0
local sum = 0
loop(i < 5) {
i = i + 1
if i == 3 {
continue
}
sum = sum + i
}
print(sum) // 12 (1+2+4+5, 3はスキップ)
// test_field_declaration.hako
box Point {
public x: IntegerBox
public y: IntegerBox
private z: IntegerBox
birth(x, y) {
me.x = x
me.y = y
me.z = 0
}
}
```
================================================================================
8. 実装順序(推奨)
================================================================================
1. tokenizer.rs
- FAT_ARROW, DOUBLE_COLON追加
- peek, continue, birth を予約語追加
2. parser/expressions.rs
- parse_peek_expr() 実装
- else必須チェック
3. parser/statements.rs
- Continue文追加
- フィールド宣言パース追加
4. ast.rs
- PeekExpr, ContinueStmt追加
- Field構造体に型情報追加
5. interpreter/evaluator.rs
- peek式の評価if-elseとして
- continue処理既存のControlFlow利用
================================================================================
9. P1に回すもの今回は実装しない
================================================================================
- import文の完全実装
- Parent::method() 記法(トークンのみ追加)
- fn{} クロージャの完全実装(環境キャプチャ等)
- フィールドのデフォルト値
- @override等の属性
================================================================================
10. 合意事項の最終確認
================================================================================
✓ peekは「式」として値を返す
✓ else節は必須コンパイルエラー
✓ 空ブロックの値はVoidBox
✓ publicは文脈依存キーワード互換性維持
✓ フィールドのデフォルト値はP1送り
✓ デシュガーでシンプル実装(最適化は後回し)
================================================================================