79 lines
2.4 KiB
Markdown
79 lines
2.4 KiB
Markdown
|
# 事件分析：Python統合における型システム特殊化の危機
|
|||
|
|
|
|||
|
|
## 1. 背景
|
|||
|
|
- 開発開始から1ヶ月でインタープリター→VM→JIT→AOT/ネイティブまで到達
|
|||
|
|
- 最終段階でPython統合（PyRuntimeBox）を実装中
|
|||
|
|
- eval方式では完全にAOT対応（unsupported=0）達成
|
|||
|
|
- import/getattr/callの実装で問題発生
|
|||
|
|
|
|||
|
|
## 2. ChatGPT5の提案（技術的には正しい）
|
|||
|
|
```
|
|||
|
|
Lowerer強化（Step 2）:
|
|||
|
|
PyRuntimeBox.import/getattr → PyObjectBox
|
|||
|
|
PyObjectBox.call を emit_plugin_invoke で実装
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 提案の内容
|
|||
|
|
- Lowererで型推論を実装
|
|||
|
|
- `py.import("math")` → PyObjectBox型として記録
|
|||
|
|
- `math.getattr("sqrt")` → 型情報を伝搬
|
|||
|
|
- `sqrt.call(16)` → 適切なplugin_invokeを生成
|
|||
|
|
|
|||
|
|
## 3. 潜在的な危険性
|
|||
|
|
|
|||
|
|
### 3.1 設計哲学の崩壊
|
|||
|
|
```
|
|||
|
|
Nyash: Everything is Box
|
|||
|
|
↓
|
|||
|
|
Python専用の型システム導入
|
|||
|
|
↓
|
|||
|
|
Everything is... Special Case???
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 3.2 実装の肥大化
|
|||
|
|
```rust
|
|||
|
|
// もし実装していたら...
|
|||
|
|
match (receiver_type, method) {
|
|||
|
|
("PyRuntimeBox", "import") => "PyObjectBox",
|
|||
|
|
("FileBox", "open") => "FileHandle",
|
|||
|
|
("DBBox", "query") => "ResultSet",
|
|||
|
|
("GameBox", "spawn") => "GameObject",
|
|||
|
|
// 無限に増える特殊ケース
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 3.3 保守性の悪夢
|
|||
|
|
- 新しいプラグインごとにコンパイラ改修
|
|||
|
|
- JIT/Lowererが特定プラグインに依存
|
|||
|
|
- 汎用性の完全な喪失
|
|||
|
|
|
|||
|
|
## 4. 危機回避の瞬間
|
|||
|
|
|
|||
|
|
### 開発者の直感的疑問
|
|||
|
|
```
|
|||
|
|
「ん？大丈夫？JITのpython用のハードコーディングにならない？汎用的につかえるやつ？」
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### この一言が引き金となり：
|
|||
|
|
1. 設計の本質的な問題に気づく
|
|||
|
|
2. ChatGPT5も即座に方向転換
|
|||
|
|
3. Handle-First の汎用設計へ
|
|||
|
|
|
|||
|
|
## 5. 根本原因の分析
|
|||
|
|
|
|||
|
|
### 5.1 爆速開発の心理
|
|||
|
|
- 「あと少しで完成」の興奮
|
|||
|
|
- 批判的思考の低下
|
|||
|
|
- 目の前の問題解決に集中しすぎ
|
|||
|
|
|
|||
|
|
### 5.2 パターン認識の罠
|
|||
|
|
- 他言語の常識（Module型、Function型）を持ち込む
|
|||
|
|
- Nyashの独自性を忘れる
|
|||
|
|
|
|||
|
|
### 5.3 AI協調の盲点
|
|||
|
|
- 技術的解決に集中
|
|||
|
|
- 「そもそも論」を問わない
|
|||
|
|
- お互いの提案を無批判に受け入れる傾向
|
|||
|
|
|
|||
|
|
## 6. 結論
|
|||
|
|
技術的に正しい解決策が、必ずしも設計哲学的に正しいとは限らない。「Everything is Box」という原則を守ることで、より美しく保守性の高い設計が維持された。
|