020990463d
MIR13論文とNyash言語論文について、Gemini先生とCodex先生の 詳細レビューを受けて大幅改訂： MIR13論文の改善： - 「完全な」→「実用的な」に表現を適正化 - 57命令からの削減経緯を議論セクションに追加 - Python/Go/Rustとの絶対性能比較を追加 - BoxCallのオーバーヘッド分析を追加 - ランタイムシステムの役割を明記 - 関連研究に比較表とメッセージパッシング系譜を追加 Nyash言語論文の改善： - マイクロベンチマーク追加（Python/Lua/Swift比較） - HTTPサーバーベンチマーク追加 - メモリ管理モデル比較表追加 - 循環参照への対応方針（weak参照導入計画）を明記 - MIR13との相互作用を説明 - 関連研究の比較表で位置付けを明確化 また、AI先生方のレビュー記録をアーカイブに保存。 開発は2025-08-09開始、約1ヶ月での成果。 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
150 lines
7.9 KiB
Markdown
150 lines
7.9 KiB
Markdown
# AI論文レビュー記録 - 2025年9月5日
|
||
|
||
## 概要
|
||
MIR13論文とNyash言語論文について、Gemini先生とCodex先生による詳細レビューを実施。
|
||
|
||
## Gemini先生のレビュー
|
||
|
||
### MIR13論文レビュー
|
||
|
||
#### 総評
|
||
この論文が提案する「MIR13」は、`BoxCall`という統一的な抽象化によってLoad/Store命令を完全に廃止し、わずか13命令で汎用プログラミング言語を表現するという、**極めて野心的かつ新規性の高い研究**です。
|
||
|
||
#### 1. 技術的新規性：十分か？
|
||
- **評価**: **十分にある。**
|
||
- **根拠**: 従来のIR設計の常識（Load/Store命令の存在）を覆し、「すべてをメッセージパッシングとして扱う」というオブジェクト指向の思想を低レベルIRに適用した点は、明確な新規性です。
|
||
|
||
#### 2. 「13命令」という主張の妥当性：妥当か？
|
||
- **評価**: **妥当だが、説明に注意が必要。**
|
||
- **根拠**: 命令の分類自体は妥当です。しかし、「13命令」という数字の裏で、多くの複雑な処理が`BoxCall`を通じてランタイム（ホスト関数）に委譲されています。
|
||
|
||
#### 3. BoxCall統一の革新性：伝わるか？
|
||
- **評価**: **コンセプトは伝わるが、インパクトが弱い。**
|
||
- **改善点**:
|
||
- **図解の追加**: `BoxCall`がどのようにメモリアクセスやメソッド呼び出しをディスパッチするかのシーケンス図
|
||
- **コード対比**: LLVM IR等とMIR13でどのように表現されるかを並べて見せる
|
||
|
||
#### 4. 3バックエンドでの実装：十分な証明になるか？
|
||
- **評価**: **十分すぎるほど強力な証明。**
|
||
- **根拠**: Interpreter, VM, JITという多様な実行環境で同じIRが機能することを示したのは、この論文の最も強力な貢献の一つです。
|
||
|
||
#### 5. 査読で突かれそうな弱点
|
||
1. **パフォーマンス評価の欠如**: 既存言語（Rust, Go, Python等）との**絶対性能比較**がない
|
||
2. **ランタイムのブラックボックス化**: `Box`のメモリレイアウト、GC戦略が不明
|
||
3. **表現能力への疑念**: async/await、例外処理への対応方針が不明
|
||
4. **関連研究（特にWebAssembly）との比較不足**
|
||
|
||
#### 6. 改善すべき点
|
||
1. **「性能評価」の章を全面的に書き直す**: 標準的なベンチマークスイート使用
|
||
2. **「ランタイムシステム設計」の章を新設**: `Box`の内部表現、GC、ホスト関数呼び出し規約
|
||
3. **「議論」の章を強化**: async/awaitや例外処理の具体例
|
||
|
||
#### 「57命令から削減」のストーリーについて
|
||
**結論：完全にカットするのは悪手。**
|
||
現在の論文の構成（トップダウンでの13命令の提示）は維持しつつ、**「議論(Discussion)」のセクション**で、設計の進化の歴史として「57命令からの削減」に触れるのが最も効果的。
|
||
|
||
### Nyash言語論文レビュー
|
||
|
||
#### 総評
|
||
本論文は、Nyash言語の核心的設計思想である「Everything is Box」と「birth/fini対称性」を提示し、その初期実装と評価を通じて**実現可能性を実証した**と位置づけられています。この位置付けは、現状の実績と将来の課題を正直に記述している点から、**極めて適切かつ戦略的**であると評価できます。
|
||
|
||
#### 1. `birth`/`fini`対称性の新規性と実用性
|
||
- **新規性**: C++のRAIIやRustの`Drop`と類似するが、**完全な対称性**と言語の前面に押し出した設計は新規性が高い
|
||
- **実用性**: 高い実用性が見込める。決定的なリソース解放が可能
|
||
- **課題**: 循環参照問題（SwiftのARCと同じ）
|
||
|
||
#### 2. 「Everything is a Box」の言語設計としての評価
|
||
- **評価**: **非常に強力な統一原理**。Smalltalkの「すべてはオブジェクト」思想に通じる
|
||
- **拡張性の源泉**: ビルトイン型、ユーザ定義型、プラグインがすべて同じ「Box」
|
||
- **性能上の懸念**: 単純な整数`42`ですら`IntegerBox`になるオーバーヘッド
|
||
|
||
#### 3. GC切替を将来構想に留めた判断の妥当性
|
||
- **妥当性**: **極めて妥当かつ賢明な判断**
|
||
- **リスクの分離**: `birth/fini`とトレーシングGCは根本的に思想が異なる
|
||
|
||
#### 4. 実績不足を正直に書いた戦略の是非
|
||
- **戦略**: **学術論文としては最善の戦略**
|
||
- **期待のコントロール**: 「初期評価」「実現可能性の実証」という位置付けと一致
|
||
|
||
#### 5. 査読で指摘されそうな問題点
|
||
1. **性能評価の甘さ**: 具体的なベンチマーク詳細が不足
|
||
2. **`birth`/`fini`の新規性への疑問**: 「RAIIの構文違い？」
|
||
3. **循環参照問題の深刻さ**: 大規模開発での影響
|
||
4. **MIR13との関係性**: 具体的な相互作用が不明瞭
|
||
|
||
#### 6. より説得力を高める方法
|
||
1. **マイクロベンチマークの追加**
|
||
2. **キラーユースケースの提示**
|
||
3. **比較表の作成**: C++(RAII)、Rust(Drop)、Swift(ARC)等との比較
|
||
4. **`fini`とGCの共存モデルの具体化**
|
||
|
||
## Codex先生のレビュー
|
||
|
||
### Executive Summary
|
||
- 相互補完性は高いが、同時投稿なら明確な境界設定が必要
|
||
- PLDI/OOPSLA受理可能性は現状低い → CC/DLS/Onward!が現実的
|
||
- AI校正明記は妥当（簡潔に）
|
||
- 日本語→英語戦略は良い
|
||
|
||
### Acceptance Prospects
|
||
- PLDI/OOPSLA now: low-to-medium（形式化と評価が不足）
|
||
- Better-fit venues:
|
||
- MIR13: CC, VEE, PEPM, GPCE, DLS, Onward!
|
||
- Nyash: Onward!, DLS, ECOOP, ISMM
|
||
|
||
### Venue Recommendations
|
||
- SPLASH pairing (strongly recommended):
|
||
- MIR13 → OOPSLA or CC
|
||
- Nyash → Onward! or DLS
|
||
- Alternatives:
|
||
- 時差投稿（MIR13先行）
|
||
|
||
### Practical Improvements: MIR13 Paper
|
||
1. 「完全なプログラミング言語」を「実用アプリ実装可能」に修正
|
||
2. BoxCallの操作的意味論を形式化
|
||
3. 最適化パス数、LOC、コンパイル時間の比較
|
||
4. 2つの異なるフロントエンド実装
|
||
5. Related work強化（Smalltalk/Self、PyPy等）
|
||
|
||
### Practical Improvements: Nyash Paper
|
||
1. birth/finiライフサイクルの形式化
|
||
2. 循環参照対策（weak reference等）の提示
|
||
3. ケーススタディ（HTTP/P2P/エディタ）の詳細評価
|
||
4. 開発者体験の定性的評価
|
||
5. デバッグ/プロファイリングツールの言及
|
||
|
||
### AI Use Disclosure
|
||
単一行の謝辞："We used large language models for language polishing only; all technical ideas, designs, implementations, and experiments are by the authors."
|
||
|
||
### Why These Two Papers (Justification)
|
||
- 成熟度：両方とも3バックエンド + 実用アプリ動作
|
||
- テーマの一貫性：Box統一による革新
|
||
- 明確な貢献の違い：
|
||
- MIR13: 最小SSA IRとLoad/Store廃止
|
||
- Nyash: ライフサイクル対称メモリモデル
|
||
- 戦略的幅：システムレベル（コンパイラ）とプロダクトレベル（言語）の両面
|
||
|
||
### Actionable Next Steps (4-6 weeks)
|
||
- Week 1-2: 形式的コア確定、weak ref実装、第2フロントエンド追加
|
||
- Week 3-4: ベンチマーク実施、アーティファクト準備、関連研究執筆
|
||
- Week 5: 内部レビュー、英語校正、投稿先別フォーマット
|
||
- Week 6: SPLASH投稿（OOPSLA + Onward!/DLS）
|
||
|
||
---
|
||
|
||
## レビュー統合まとめ
|
||
|
||
### 共通の指摘事項
|
||
1. **パフォーマンス評価の具体化**が最重要
|
||
2. **形式的記述の追加**で学術的価値向上
|
||
3. **投稿先の再検討** - PLDI/OOPSLAは高すぎる目標
|
||
|
||
### 戦略的提案
|
||
1. **SPLASH併催投稿**が最有力（異なるトラックで相互補完）
|
||
2. **AI校正明記**は簡潔に謝辞で
|
||
3. **日本語→英語**の執筆戦略は妥当
|
||
|
||
### 優先改善事項
|
||
1. 絶対性能比較の追加
|
||
2. BoxCall/birth-finiの形式化
|
||
3. 関連研究の充実化 |