4e824fa00e
🌟 Phase 12.7文法改革に基づくドキュメント更新 - init {} → field: TypeBox 個別フィールド宣言形式 - init() → birth() コンストラクタ統一 - pack() → 廃止（birth()に統一） - public {}/private {} → 個別フィールド修飾子 - override → 廃止（メソッド定義はシンプルに） 📚 更新したドキュメント - CLAUDE.md: メイン開発ガイド - docs/quick-reference/syntax-cheatsheet.md: 構文早見表 - docs/reference/language/LANGUAGE_REFERENCE_2025.md: 言語リファレンス - docs/development/roadmap/phases/phase-15/README.md: Phase 15計画 🔧 VMリファクタリング準備 - vm_methods.rs: VMメソッド呼び出しの分離 - plugin_loader.rs → plugin_loader/: ディレクトリ構造化 - mir/builder/exprs.rs: 式ビルダー分離 📝 新規ドキュメント追加 - 論文戦略・ロードマップ - Phase 15セルフホスティング準備資料 - Codex Androidセットアップガイド ビルドは正常に通ることを確認済み！🎉 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
3.6 KiB
3.6 KiB
論文分担戦略 - MIR13時代の2本構成
Date: 2025-09-03 Status: Active Strategy
📊 2本の論文の違い（一目でわかる表）
| 観点 | Paper A（実装の幅） | Paper B（設計の深さ） |
|---|---|---|
| タイトル | From Interpreter to Native GUI Apps | The Simple Lifecycle Philosophy |
| 焦点 | 何ができるか（WHAT） | なぜできるか（WHY） |
| 読者 | システム研究者 | 言語設計者 |
| データ | 性能・サイズ・実行時間 | 設計メトリクス・学習曲線 |
| 評価 | 5つの実行形態の比較 | API一貫性・拡張性 |
| 投稿先 | ASPLOS, CGO, OSDI | PLDI, OOPSLA, Onward! |
| ページ数 | 12-14ページ | 10-12ページ |
🎯 なぜこの分け方が良いのか
1. メッセージの明確化
- Paper A: 「13命令でこんなにできる！」（驚き）
- Paper B: 「なぜ13で済むのか」（洞察）
2. 評価の適切性
- Paper A: 定量的評価（ベンチマーク）
- Paper B: 定性的評価（設計の美しさ）
3. 読者層の最適化
- Paper A: 実装したい人向け
- Paper B: 設計を学びたい人向け
📝 具体的な内容分担
Paper A に入れるもの
- ✅ MIR13の命令リスト
- ✅ 5つの実行形態の実装詳細
- ✅ 性能ベンチマーク結果
- ✅ 実アプリのスクリーンショット
- ✅ バイナリサイズ比較
- ✅ コンパイル時間測定
- ❌ Box哲学の詳細（軽く触れる程度）
- ❌ ライフサイクル設計論
Paper B に入れるもの
- ✅ Everything is Box哲学
- ✅ ライフサイクルの3段階
- ✅ なぜ13命令で十分かの説明
- ✅ User/Plugin/Builtinの統一性
- ✅ 学習曲線の分析
- ✅ コード削減率（80k→20k）
- ❌ 詳細な性能データ
- ❌ 実装のテクニカルな話
🔄 相互参照の仕方
Paper A での言及
"The simplicity of MIR13 is enabled by the Everything-is-Box
philosophy, which we explore in depth in [Paper B]."
Paper B での言及
"The practical implications of this design are demonstrated
in [Paper A], where we show implementations ranging from
interpreters to GUI applications."
📅 執筆スケジュール
Phase 1: Paper A 優先（9-10月）
- Week 1-2: データ収集・ベンチマーク
- Week 3-4: 執筆・図表作成
- Week 5: レビュー・推敲
Phase 2: Paper B 熟成（11-12月）
- Month 1: 設計分析・メトリクス収集
- Month 2: 執筆・ケーススタディ
理由
- Paper Aは実装済みでデータがある
- Paper Bは使用経験を積んでから書く方が深い
💡 書き方のコツ
Paper A（実装論文）のコツ
- デモ重視: スクリーンショット多用
- 数値で語る: グラフ・表を活用
- 再現性: ソースコード公開を明記
Paper B（設計論文）のコツ
- 図解重視: 概念図・アーキテクチャ図
- 例で語る: 具体的なコード例
- 比較で語る: 他言語との違い
🎯 最終目標
短期（2025年）
- Paper A → ASPLOS/CGO採択
- Paper B → PLDI/OOPSLA投稿
中期（2026年）
- 両論文の内容を統合した招待講演
- チュートリアル・ワークショップ開催
長期（2027年以降）
- 書籍化："The Nyash Way: Simplicity in Language Design"
- 教育カリキュラムへの採用
🌟 成功の鍵
Paper A: 実装の幅広さで驚かせる Paper B: 設計のシンプルさで感動させる
2本合わせて、Nyashの革新性を完全に伝える！