7.1 KiB
7.1 KiB
Codex相談結果 - Macro System実装戦略と技術制約
日時: 2025-09-18 相談内容: Box-Based Macro Systemの技術的実現可能性と実装ロードマップ
🎯 技術的結論（要約）
- ✅ Property（実行時）+ Macro（コンパイル時）の厳密分離可能
- ✅ 既存MIR14命令で対応、新命令不要
- ✅ Pattern Matching基盤 → Macro実装の順序妥当
- 📊 工数見積もり: 最小2-3週間、充実4-6週間
🔧 技術的課題への回答
1. Property System（実行時）+ Macro（コンパイル時）の実装分離は可能？
Codex回答: 可能だよ。
分離設計
- マクロ: AST→ASTの純関数として実行（副作用なし、決定的）
- Property評価・状態: 実行時のみ
- 制約: マクロが参照できるのはAST上の属性メタデータのみ
アーキテクチャ利点
- フロントエンド（マクロ/構文糖）とバックエンド（MIR/LLVM/Cranelift）が綺麗に分離
- 既存の実行パスに影響なし
2. 既存MIR命令でマクロ展開をどう表現？新命令必要？
Codex回答: 原則不要だよ。
設計原則
- 展開結果は通常の構文へ還元
- 既存のloweringでMIR14生成
- 追加要素: デバッグ情報/起源（Span/Origin）のメタデータのみ
命令セット維持の利点
- 既存バックエンド（PyVM/LLVM/Cranelift）無変更
- テスト・検証の継続性確保
3. Pattern Matching実装 → AST操作ツール → Macro Systemの技術的順序は妥当？
Codex回答: 妥当だよ。
推奨実装順序
AST utils（パターン/クオジクオート/リライト）
↓
マクロ（関数風、次に属性）
↓
余裕があれば言語のmatch/desugarを同じ基盤で実装
Pattern Matching優先の技術的理由
- ASTは複雑なツリー構造 → Pattern Matchingが最適なツール
- マクロシステム自体の実装がクリーンになる
- 膨大なif let、switch、visitorパターンの回避
4. MacroBox<InputAst, OutputAst>型安全マクロの実装コスト？
Codex回答: 段階導入を推奨。
実装戦略
Stage 1: 組み込み手続きマクロ（in-proc、型は動的検証）
↓
Stage 2: Rust内製MacroBox（型付きAPI）
↓
Stage 3: Hygiene/解決文脈まで型モデリング拡張
コスト分析
- Rust実装: Traitベースで比較的低リスク
- 外部マクロ: JSON AST + スキーマ検証で橋渡し
- 初期: 境界での厳格スキーマ検証を重視
5. 工数見積もりの現実性
Codex回答: 現実的工数を提示
詳細見積もり
- 最小ASTパターン/クオジクオート/リライト: 2-4日（1-2日は攻めすぎ）
- マクロシステム最小: 2-3週間（関数風 + 簡易衛生 + エラーハンドリング）
- 属性マクロ・派生・MacroBox（型付き）: +2-3週間
- 合計: 4-6週間が妥当
🏗️ アーキテクチャ設計（Box-Based Macroの実像）
マクロ実行境界
Parser → 解決前/中のフェーズでマクロ実行
実行順序:
モジュール/マクロ定義収集
→ マクロ解決
→ 展開
→ 構文糖デシュガ
→ 型検査
→ MIR lowering
API設計（Rust側）
trait Macro {
fn expand(&self, ctx: &mut MacroCtx, input: AstNode) -> Result<AstNode>;
}
// MacroCtx提供機能:
// - fresh_symbol(), resolve_path()
// - emit_error()/warn(), span合成
// - 再帰カウンタ、featureフラグ
AST操作ツール
- パターン: 変数束縛、ワイルドカード、可変長（…）
- 準引用/脱引用: ASTをコード片として安全に構築
- リライト: 訪問/置換の汎用器（Span伝播対応）
衛生（Hygiene）設計
Stage 1: gensymベースの簡易衛生（捕捉回避）
Stage 2: SyntaxContext/Scope Markによる本格衛生
📋 実装フェーズとタスク
Phase A（基盤・1週）
- ✅ AST Pattern/Unifier（変数/ワイルドカード/variadic）
- ✅ Quasi-quote/unquote、AST Builder、Span連鎖
- ✅ Rewriter（停止条件/置換/環境）
Phase B（最小マクロ・1-2週）
- ✅ マクロ定義/登録/解決（関数風）
- ✅ 簡易衛生（gensym）+ 再帰上限
- ✅ エラー設計（Span指向、補助メッセージ）
- ✅ 展開トレース
NYASH_MACRO_TRACE=1
Phase C（拡張・1-2週）
- ✅ 属性マクロ（宣言/プロパティ/関数）
- ✅ MacroBox（Rust in-proc型付きAPI）
- ✅ デシュガ（pattern matching構文等）を基盤上で実装
Phase D（高機能・以降）
- ✅ 本格衛生（SyntaxContext）
- ✅ 外部手続きマクロ（AST JSON v0）試験的
- ✅ キャッシュ/インクリメンタル展開
✅ 受け入れ基準（各段階）
Phase A完了基準
- AST Pattern/クオジクオートのユニットテスト
- Span一貫性の確保
Phase B完了基準
- マクロ→通常構文→MIR14が既存スモークと一致
- PyVM/LLVM両方で差分なし
Phase C完了基準
- 属性マクロでProperty宣言の糖衣実装
- MacroBoxで実例1つ動作
Phase D完了基準
- 再帰/衛生の難ケース（名前捕捉/別スコープ）で期待通り動作
🎯 制約とリスク対応
Phase-15方針との整合
- 優先度: AST操作基盤 → 最小マクロ（in-proc）→ デシュガ → 属性マクロ
- 制約: Rust VM/JIT拡張は最小化、フロントエンド完結
- 影響: 既存実行経路への影響なし
リスク対応策
- 衛生の落とし穴: 段階導入（gensym→context）で抑制
- エラーレポート品質: Span合成と補助ヒント初期設計
- 外部マクロ不安定化: Phase-15中はin-proc限定
- 無限展開: 再帰上限と循環検出（展開履歴）
🚀 次アクション（Codex推奨）
即座に着手すべき
- AST utils（Pattern/Quote/Rewrite）の最小設計確定
- MacroCtx/Registryの最小Trait草案作成
- 関数風マクロ + 簡易衛生 + トレースでスモーク1本
- 属性マクロでProperty糖衣（例: #[once]）実装
実装方針
この方針なら、Property実行系に手を入れず、安全にマクロを導入できるよ。必要ならMacroCtx/Registryの最小APIスケッチもすぐ出すよ。
📊 工数見積もり詳細
| フェーズ | 内容 | 期間 | 累積 |
|---|---|---|---|
| Phase A | AST基盤 | 3-5日 | 1週間 |
| Phase B | 最小マクロ | 7-10日 | 2-3週間 |
| Phase C | Box化・属性 | 7-10日 | 4-6週間 |
| Phase D | 高機能化 | 1-2週間 | 6-8週間 |
最小ルート（急ぎ）
- 最小を急げば: 2-3週間
- 充実まで: 4-6週間
結論: Codexの技術分析により、Box-Based Macro Systemは既存アーキテクチャを壊すことなく、段階的に実装可能であることが確認された。
技術的制約とリスクを明確化し、現実的な実装ロードマップを提示。