# 実装変遷の記録

## Phase 1: MIR設計（2024年11月-12月）

### AI相談の流れ
1. **ChatGPT**: 「最小限のIRを作りたい」
   - 27命令から13命令への削減を提案
   - BoxCall統一アーキテクチャ
   - **型情報については言及なし**

2. **Claude**: 「実装を手伝って」
   - MIR→LLVM変換の実装
   - 動作優先で進める
   - **型推測で対応することを暗黙の前提に**

3. **Gemini**: 「最適化どうする？」
   - インラインキャッシング提案
   - パフォーマンス改善
   - **型情報の必要性は議論されず**

### 結果
```json
// 型情報のないMIR
{"op": "binop", "kind": "+", "lhs": 10, "rhs": 20, "result": 30}
// 30が文字列か数値か不明！
```

## Phase 2: 実装での苦闘（2025年1月）

### 症状
```
入力: print("Hello" + " World")
期待: Hello World
実際: 0
```

### デバッグログ
```
[2025-01-13 14:30] 文字列連結が動かない
[2025-01-13 15:00] ハンドルが0になってる？
[2025-01-13 15:30] +演算子の解釈が違う？
[2025-01-13 16:20] あれ、型情報ないじゃん！
```

### ChatGPT5の苦闘
- 50分の大長考
- Resolver 300行の複雑な実装
- PHI配線で混乱

## Phase 3: 人間の気づき（2025年1月13日）

### にゃーの素朴な疑問
「なんで+が文字列連結か数値加算か分からないの？」
「最初から型書いとけばよくない？」
「他の言語はどうしてるの？」

### 発見のプロセス
1. 実装の痛み → なぜ？
2. 型推測の複雑さ → 無駄では？
3. 他言語の調査 → みんな型情報持ってる！
4. 結論 → **MIRに型情報が必要**

## Phase 4: 解決策の実装

### Before（型推測地獄）
```python
# 300行のResolver
if is_stringish(lhs) or is_stringish(rhs):
    # 複雑な推測ロジック...
```

### After（型情報明示）
```json
{"op": "binop", "kind": "+", "lhs": 10, "rhs": 20, "result": 30,
 "dst_type": {"kind": "handle", "box_type": "StringBox"}}
```

## Phase 5: PHI生成の重複発見（2025年1月14日）

### 問題の発覚
にゃー：「なんで文字列が0になるの？」
調査結果：PHI生成が2箇所で行われていた！

1. **Builder側**: JSONからプレースホルダ生成
2. **Resolver側**: 必要時に`loc_i64_*`を生成

### 複雑性の段階的侵入
```
初期: シンプルなPHI変換
↓ forward reference問題
↓ プレースホルダ導入
↓ Resolverも独自にPHI生成
↓ 気づいたら2つのPHI生成器！
```

### にゃーの提案
「Resolverで統一したら？」
→ Gemini「美しいけど大変」
→ ChatGPT「やります！」

## 教訓

1. **AIの盲点**
   - 「最小化」に夢中で基本を忘れる
   - 実装の苦痛を経験できない
   - 部分最適化の罠
   - **複雑性の段階的侵入に気づかない**

2. **人間の強み**
   - 痛みから学ぶ
   - 「普通こうでしょ」という直感
   - 全体を俯瞰する力
   - **「なんで2つあるの？」という素朴な疑問**

3. **協働の価値**
   - AIが理論、人間が実践
   - 相補的な関係
   - 失敗から学ぶプロセス
   - **人間の疑問がアーキテクチャ改善を促す**