146 lines
4.5 KiB
Markdown
146 lines
4.5 KiB
Markdown
|
# AI深層考察: Nyash統一文法アーキテクチャ
|
|||
|
|
|
|||
|
|
## 🎯 概要
|
|||
|
|
|
|||
|
|
GeminiとCodexに時間無制限で深く考えてもらった、Nyash統一文法アーキテクチャに関する洞察をまとめました。
|
|||
|
|
|
|||
|
|
## 🔥 Gemini先生の洞察
|
|||
|
|
|
|||
|
|
### 核心的提言: 宣言的文法定義 + ビルド時コード生成
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
[ grammar.toml ] ← 宣言的SSoT（Single Source of Truth）
|
|||
|
|
↓
|
|||
|
|
[ build.rs ] ← メタプログラミング層
|
|||
|
|
↓
|
|||
|
|
├─ generated_tokens.rs
|
|||
|
|
├─ generated_keywords.rs
|
|||
|
|
├─ generated_rules.rs
|
|||
|
|
└─ generated_opcodes.rs
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 重要ポイント
|
|||
|
|
|
|||
|
|
1. **真の分離**: `UnifiedKeyword`構造体は依然として各層を密結合させる。宣言的ファイルからコード生成する方が疎結合を保てる。
|
|||
|
|
|
|||
|
|
2. **ゼロコスト抽象化**:
|
|||
|
|
- ビルド時生成により実行時オーバーヘッドなし
|
|||
|
|
- `enum`と`match`文で高速ディスパッチ
|
|||
|
|
- `#[inline(always)]`で関数呼び出しコストなし
|
|||
|
|
|
|||
|
|
3. **コンパイラ駆動開発**:
|
|||
|
|
```rust
|
|||
|
|
// 新機能追加時、全層でコンパイルエラー発生
|
|||
|
|
// → 実装漏れがなくなる
|
|||
|
|
match token {
|
|||
|
|
TokenType::Async => // 新しく追加されたので実装必須
|
|||
|
|
_ => // ...
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
4. **他言語からの学び**:
|
|||
|
|
- **CPython**: `Grammar/Tokens`ファイルから生成
|
|||
|
|
- **V8**: Ignition(インタプリタ)とTurboFan(JIT)の分離
|
|||
|
|
- **rustc**: HIR→MIRという段階的表現
|
|||
|
|
|
|||
|
|
## 💡 Codex先生の洞察
|
|||
|
|
|
|||
|
|
### 核心的提言: MIRを中心とした統一セマンティクス基盤
|
|||
|
|
|
|||
|
|
```yaml
|
|||
|
|
# grammar/nyash.yml
|
|||
|
|
tokens:
|
|||
|
|
- name: ME
|
|||
|
|
literal: "me"
|
|||
|
|
soft: true
|
|||
|
|
contexts: ["expr", "pattern"]
|
|||
|
|
deprecated_aliases: ["self"]
|
|||
|
|
ai_hint: "Current object; not assignable."
|
|||
|
|
|
|||
|
|
operators:
|
|||
|
|
- symbol: "+"
|
|||
|
|
name: add
|
|||
|
|
precedence: 110
|
|||
|
|
associativity: left
|
|||
|
|
overloads:
|
|||
|
|
- types: ["i64","i64"] -> "i64"
|
|||
|
|
lower: MIR.AddI64
|
|||
|
|
- types: ["String","String"] -> "String"
|
|||
|
|
lower: MIR.Concat
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 実装戦略
|
|||
|
|
|
|||
|
|
1. **単一仕様ファイル**: `grammar/nyash.yml`に全て定義
|
|||
|
|
- キーワード、演算子、文法、型、強制変換
|
|||
|
|
- MIRローリング、VMオペコード、JITパターン
|
|||
|
|
- 非推奨、AIヒント
|
|||
|
|
|
|||
|
|
2. **コード生成クレート**: `crates/nygrammar-gen`
|
|||
|
|
- Perfect hash関数でO(1)キーワード認識
|
|||
|
|
- Pratt/PEGパーサーテーブル生成
|
|||
|
|
- 型ディスパッチマトリックス生成
|
|||
|
|
|
|||
|
|
3. **MIRが真実の基盤**:
|
|||
|
|
```rust
|
|||
|
|
pub fn add(lhs: Value, rhs: Value) -> Result<MIRNode> {
|
|||
|
|
// 生成されたfast-pathを使用
|
|||
|
|
// 常にMIRノードを返す
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
4. **性能最適化**:
|
|||
|
|
- ビルド時にすべて決定（実行時検索なし）
|
|||
|
|
- インラインキャッシュで呼び出しサイト最適化
|
|||
|
|
- ソフトキーワードはパーサー状態で判定
|
|||
|
|
|
|||
|
|
### 段階的移行計画
|
|||
|
|
|
|||
|
|
- **Phase 0**: ベースラインテスト（現状記録）
|
|||
|
|
- **Phase 1**: 正準MIR定義
|
|||
|
|
- **Phase 2**: KeywordRegistry生成
|
|||
|
|
- **Phase 3**: UnifiedSemantics導入
|
|||
|
|
- **Phase 4**: パーサー統一
|
|||
|
|
- **Phase 5**: バックエンドマッピング
|
|||
|
|
- **Phase 6**: 非推奨警告
|
|||
|
|
- **Phase 7**: ツール/ドキュメント生成
|
|||
|
|
|
|||
|
|
## 🎯 統合された知見
|
|||
|
|
|
|||
|
|
両AIの提言を統合すると：
|
|||
|
|
|
|||
|
|
### 1. 宣言的定義 + コード生成が最強
|
|||
|
|
- YAML/TOMLで文法を宣言的に定義
|
|||
|
|
- build.rsでRustコードを生成
|
|||
|
|
- 実行時オーバーヘッドゼロ
|
|||
|
|
|
|||
|
|
### 2. MIRを中心とした統一
|
|||
|
|
- すべてのセマンティクスはMIRで表現
|
|||
|
|
- 各バックエンドはMIRを実行/コンパイル
|
|||
|
|
- 一貫性が自動的に保証される
|
|||
|
|
|
|||
|
|
### 3. AI友好的な設計
|
|||
|
|
- 機械可読な仕様ファイル
|
|||
|
|
- 豊富な例とエラーカタログ
|
|||
|
|
- 自動生成されるドキュメント
|
|||
|
|
|
|||
|
|
### 4. 拡張性への配慮
|
|||
|
|
- 新バックエンド追加が容易
|
|||
|
|
- プラグインによる拡張可能
|
|||
|
|
- 後方互換性の維持
|
|||
|
|
|
|||
|
|
## 📋 実装優先順位
|
|||
|
|
|
|||
|
|
1. **最優先**: `grammar/nyash.yml`の初版作成
|
|||
|
|
2. **高優先**: `build.rs`によるトークン生成
|
|||
|
|
3. **中優先**: MIR統一とUnifiedSemantics
|
|||
|
|
4. **低優先**: JIT最適化ヒント
|
|||
|
|
|
|||
|
|
## 🚀 期待される効果
|
|||
|
|
|
|||
|
|
- **保守性**: 新機能追加が1箇所の修正で完了
|
|||
|
|
- **一貫性**: 全層で同じセマンティクス保証
|
|||
|
|
- **性能**: ビルド時最適化で実行時コストなし
|
|||
|
|
- **AI対応**: LLMが正確にNyashコードを生成
|
|||
|
|
|
|||
|
|
これらの深い洞察により、Nyashの統一文法アーキテクチャは強固な基盤の上に構築されることになります。
|