Files
hakorune/docs/private/papers/paper-g-ai-collaboration/implementation-history.md

119 lines
3.2 KiB
Markdown
Raw Normal View History

# 実装変遷の記録
## 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が理論、人間が実践
- 相補的な関係
- 失敗から学ぶプロセス
- **人間の疑問がアーキテクチャ改善を促す**