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