json(vm): fix birth dispatch; unify constructor naming (Box.birth/N); JsonNode factories return JsonNodeInstance; quick: enable heavy JSON with probe; builder: NYASH_BUILDER_DEBUG_LIMIT guard; json_query_min(core) harness; docs/tasks updated
81
docs/private/research/docs/private/research/README.md
Normal file
@ -0,0 +1,81 @@
|
||||
# 📚 Nyash研究論文管理
|
||||
|
||||
最終更新: 2025-09-27
|
||||
|
||||
## 🎯 今書いている論文(2本のみ!)
|
||||
|
||||
### 論文セット: MIR14 + Nyash言語
|
||||
|
||||
**目標**: Phase 15完了までに2本セット完成
|
||||
|
||||
#### 1. [MIR14: たった14命令で万能実行系](papers-active/mir14-universal-execution/)
|
||||
- **テーマ**: 実行基盤の最小性(How)
|
||||
- **主張**: 14命令で全実行形態を実現
|
||||
- **進捗**: 構造済み、Phase 15最新仕様に更新中
|
||||
- **完成目標**: 2週間以内
|
||||
|
||||
#### 2. [Nyash言語: Box-First Programming](papers-active/nyash-box-first-language/)
|
||||
- **テーマ**: 言語設計の統一性(What)
|
||||
- **主張**: Everything is Boxの完全実現
|
||||
- **進捗**: 構造済み、Phase 15最新仕様に更新中
|
||||
- **完成目標**: 2週間以内
|
||||
|
||||
**なぜこの2本セット?**
|
||||
- 相互補完性: 理論(言語設計)× 実装(14命令)
|
||||
- ストーリー性: 読者を「驚き」へ導く流れ
|
||||
- 世界初の主張: データ/演算/制御すべてBox + 14命令実装
|
||||
|
||||
---
|
||||
|
||||
## 💡 アイデアメモ(次の論文候補)
|
||||
|
||||
今後の論文候補をメモとして保管。1ファイル50-200行の簡潔メモ。
|
||||
|
||||
**作成予定**:
|
||||
- `operator-box-insights.md`: 演算子Box最強説
|
||||
- `loopform-control-flow.md`: 制御構造のBox化
|
||||
- `ai-collaborative-development.md`: AI協働開発の実践
|
||||
- `mir-unified-call.md`: Call命令統一戦略
|
||||
|
||||
---
|
||||
|
||||
## 📚 完成済み論文
|
||||
|
||||
**現状**: まだなし
|
||||
|
||||
**今後**: 上記2本が最初の完成論文になる予定
|
||||
|
||||
---
|
||||
|
||||
## 🗄️ アーカイブ(低優先度/古い論文)
|
||||
|
||||
`papers-archive/` に41本の論文アイデアを保管。
|
||||
|
||||
**方針**:
|
||||
- 完成論文が1本できたら、次の1本に着手
|
||||
- アーカイブから復活させる可能性もあり
|
||||
- 視界からは消すが、参照は可能
|
||||
|
||||
---
|
||||
|
||||
## 🚀 開発方針
|
||||
|
||||
### **80/20ルール適用**
|
||||
```
|
||||
❌ 悪い: 44本の未完成論文
|
||||
✅ 良い: 2本の完成論文 + 41個のアーカイブ
|
||||
```
|
||||
|
||||
### **完成の定義**
|
||||
- Abstract/Introduction/本文/Conclusion完備
|
||||
- Phase 15最新仕様反映
|
||||
- 実装実証済み
|
||||
- AI査読(ChatGPT/Claude)完了
|
||||
|
||||
### **次の論文に移る条件**
|
||||
- 現在の論文が**完全に完成**してから
|
||||
- 無限未完成サイクルを回避
|
||||
|
||||
---
|
||||
|
||||
**💡 ルール**: 一度に書く論文は**2本まで**(今回はセットなので2本)。完成してから次へ!
|
||||
@ -0,0 +1,89 @@
|
||||
# MIR14 Core‑14 Specification (Draft)
|
||||
|
||||
本メモは、MIR14(Core‑14)命令体系の確定仕様と、レガシー命令の廃止方針をまとめる。実装は"Core‑14既定ON・forbid‑legacy"を前提とする。
|
||||
|
||||
## 1. Core‑14 命令一覧(最小限+実践的)
|
||||
|
||||
| 区分 | 命令 | 役割(要点) |
|
||||
|------|------|---------------|
|
||||
| 値 | Const | 即値・アドレス等の定数生成(副作用なし) |
|
||||
| 演算 | BinOp | 加減乗除/ビット演算(純粋) |
|
||||
| 演算 | UnaryOp | 単項演算(否定、NOT等)【実用性から復活】 |
|
||||
| 演算 | Compare | 比較演算(純粋) |
|
||||
| 制御 | Jump | 無条件遷移(終端) |
|
||||
| 制御 | Branch | 条件分岐遷移(終端) |
|
||||
| 制御 | Return | 関数復帰(終端) |
|
||||
| 形状 | Phi | SSA合流(純粋) |
|
||||
| 呼出 | Call | 直接/間接呼出(ユーザー関数) |
|
||||
| 呼出 | BoxCall | Boxへのメッセージ呼出(配列/フィールド/メソッドの統一) |
|
||||
| 呼出 | ExternCall | ランタイム/プラグインへの呼出(FFI境界) |
|
||||
| 型 | TypeOp | 型判定・型変換(型関連演算の統合) |
|
||||
| 実行 | Safepoint | 安全点(GC/割込み協調) |
|
||||
| 実行 | Barrier | 書込/読込バリア等の最小表現 |
|
||||
|
||||
注:
|
||||
- Branch/Jump/Return は終端命令。Phi は構文木上で合流点にのみ出現。
|
||||
- BoxCall は自由可変長引数(receiver+メソッド名/操作名+args...)を標準とし、BoxCallWithは廃止。
|
||||
|
||||
## 2. IR規約(Invariants)
|
||||
- SSA: すべての値は一度だけ定義。Phiは支配関係に従い配置。
|
||||
- 終端整合: Blockの末尾は {Return|Jump|Branch} のいずれか1つ。
|
||||
- 副作用モデル:
|
||||
- 純粋: Const/BinOp/Compare/Phi
|
||||
- 効果あり: Call/BoxCall/ExternCall/Safepoint/Barrier(効果種別はEffect Maskで注釈可)
|
||||
- Safepoint配置: ループヘッダ/長期待機前/FFI直後などに挿入(最小限)。
|
||||
- Barrier: write/read バリアはCore‑13で抽象化し、下位で最適化。
|
||||
|
||||
## 3. 高位→Core‑13 への標準Lowering
|
||||
- 配列/フィールド/メソッド: すべて BoxCall で統一。
|
||||
- 例) `a[i]` → `BoxCall(a, "get", i)`
|
||||
- 例) `o.name` → `BoxCall(o, "getField", "name")`
|
||||
- 例) `o.add(x)` → `BoxCall(o, "add", x)`
|
||||
- ランタイム/プラグイン: `ExternCall("iface", "method", args...)` による一貫表現。
|
||||
- 型操作: `TypeOp(kind, value[, type])`(型判定/変換を単一路に集約)。
|
||||
- 制御構造: if/loop は Branch/Jump/Phi で表現。
|
||||
|
||||
### 3.1 記法方針(表記と内部の二層)
|
||||
- 表記: 従来の if / while / for / return などの構文を維持(ユーザフレンドリ)。
|
||||
- 内部: LoopForm IR(loop.begin/iter/branch/end)に正規化。
|
||||
- 最終: LoopForm → Core‑13 へ逆Lowering(Branch/Jump/Phi/Return へ落とす)。
|
||||
|
||||
これにより、言語表記の自由度とIRの直交性(正規形)を両立する。
|
||||
|
||||
## 4. LoopForm(LoopSignal IR)との整合
|
||||
- LoopForm は“中間正規形”として `loop.begin/iter/branch/end` を導入(Core‑13の上位層)。
|
||||
- 逆Lowering: LoopForm → Core‑13 は以下の基本変換で常時可能:
|
||||
- `loop.begin` → ヘッダBlock生成+Phi配置
|
||||
- `loop.iter` → 条件/stepコードをヘッダ/ボディに分配
|
||||
- `loop.branch` → `switch/Branch` + `Jump`
|
||||
- `loop.end` → 合流先にReturn/Jump(Signal種別に応じる)
|
||||
- Safepoint/Barrier は Core‑13 層で維持。LoopFormは制御の正規化に専念。
|
||||
|
||||
## 5. レガシー命令の廃止マップ
|
||||
- Load/Store / ArrayGet/ArraySet / RefGet/RefSet / WeakNew/WeakLoad → BoxCall(必要時Barrier/Safepoint併用)
|
||||
- TypeCheck/Cast → TypeOp
|
||||
- PluginInvoke → ExternCall / BoxCall(ABIに応じて)
|
||||
- Nop/Copy/UnOp 等の補助命令 → 最適化/ビルダ内部に吸収(表面APIから排除)
|
||||
|
||||
## 6. ExternCall の階層化(境界の明示)
|
||||
- iface例:
|
||||
- `env.runtime`: ランタイム内部API(checkpoint等)
|
||||
- `env.gc`: GC操作(将来)
|
||||
- `plugin.*`: プラグイン提供のFFI群
|
||||
- 指針: BoxCallで表現可能な操作は BoxCall を優先(抽象度維持)。どうしてもhost境界を越える必要がある場合のみ ExternCall。
|
||||
|
||||
## 7. 妥当性検査(Lint/Verify)
|
||||
- Phi配置の正当性(支配木チェック)
|
||||
- 終端命令の整合
|
||||
- EffectとSafepointの整合(長期ループでの安全点確保)
|
||||
- レガシー命令検出(forbid‑legacy がONであること)
|
||||
|
||||
## 8. 移行計画(段階導入)
|
||||
1) フラグ: Core‑13 既定ON/forbid‑legacy を実装側で保証(nyash.tomlも同値)。
|
||||
2) レガシー→Core‑13 置換を段階実施(ビルダ/最適化/バックエンドを横断)
|
||||
3) LoopForm(任意)を導入し、while/for/scope から正規化→逆LoweringでCore‑13へ落とす
|
||||
4) 検証: 既存スイート + 再現ベンチ(AOT/VM/JIT) + Lint で差分監視
|
||||
|
||||
---
|
||||
|
||||
この文書は“仕様の真実の源泉(single source of truth)”として、Core‑13 と上位LoopFormの整合と廃止路線を明示する。実装の進捗に合わせて更新する。
|
||||
@ -0,0 +1,143 @@
|
||||
# MIR14論文 Phase 15更新計画
|
||||
|
||||
最終更新: 2025-09-27
|
||||
|
||||
## 🎯 更新の目的
|
||||
|
||||
Phase 15の最新仕様(2本柱体制、PHI-on、演算子Box等)を反映し、論文を完成させる。
|
||||
|
||||
---
|
||||
|
||||
## 📋 更新項目リスト
|
||||
|
||||
### 優先度1(必須更新)
|
||||
|
||||
#### 1. **2本柱体制への更新**
|
||||
- ❌ 古い: 5つの実行形態(Interpreter/VM/JIT/AOT/WASM)
|
||||
- ✅ 新: 2本柱 + 特殊用途
|
||||
- Rust VM: 開発・デバッグ・検証(712行の高品質実装)
|
||||
- LLVM: 本番・最適化・配布(Python/llvmlite)
|
||||
- PyVM: JSON v0ブリッジ専用
|
||||
|
||||
**更新箇所**:
|
||||
- README.md: 実行形態の説明
|
||||
- chapters/05-evaluation.md: ベンチマーク対象
|
||||
- main-paper-jp.md: 実行モデル図
|
||||
|
||||
#### 2. **PHI-on標準化**
|
||||
- ❌ 古い: PHI-off(エッジコピー)前提
|
||||
- ✅ 新: PHI-on標準、LoopForm実装
|
||||
|
||||
**更新箇所**:
|
||||
- MIR13_CORE13_SPEC.md → MIR14_SPEC.md
|
||||
- chapters/02-box-theory.md: SSA形式説明追加
|
||||
- 制御構造の説明でLoopForm追加
|
||||
|
||||
#### 3. **LoopForm: 制御構造のBox化**
|
||||
- ❌ 古い: ループは特殊構文
|
||||
- ✅ 新: LoopFormで制御もBox化
|
||||
|
||||
**追加内容**:
|
||||
- LoopFormの設計と実装
|
||||
- PHI生成の自動化
|
||||
- break/continue処理
|
||||
|
||||
#### 4. **Callee型: 型安全な関数呼び出し**
|
||||
- ❌ 古い: 文字列ベースの関数解決
|
||||
- ✅ 新: Callee enum(Global/Method/Value/Extern)
|
||||
|
||||
**追加内容**:
|
||||
- シャドウイング問題の解決
|
||||
- コンパイル時型解決
|
||||
- VM/LLVM両対応
|
||||
|
||||
### 優先度2(強く推奨)
|
||||
|
||||
#### 5. **演算子Box統一**
|
||||
- 新機能: AddOperator, CompareOperator等
|
||||
- observe/adopt段階的移行
|
||||
- デバッグ可視化の威力
|
||||
|
||||
**追加箇所**:
|
||||
- chapters/03-boxcall-unification.md: 演算子Box追加
|
||||
- 実装例とデバッグ事例
|
||||
|
||||
#### 6. **実装実証の更新**
|
||||
- JSON Native: 完全な構文解析器
|
||||
- スモークテスト: quick/integration/full
|
||||
- VM/LLVMパリティ検証
|
||||
|
||||
**更新箇所**:
|
||||
- chapters/05-evaluation.md: 最新ベンチマーク
|
||||
- 実アプリケーション例
|
||||
|
||||
### 優先度3(あれば尚良)
|
||||
|
||||
#### 7. **MIR Unified Call計画**
|
||||
- 6種類のCall → 1つのMirCallに統一予定
|
||||
- 7,372行 → 5,468行(26%削減見込み)
|
||||
|
||||
**記載内容**:
|
||||
- Future Workとして言及
|
||||
- Phase 15.5以降の計画
|
||||
|
||||
---
|
||||
|
||||
## 📊 章構成(更新後)
|
||||
|
||||
### Introduction
|
||||
- Nyash言語とMIR14の概要
|
||||
- 2本柱体制の説明
|
||||
- Everything is Box哲学
|
||||
|
||||
### Chapter 2: MIR14設計
|
||||
- 14命令の詳細
|
||||
- PHI-on標準化
|
||||
- LoopFormによる制御Box化
|
||||
- Callee型による型安全化
|
||||
|
||||
### Chapter 3: BoxCall統一
|
||||
- データBox
|
||||
- 演算子Box(新規追加)
|
||||
- 制御Box(LoopForm)
|
||||
|
||||
### Chapter 4: 2本柱実装
|
||||
- Rust VM: 開発・デバッグ
|
||||
- LLVM: 本番・最適化
|
||||
- VM/LLVMパリティ戦略
|
||||
|
||||
### Chapter 5: 実装実証
|
||||
- JSON Native
|
||||
- スモークテスト結果
|
||||
- ベンチマーク
|
||||
|
||||
### Conclusion
|
||||
- Everything is Boxの完全実現
|
||||
- 世界初: 14命令で完全実装
|
||||
- Future Work: MIR Unified Call
|
||||
|
||||
---
|
||||
|
||||
## ✅ 完成チェックリスト
|
||||
|
||||
- [ ] README.md更新
|
||||
- [ ] MIR14_SPEC.md作成
|
||||
- [ ] Chapter 2: MIR14設計(PHI-on, LoopForm追加)
|
||||
- [ ] Chapter 3: BoxCall統一(演算子Box追加)
|
||||
- [ ] Chapter 4: 2本柱実装(新規作成)
|
||||
- [ ] Chapter 5: 実装実証(最新データ)
|
||||
- [ ] main-paper-jp.md統合
|
||||
- [ ] Abstract更新
|
||||
- [ ] AI査読(ChatGPT/Claude)
|
||||
|
||||
---
|
||||
|
||||
## 🗓️ スケジュール
|
||||
|
||||
- **Day 1-2**: 構造更新、MIR14_SPEC作成
|
||||
- **Day 3-5**: Chapter 2-3更新(PHI-on, LoopForm, 演算子Box)
|
||||
- **Day 6-7**: Chapter 4-5更新(2本柱、実証)
|
||||
- **Day 8**: 統合、AI査読
|
||||
- **Day 9-10**: 修正、完成
|
||||
|
||||
**目標**: 10日以内に完成 ✨
|
||||
@ -0,0 +1,105 @@
|
||||
# 論文A: MIR14で作る万能実行系
|
||||
|
||||
> Scope (2025-09-19): 本稿の実験・評価は PyVM(意味論リファレンス)と LLVM/llvmlite(AOT/EXEハーネス)に限定する。MIR は PHI‑off(合流はエッジコピー)で、PHI 形成は LLVM 側で合成する。詳細は SCOPE.md を参照。
|
||||
|
||||
## 📚 概要
|
||||
|
||||
**タイトル**: From Interpreter to Native GUI Apps: Universal Execution with 14 Core Instructions
|
||||
|
||||
**主題**: 14命令のミニマルIRで実現する5つの実行形態(インタープリター/VM/JIT/AOT/GUI)
|
||||
|
||||
**対象読者**: システム研究者、言語実装者、実用性重視の開発者
|
||||
|
||||
## 🌱 MIR命令数の進化史
|
||||
|
||||
**初期**: 27命令前後(汎用的にあれもこれも欲しい状態)
|
||||
↓
|
||||
**削減会議**: Box哲学と抽象化を突き詰めて13命令まで削減
|
||||
↓
|
||||
**復活**: 「最低限の算術演算は直接あった方が良い」という判断で UnaryOp を追加
|
||||
↓
|
||||
**MIR14**: 現在のコア命令セット(Core-13 + UnaryOp = 14命令)
|
||||
|
||||
## 🎯 研究ポイント
|
||||
|
||||
### 1. 実装の完全性
|
||||
- **インタープリター**: 開発・デバッグ用(500行)
|
||||
- **VM**: 高速実行(1000行)
|
||||
- **JIT/AOT**: Cranelift統合でネイティブ性能
|
||||
- **EXE生成**: lld内蔵で完全自立
|
||||
- **Windows GUIアプリ**: EguiBoxで実用アプリ
|
||||
|
||||
### 2. MIR14の威力
|
||||
- 14命令(Core-13 + UnaryOp)ですべての実行形態をサポート
|
||||
- 27命令 → 13命令 → 14命令への実践的な進化
|
||||
- BoxCallへの統一と必要最小限の算術演算
|
||||
|
||||
### 3. 実用性の証明
|
||||
- サイコロRPG(ゲーム)
|
||||
- 統計計算ツール(数値計算)
|
||||
- LISPインタープリター(言語処理系)
|
||||
- ファイルエクスプローラー(GUIアプリ)
|
||||
|
||||
## 📊 実験計画
|
||||
|
||||
### 実行形態の比較
|
||||
- **起動時間**: Interpreter < VM < JIT < AOT < GUI
|
||||
- **実行速度**: Interpreter < VM < JIT ≈ AOT
|
||||
- **バイナリサイズ**: Script < VM < JIT < AOT < GUI
|
||||
- **メモリ使用量**: 各形態での比較
|
||||
|
||||
### 実アプリケーション評価
|
||||
- **サイコロRPG**: ゲームループ性能(60fps達成)
|
||||
- **統計計算**: 大規模データ処理(100万件)
|
||||
- **GUIレスポンス**: ユーザー操作の遅延(<16ms)
|
||||
- **コンパイル時間**: ソース→EXEの所要時間
|
||||
|
||||
## 📁 ディレクトリ構造
|
||||
|
||||
```
|
||||
paper-a-mir13-ir-design/
|
||||
├── README.md # このファイル
|
||||
├── abstract.md # 論文概要
|
||||
├── main-paper.md # 本文
|
||||
├── chapters/ # 章別ファイル
|
||||
│ ├── 01-introduction.md
|
||||
│ ├── 02-mir-evolution.md
|
||||
│ ├── 03-boxcall-unification.md
|
||||
│ ├── 04-optimization-techniques.md
|
||||
│ ├── 05-evaluation.md
|
||||
│ └── 06-conclusion.md
|
||||
├── figures/ # 図表
|
||||
│ ├── mir-instruction-reduction.png
|
||||
│ ├── performance-comparison.png
|
||||
│ └── boxcall-architecture.svg
|
||||
├── data/ # 実験データ
|
||||
│ ├── benchmark-results/
|
||||
│ └── mir-statistics/
|
||||
└── related-work.md # 関連研究
|
||||
|
||||
```
|
||||
|
||||
## 🗓️ スケジュール
|
||||
|
||||
- **2025年9月前半**: 実験実施・データ収集
|
||||
- **2025年9月中旬**: 執筆開始
|
||||
- **2025年9月末**: arXiv投稿(速報版)
|
||||
- **2025年11月**: POPL/PLDI 2026投稿
|
||||
|
||||
## 📝 執筆メモ
|
||||
|
||||
### 強調すべき貢献
|
||||
1. **実装の幅広さ**: 1つのIRで5つの実行形態を実現
|
||||
2. **完全な自立性**: 外部コンパイラ・リンカー不要
|
||||
3. **実用アプリ動作**: GUIアプリまで実際に動く
|
||||
|
||||
### 新規性
|
||||
- 13命令で実用GUIアプリまで動かした初の事例
|
||||
- インタープリターからネイティブまでの統一パイプライン
|
||||
- Cranelift + lld内蔵による完全自己完結型言語
|
||||
|
||||
## 🔗 関連ドキュメント
|
||||
|
||||
- [MIR Instruction Set](../../../../reference/mir/INSTRUCTION_SET.md)
|
||||
- [Phase 11.8 MIR Cleanup](../../../../development/roadmap/phases/phase-11.8_mir_cleanup/)
|
||||
- [Phase 12 TypeBox統合](../../../../development/roadmap/phases/phase-12/)
|
||||
@ -0,0 +1,32 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
OUT_DIR=$(cd "$(dirname "$0")" && pwd)
|
||||
OUT_FILE="$OUT_DIR/ENVIRONMENT.txt"
|
||||
|
||||
{
|
||||
echo "== Datetime =="
|
||||
date -Iseconds || date
|
||||
echo
|
||||
echo "== OS =="
|
||||
uname -a || true
|
||||
lsb_release -a 2>/dev/null || true
|
||||
sw_vers 2>/dev/null || true
|
||||
systeminfo 2>/dev/null | head -n 30 || true
|
||||
echo
|
||||
echo "== CPU =="
|
||||
lscpu 2>/dev/null || sysctl -a 2>/dev/null | grep machdep.cpu || true
|
||||
echo
|
||||
echo "== Rust toolchain =="
|
||||
rustc --version 2>/dev/null || true
|
||||
cargo --version 2>/dev/null || true
|
||||
echo
|
||||
echo "== Git =="
|
||||
git rev-parse HEAD 2>/dev/null || true
|
||||
echo
|
||||
echo "== Cranelift/JIT features =="
|
||||
rg -n "cranelift|jit" -S ../../../../ -g '!target' 2>/dev/null || true
|
||||
} > "$OUT_FILE"
|
||||
|
||||
echo "[DONE] Wrote $OUT_FILE"
|
||||
|
||||
@ -0,0 +1,25 @@
|
||||
This folder contains reproducibility artifacts for Paper A (MIR13 IR design).
|
||||
|
||||
Files
|
||||
- `COLLECT_ENV.sh`: Captures host OS/CPU/toolchain/git info into `ENVIRONMENT.txt`.
|
||||
- `RUN_BENCHMARKS.sh`: Runs interpreter/VM/JIT/AOT (if available) against sample benchmarks and writes CSVs to `results/`.
|
||||
- `results/`: Output CSVs (per benchmark and per mode). Merge/plot as needed.
|
||||
|
||||
Usage
|
||||
1) Capture environment
|
||||
./COLLECT_ENV.sh
|
||||
|
||||
2) Build (full)
|
||||
cargo build --release --features cranelift-jit
|
||||
|
||||
3) Run benchmarks
|
||||
./RUN_BENCHMARKS.sh
|
||||
|
||||
Variables:
|
||||
- NYASH_BIN: Path to nyash binary (default: target/release/nyash)
|
||||
- USE_EXE_ONLY=1: Only measure AOT executables (skips interp/vm/jit)
|
||||
|
||||
Notes
|
||||
- AOT requires `tools/build_aot.sh`. If missing, AOT is skipped.
|
||||
- If `hyperfine` is not installed, a simple timing fallback is used.
|
||||
|
||||
@ -0,0 +1,195 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
# Reproducible benchmarks for MIR13 paper (Interpreter/VM/JIT/AOT if available)
|
||||
# Outputs CSVs under _artifacts/results/
|
||||
|
||||
if ROOT_DIR=$(git -C "$(dirname "$0")" rev-parse --show-toplevel 2>/dev/null); then
|
||||
ROOT_DIR="$ROOT_DIR/nyash"
|
||||
[[ -d "$ROOT_DIR" ]] || ROOT_DIR=$(git rev-parse --show-toplevel)
|
||||
else
|
||||
# Fallback: ascend to repo root from _artifacts
|
||||
ROOT_DIR=$(cd "$(dirname "$0")/../../../../.." && pwd)
|
||||
fi
|
||||
ART_DIR=$(cd "$(dirname "$0")" && pwd)
|
||||
RES_DIR="$ART_DIR/results"
|
||||
mkdir -p "$RES_DIR"
|
||||
|
||||
NYASH_BIN=${NYASH_BIN:-"$ROOT_DIR/target/release/nyash"}
|
||||
SKIP_INTERP=${SKIP_INTERP:-0} # 1: skip interpreter(遅い環境向け)
|
||||
USE_LLVM_AOT=${USE_LLVM_AOT:-0} # 1: LLVM backendでAOTも計測
|
||||
SKIP_AOT=${SKIP_AOT:-0} # 1: tools/build_aot.sh 経由のAOT計測をスキップ
|
||||
RUNS=${RUNS:-10} # 計測回数
|
||||
USE_EXE_ONLY=${USE_EXE_ONLY:-0} # 1: measure AOT exe only
|
||||
HYPERFINE=$(command -v hyperfine || true)
|
||||
TIMEOUT_SECS=${TIMEOUT_SECS:-0} # >0 なら各コマンドをtimeoutでラップ
|
||||
TIMEOUT_BIN=$(command -v timeout || true)
|
||||
|
||||
BENCH_DIR="$ROOT_DIR/benchmarks"
|
||||
FILES=(
|
||||
"$BENCH_DIR/bench_light.nyash"
|
||||
"$BENCH_DIR/bench_medium.nyash"
|
||||
"$BENCH_DIR/bench_heavy.nyash"
|
||||
"$BENCH_DIR/bench_aot_len_light.nyash"
|
||||
"$BENCH_DIR/bench_aot_len_medium.nyash"
|
||||
"$BENCH_DIR/bench_aot_len_heavy.nyash"
|
||||
"$ROOT_DIR/examples/aot_min_string_len.nyash"
|
||||
# Pure arithmetic (no plugins)
|
||||
"$BENCH_DIR/bench_arith_pure_light.nyash"
|
||||
"$BENCH_DIR/bench_arith_pure_medium.nyash"
|
||||
"$BENCH_DIR/bench_arith_pure_heavy.nyash"
|
||||
)
|
||||
|
||||
FILTER_REGEX=${FILTER:-}
|
||||
|
||||
echo "[INFO] NYASH_BIN=$NYASH_BIN"
|
||||
echo "[INFO] USE_EXE_ONLY=$USE_EXE_ONLY (1=EXE only)"
|
||||
echo "[INFO] hyperfine=${HYPERFINE:-not found}"
|
||||
echo "[INFO] USE_LLVM_AOT=$USE_LLVM_AOT (1=measure LLVM AOT)"
|
||||
echo "[INFO] SKIP_AOT=$SKIP_AOT (1=skip AOT via tools/build_aot.sh)"
|
||||
echo "[INFO] RUNS=$RUNS"
|
||||
|
||||
if [[ ! -x "$NYASH_BIN" && "$USE_EXE_ONLY" -eq 0 ]]; then
|
||||
echo "[INFO] Building nyash (release, with JIT feature)"
|
||||
(cd "$ROOT_DIR" && cargo build --release --features cranelift-jit)
|
||||
fi
|
||||
|
||||
have_build_aot=0
|
||||
if [[ -x "$ROOT_DIR/tools/build_aot.sh" ]]; then
|
||||
have_build_aot=1
|
||||
fi
|
||||
|
||||
have_build_llvm=0
|
||||
if [[ -x "$ROOT_DIR/tools/build_llvm.sh" ]]; then
|
||||
have_build_llvm=1
|
||||
fi
|
||||
|
||||
run_cmd() {
|
||||
local cmd="$1" label="$2" csv="$3"
|
||||
local cmd_wrap="$cmd"
|
||||
if [[ -n "$TIMEOUT_BIN" && "$TIMEOUT_SECS" -gt 0 ]]; then
|
||||
cmd_wrap="$TIMEOUT_BIN ${TIMEOUT_SECS}s $cmd"
|
||||
fi
|
||||
if [[ -n "$HYPERFINE" ]]; then
|
||||
# runs configurable, warmup 1, export CSV
|
||||
$HYPERFINE -w 1 -r "$RUNS" --export-csv "$csv" --show-output "$cmd_wrap"
|
||||
else
|
||||
# Simple fallback: run 10 times and record naive timing (ms)
|
||||
: > "$csv"
|
||||
for i in $(seq 1 "$RUNS"); do
|
||||
local t0=$(python3 - <<<'import time; print(int(time.time()*1000))')
|
||||
bash -lc "$cmd_wrap" >/dev/null 2>&1 || true
|
||||
local t1=$(python3 - <<<'import time; print(int(time.time()*1000))')
|
||||
echo "$label,$((t1-t0))" >> "$csv"
|
||||
done
|
||||
fi
|
||||
}
|
||||
|
||||
# Measure modes
|
||||
for f in "${FILES[@]}"; do
|
||||
if [[ -n "$FILTER_REGEX" ]]; then
|
||||
if [[ ! "$f" =~ $FILTER_REGEX ]]; then
|
||||
echo "[INFO] FILTER: skip $f"
|
||||
continue
|
||||
fi
|
||||
fi
|
||||
[[ -f "$f" ]] || { echo "[WARN] Skip missing $f"; continue; }
|
||||
base=$(basename "$f" .nyash)
|
||||
|
||||
if [[ "$USE_EXE_ONLY" -eq 0 ]]; then
|
||||
# Interpreter
|
||||
if [[ "$SKIP_INTERP" -eq 0 ]]; then
|
||||
run_cmd "$NYASH_BIN $f" "interp-$base" "$RES_DIR/${base}_interp.csv"
|
||||
else
|
||||
echo "[INFO] SKIP_INTERP=1: skipping interpreter for $f"
|
||||
fi
|
||||
# VM
|
||||
run_cmd "$NYASH_BIN --backend vm $f" "vm-$base" "$RES_DIR/${base}_vm.csv"
|
||||
# JIT (VM + JIT execute)
|
||||
run_cmd "NYASH_JIT_EXEC=1 $NYASH_BIN --backend vm $f" "jit-$base" "$RES_DIR/${base}_jit.csv"
|
||||
fi
|
||||
|
||||
# AOT (if tool available)
|
||||
if [[ $have_build_aot -eq 1 && "$SKIP_AOT" -eq 0 ]]; then
|
||||
out="/tmp/ny_${base}_aot"
|
||||
bash "$ROOT_DIR/tools/build_aot.sh" "$f" -o "$out" >/dev/null 2>&1 || true
|
||||
if [[ -x "$out" ]]; then
|
||||
run_cmd "$out" "aot-$base" "$RES_DIR/${base}_aot.csv"
|
||||
rm -f "$out"
|
||||
else
|
||||
echo "[WARN] AOT build failed for $f"
|
||||
fi
|
||||
else
|
||||
if [[ "$SKIP_AOT" -eq 1 ]]; then
|
||||
echo "[INFO] SKIP_AOT=1: skipping AOT for $f"
|
||||
else
|
||||
echo "[INFO] AOT tool not found; skipping AOT for $f"
|
||||
fi
|
||||
fi
|
||||
done
|
||||
|
||||
# LLVM AOT-only targets (optional)
|
||||
if [[ "$USE_LLVM_AOT" -eq 1 ]]; then
|
||||
if [[ $have_build_llvm -eq 0 ]]; then
|
||||
echo "[WARN] tools/build_llvm.sh not found; skipping LLVM AOT"
|
||||
elif ! command -v llvm-config-18 >/dev/null 2>&1; then
|
||||
echo "[WARN] llvm-config-18 not found; skipping LLVM AOT"
|
||||
else
|
||||
LLVM_FILES=(
|
||||
"$ROOT_DIR/apps/tests/ny-llvm-smoke/main.nyash"
|
||||
)
|
||||
for f in "${LLVM_FILES[@]}"; do
|
||||
[[ -f "$f" ]] || { echo "[WARN] Skip missing LLVM target $f"; continue; }
|
||||
base=$(basename "$f" .nyash)
|
||||
out="/tmp/ny_${base}_llvm"
|
||||
# Build via LLVM backend
|
||||
LLVM_SYS_180_PREFIX=$(llvm-config-18 --prefix) \
|
||||
LLVM_SYS_181_PREFIX=$(llvm-config-18 --prefix) \
|
||||
"$ROOT_DIR/tools/build_llvm.sh" "$f" -o "$out" >/dev/null 2>&1 || true
|
||||
if [[ -x "$out" ]]; then
|
||||
run_cmd "$out" "llvm-aot-$base" "$RES_DIR/${base}_llvm_aot.csv"
|
||||
rm -f "$out"
|
||||
else
|
||||
echo "[WARN] LLVM AOT build failed for $f"
|
||||
fi
|
||||
done
|
||||
fi
|
||||
fi
|
||||
|
||||
# JIT-AOT (Cranelift) via --jit-direct (optional)
|
||||
USE_JIT_AOT=${USE_JIT_AOT:-0}
|
||||
echo "[INFO] USE_JIT_AOT=$USE_JIT_AOT (1=measure JIT AOT via jit-direct)"
|
||||
if [[ "$USE_JIT_AOT" -eq 1 ]]; then
|
||||
echo "[JIT-AOT] Building nyash + nyrt ..."
|
||||
(cd "$ROOT_DIR" && cargo build --release --features cranelift-jit >/dev/null)
|
||||
(cd "$ROOT_DIR/crates/nyrt" && cargo build --release >/dev/null)
|
||||
|
||||
JIT_AOT_FILES=(
|
||||
"$ROOT_DIR/apps/examples/array_p0.nyash"
|
||||
)
|
||||
for f in "${JIT_AOT_FILES[@]}"; do
|
||||
[[ -f "$f" ]] || { echo "[WARN] Skip missing JIT-AOT target $f"; continue; }
|
||||
base=$(basename "$f" .nyash)
|
||||
objdir="$ROOT_DIR/target/aot_objects"
|
||||
rm -rf "$objdir" && mkdir -p "$objdir"
|
||||
# Emit object via JIT-direct (relaxed)
|
||||
NYASH_JIT_EVENTS=1 NYASH_AOT_OBJECT_OUT="$objdir/main.o" "$NYASH_BIN" --jit-direct "$f" >/dev/null || true
|
||||
if [[ -f "$objdir/main.o" ]]; then
|
||||
out="/tmp/ny_${base}_jit_aot"
|
||||
cc "$objdir/main.o" \
|
||||
-L "$ROOT_DIR/target/release" \
|
||||
-Wl,--whole-archive -lnyrt -Wl,--no-whole-archive \
|
||||
-lpthread -ldl -lm -o "$out"
|
||||
if [[ -x "$out" ]]; then
|
||||
run_cmd "$out" "jit-aot-$base" "$RES_DIR/${base}_jit_aot.csv"
|
||||
rm -f "$out"
|
||||
else
|
||||
echo "[WARN] link failed for JIT-AOT target $f"
|
||||
fi
|
||||
else
|
||||
echo "[WARN] JIT AOT object not generated for $f"
|
||||
fi
|
||||
done
|
||||
fi
|
||||
|
||||
echo "[DONE] Results in $RES_DIR"
|
||||
@ -0,0 +1,41 @@
|
||||
#!/usr/bin/env python3
|
||||
import sys, os, csv, statistics
|
||||
|
||||
def scan_results(path):
|
||||
rows = []
|
||||
for name in sorted(os.listdir(path)):
|
||||
if not name.endswith('.csv'):
|
||||
continue
|
||||
fpath = os.path.join(path, name)
|
||||
with open(fpath, newline='') as f:
|
||||
rdr = csv.reader(f)
|
||||
vals = []
|
||||
label = None
|
||||
for r in rdr:
|
||||
if not r:
|
||||
continue
|
||||
label = r[0]
|
||||
try:
|
||||
vals.append(float(r[1]))
|
||||
except Exception:
|
||||
pass
|
||||
if label and vals:
|
||||
rows.append((name, label, len(vals), statistics.median(vals), statistics.mean(vals)))
|
||||
return rows
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print("usage: gen_table.py <results_dir>", file=sys.stderr)
|
||||
sys.exit(1)
|
||||
res = scan_results(sys.argv[1])
|
||||
if not res:
|
||||
print("no CSVs found", file=sys.stderr)
|
||||
sys.exit(2)
|
||||
print("| File | Label | N | Median (ms) | Mean (ms) |")
|
||||
print("|------|-------|---|-------------:|----------:|")
|
||||
for name, label, n, med, mean in res:
|
||||
print(f"| {name} | {label} | {n} | {med:.1f} | {mean:.1f} |")
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
|
||||
@ -0,0 +1,27 @@
|
||||
# Abstract
|
||||
|
||||
## English Version
|
||||
|
||||
We present MIR-14, a minimal yet practical intermediate representation that evolves from an initial 27-instruction set through aggressive reduction to 13 instructions, then pragmatically adds back one essential operation (UnaryOp) for a final count of 14 core instructions. This evolution demonstrates the tension between theoretical minimalism and practical efficiency in compiler design.
|
||||
|
||||
Our key contributions are: (1) systematic instruction set evolution from Core-27 → Core-13 → Core-14 through empirical validation; (2) the BoxCall unification architecture that elegantly handles all data access patterns; (3) recognition that certain primitive operations (UnaryOp for negation and NOT) significantly improve both compilation efficiency and runtime performance; (4) optimization strategies including inline caching (33x speedup), AOT compilation, and typed array specialization that complement the minimal instruction set; (5) proof that the "Everything is Box" philosophy can be effectively realized at the IR level while maintaining practical performance.
|
||||
|
||||
Implementation results show that despite halving the instruction count, our benchmarks maintain performance within ±5% of the baseline while reducing MIR code size by 20-50%. The system successfully compiles complex applications including GUI programs, web servers, and distributed systems. This work demonstrates that IR minimalism, when coupled with strategic optimization placement, can achieve both extreme simplicity and production-level performance.
|
||||
|
||||
Our approach challenges the trend toward increasingly complex intermediate representations (e.g., LLVM's 60+ opcodes), showing that careful design can achieve more with less. We believe MIR-14 opens new possibilities for compiler construction, optimization research, and language implementation education.
|
||||
|
||||
## 日本語版
|
||||
|
||||
本研究では、初期の27命令セットから積極的な削減により13命令まで圧縮し、その後実用性を考慮して必須演算(UnaryOp)を追加した14命令の最小限かつ実践的な中間表現MIR-14を提示する。この進化は、コンパイラ設計における理論的ミニマリズムと実践的効率性の間の緊張関係を示している。
|
||||
|
||||
本研究の主要な貢献は以下の通りである:(1)Core-27 → Core-13 → Core-14への段階的な命令セット進化の実証的検証、(2)すべてのデータアクセスパターンをエレガントに処理するBoxCall統一アーキテクチャ、(3)特定のプリミティブ演算(否定やNOT演算のためのUnaryOp)がコンパイル効率と実行時性能の両方を大幅に改善するという認識、(4)最小命令セットを補完するインラインキャッシング(33倍高速化)、AOTコンパイル、型付き配列特化などの最適化戦略、(5)「Everything is Box」哲学が実用的な性能を維持しながらIRレベルで効果的に実現可能であることの証明。
|
||||
|
||||
実装結果は、命令数を半減させたにもかかわらず、ベンチマークがベースラインの±5%以内の性能を維持し、MIRコードサイズを20-50%削減することを示している。このシステムはGUIプログラム、Webサーバー、分散システムを含む複雑なアプリケーションのコンパイルに成功している。本研究は、IRミニマリズムが戦略的な最適化配置と組み合わされることで、極端なシンプルさと本番レベルの性能の両立が可能であることを実証した。
|
||||
|
||||
我々のアプローチは、ますます複雑化する中間表現(例:LLVMの60以上のオペコード)の傾向に挑戦し、慎重な設計により「より少ないものでより多くを達成できる」ことを示している。MIR-14はコンパイラ構築、最適化研究、言語実装教育に新たな可能性を開くと考えられる。
|
||||
|
||||
## Keywords / キーワード
|
||||
|
||||
Intermediate representation, Instruction set reduction, BoxCall unification, Compiler optimization, Inline caching, AOT compilation
|
||||
|
||||
中間表現、命令セット削減、BoxCall統一、コンパイラ最適化、インラインキャッシング、AOTコンパイル
|
||||
@ -0,0 +1,87 @@
|
||||
# Chapter 1: Introduction
|
||||
|
||||
## The 14-Instruction Balance
|
||||
|
||||
Can we build a practical programming language with just 14 intermediate representation (IR) instructions? This paper demonstrates how we evolved from 27 instructions to 13 through aggressive minimization, then pragmatically added one back (UnaryOp) to achieve the optimal balance between theoretical minimalism and practical efficiency.
|
||||
|
||||
## The Complexity Crisis
|
||||
|
||||
Modern intermediate representations have grown alarmingly complex:
|
||||
|
||||
- **LLVM IR**: 60+ opcodes (and growing)
|
||||
- **JVM bytecode**: ~200 instructions
|
||||
- **CLR IL**: ~100 instructions
|
||||
- **WebAssembly**: ~150 instructions
|
||||
- **Even "minimal" VMs**: 30-50 instructions
|
||||
|
||||
This complexity stems from decades of optimization-driven design, where each performance improvement adds new instructions. The result? Compiler implementations measured in millions of lines of code, optimization passes that few understand, and a barrier to entry that excludes most researchers and students.
|
||||
|
||||
## The MIR-14 Evolution
|
||||
|
||||
We present MIR-14, which evolved through three distinct phases:
|
||||
1. **Initial design**: 27 instructions (feature-driven)
|
||||
2. **Aggressive reduction**: 13 instructions via BoxCall unification
|
||||
3. **Practical restoration**: 14 instructions (Core-13 + UnaryOp)
|
||||
|
||||
```
|
||||
Traditional: MIR-14:
|
||||
ArrayGet →
|
||||
ArraySet → } BoxCall
|
||||
RefGet → } (unified)
|
||||
RefSet →
|
||||
UnaryOp (restored for efficiency)
|
||||
```
|
||||
|
||||
The key insight: array operations and field accesses are fundamentally the same—they're all Box method calls. By recognizing this pattern, we achieved dramatic instruction reduction. However, practical experience showed that certain primitive operations (negation, NOT) warrant direct representation, leading to our final 14-instruction set.
|
||||
|
||||
## Performance Without Complexity
|
||||
|
||||
Critics might assume that fewer instructions mean worse performance. We prove the opposite:
|
||||
|
||||
- **Inline Caching**: 33x speedup for method dispatch
|
||||
- **AOT Compilation**: Near-native performance
|
||||
- **Typed Array Specialization**: Competitive with C arrays
|
||||
- **Code Size Reduction**: 20-50% smaller MIR output
|
||||
|
||||
The secret? Strategic optimization placement at Box boundaries rather than IR complexity.
|
||||
|
||||
## Contributions
|
||||
|
||||
This paper makes five key contributions:
|
||||
|
||||
1. **Evolution Methodology**: A documented journey from Core-27 → Core-13 → Core-14, demonstrating both aggressive reduction and pragmatic restoration.
|
||||
|
||||
2. **BoxCall Unification Architecture**: A novel design pattern that elegantly absorbs data access operations into a single instruction.
|
||||
|
||||
3. **Optimization Strategy**: Demonstration that IR minimalism coupled with boundary optimization outperforms complex IR designs.
|
||||
|
||||
4. **Implementation Evidence**: Full compiler stack (Parser → MIR → VM/JIT/AOT/WASM) maintaining ±5% performance of baseline.
|
||||
|
||||
5. **Educational Impact**: A compiler design that students can understand in days, not months.
|
||||
|
||||
## Paper Organization
|
||||
|
||||
The remainder of this paper is organized as follows:
|
||||
|
||||
- **Chapter 2** presents the Box Theory, our theoretical foundation for achieving complexity through composition rather than instruction proliferation.
|
||||
|
||||
- **Chapter 3** details the MIR15 design, explaining our process of reducing 26 instructions to 15 while maintaining full functionality.
|
||||
|
||||
- **Chapter 4** describes our implementation, including the unified architecture that enables four different backends to share the same minimal IR.
|
||||
|
||||
- **Chapter 5** evaluates our approach through GUI demonstrations, performance benchmarks, and instruction coverage analysis.
|
||||
|
||||
- **Chapter 6** discusses the implications of our findings and why this approach succeeds where conventional wisdom suggests it should fail.
|
||||
|
||||
- **Chapter 7** compares our work with related systems, highlighting the unique aspects of our minimalist approach.
|
||||
|
||||
- **Chapter 8** concludes with reflections on the future of minimal language design.
|
||||
|
||||
## A Note on Simplicity
|
||||
|
||||
> "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
|
||||
> — Antoine de Saint-Exupéry
|
||||
|
||||
Nyash embodies this principle. By removing rather than adding, we have discovered that less truly can be more—not just philosophically, but practically. The GUI application running on your screen with 15 instructions is not a limitation overcome, but a validation of simplicity as a first-class design principle.
|
||||
|
||||
Welcome to the minimal instruction revolution.
|
||||
@ -0,0 +1,148 @@
|
||||
# Chapter 2: The Box Theory - A Mathematical Foundation
|
||||
|
||||
## 2.1 The Atomic Theory of Programming
|
||||
|
||||
Just as matter is composed of atoms that combine to form molecules and complex structures, we propose that programs can be viewed as compositions of atomic operations that combine through a universal abstraction—the Box.
|
||||
|
||||
### Definition 2.1 (Box)
|
||||
A Box B is a tuple (S, O, σ) where:
|
||||
- S is the internal state space
|
||||
- O is the set of operations {o₁, o₂, ..., oₙ}
|
||||
- σ: S × O × Args → S × Result is the state transition function
|
||||
|
||||
### Definition 2.2 (Atomic Operations)
|
||||
The minimal set of atomic operations A = {a₁, a₂, ..., a₁₅} forms the complete basis for computation:
|
||||
|
||||
```
|
||||
A = {Const, UnaryOp, BinOp, Compare, TypeOp,
|
||||
Load, Store, Branch, Jump, Return, Phi,
|
||||
NewBox, BoxCall, ArrayGet, ArraySet, ExternCall}
|
||||
```
|
||||
|
||||
## 2.2 Composition and Recursion
|
||||
|
||||
The power of the Box Theory lies not in the individual operations but in their composition:
|
||||
|
||||
### Theorem 2.1 (Compositional Completeness)
|
||||
For any computable function f, there exists a finite composition of Boxes B₁, B₂, ..., Bₙ such that f can be expressed using only operations from A.
|
||||
|
||||
*Proof sketch*: By showing that A contains operations for:
|
||||
1. Value creation (Const, NewBox)
|
||||
2. State manipulation (Load, Store, ArrayGet, ArraySet)
|
||||
3. Control flow (Branch, Jump, Return, Phi)
|
||||
4. Composition (BoxCall)
|
||||
5. External interaction (ExternCall)
|
||||
|
||||
We can construct any Turing-complete computation.
|
||||
|
||||
### Lemma 2.1 (Recursive Box Construction)
|
||||
Boxes can contain other Boxes, enabling recursive composition:
|
||||
|
||||
```
|
||||
GuiBox = Box({
|
||||
WindowBox,
|
||||
ButtonBox,
|
||||
CanvasBox
|
||||
})
|
||||
```
|
||||
|
||||
This recursive nature allows unbounded complexity from bounded primitives.
|
||||
|
||||
## 2.3 The Box Calculus
|
||||
|
||||
We formalize Box operations using a simple calculus:
|
||||
|
||||
### Syntax
|
||||
```
|
||||
e ::= x (variable)
|
||||
| c (constant)
|
||||
| new B(e₁,...,eₙ) (box creation)
|
||||
| e.m(e₁,...,eₙ) (box method call)
|
||||
| e₁ ⊕ e₂ (binary operation)
|
||||
| if e₁ then e₂ else e₃ (conditional)
|
||||
```
|
||||
|
||||
### Operational Semantics
|
||||
|
||||
**Box Creation**:
|
||||
```
|
||||
σ ⊢ eᵢ ⇓ vᵢ (for i = 1..n)
|
||||
________________________________
|
||||
σ ⊢ new B(e₁,...,eₙ) ⇓ ref(B, v₁,...,vₙ)
|
||||
```
|
||||
|
||||
**Method Call**:
|
||||
```
|
||||
σ ⊢ e ⇓ ref(B, state) σ ⊢ eᵢ ⇓ vᵢ
|
||||
B.m(state, v₁,...,vₙ) → (state', result)
|
||||
_________________________________________
|
||||
σ ⊢ e.m(e₁,...,eₙ) ⇓ result
|
||||
```
|
||||
|
||||
## 2.4 From Theory to Practice
|
||||
|
||||
The Box Theory manifests in Nyash through concrete examples:
|
||||
|
||||
### Example 2.1 (GUI as Boxes)
|
||||
```nyash
|
||||
box Button from Widget {
|
||||
init { text, onClick }
|
||||
|
||||
render() {
|
||||
# Rendering is just Box operations
|
||||
return me.drawRect(me.bounds)
|
||||
.drawText(me.text)
|
||||
}
|
||||
|
||||
handleClick(x, y) {
|
||||
if me.contains(x, y) {
|
||||
me.onClick()
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Every GUI element is a Box, every interaction is a BoxCall. The 15 atomic operations suffice because complexity resides in Box composition, not in the instruction set.
|
||||
|
||||
### Example 2.2 (Concurrency as Boxes)
|
||||
```nyash
|
||||
box TaskGroup {
|
||||
spawn(target, method, args) {
|
||||
# Concurrency through Box abstraction
|
||||
local future = new FutureBox()
|
||||
ExternCall("scheduler", "enqueue", [target, method, args, future])
|
||||
return future
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 2.5 Why 15 Instructions Suffice
|
||||
|
||||
The key insight is the separation of concerns:
|
||||
|
||||
1. **Structure** (MIR): Handles control flow and basic operations
|
||||
2. **Behavior** (Boxes): Encapsulates domain-specific complexity
|
||||
3. **Composition** (BoxCall): Enables unlimited combinations
|
||||
|
||||
This separation allows us to keep the structural layer (MIR) minimal while achieving arbitrary functionality through behavioral composition.
|
||||
|
||||
### Theorem 2.2 (Minimality)
|
||||
The 15-instruction set A is minimal in the sense that removing any instruction would break either:
|
||||
1. Turing completeness
|
||||
2. Practical usability
|
||||
3. Box abstraction capability
|
||||
|
||||
## 2.6 Implications
|
||||
|
||||
The Box Theory has profound implications:
|
||||
|
||||
1. **Language Design**: Complexity should be in libraries, not in the core language
|
||||
2. **Implementation**: Simpler IRs can lead to more robust implementations
|
||||
3. **Optimization**: Focus on Box boundaries rather than instruction-level optimization
|
||||
4. **Education**: Minimal languages are easier to learn and understand
|
||||
|
||||
## 2.7 Conclusion
|
||||
|
||||
The Box Theory provides a mathematical foundation for building complex systems from minimal primitives. By viewing computation as the composition of atomic operations through Box abstractions, we can achieve the seemingly impossible: full-stack applications, including GUI programs, with just 15 instructions.
|
||||
|
||||
This is not merely a theoretical exercise—as we will show in the following chapters, this theory has been successfully implemented and validated in the Nyash programming language.
|
||||
@ -0,0 +1,60 @@
|
||||
# MIR13 (Core-13) Final Instruction Set
|
||||
|
||||
## The 13 Instructions
|
||||
|
||||
### 1. 値・計算 (3命令)
|
||||
- **Const**: 定数値のロード
|
||||
- **BinOp**: 二項演算(算術、論理、ビット演算すべて)
|
||||
- **Compare**: 比較演算(==, !=, <, >, <=, >=)
|
||||
|
||||
### 2. 制御フロー (4命令)
|
||||
- **Jump**: 無条件ジャンプ
|
||||
- **Branch**: 条件分岐
|
||||
- **Return**: 関数からの戻り
|
||||
- **Phi**: SSA形式での値の合流
|
||||
|
||||
### 3. 呼び出し (3命令)
|
||||
- **Call**: 通常の関数呼び出し
|
||||
- **BoxCall**: Boxメソッド呼び出し(配列、オブジェクト、すべてのデータ操作)
|
||||
- **ExternCall**: 外部関数呼び出し(システムコール、プラグイン等)
|
||||
|
||||
### 4. メタ操作 (3命令)
|
||||
- **TypeOp**: 型関連操作(型チェック、キャスト)
|
||||
- **Safepoint**: GCセーフポイント
|
||||
- **Barrier**: メモリバリア
|
||||
|
||||
## 削除された命令とその統合先
|
||||
|
||||
| 削除された命令 | 統合方法 |
|
||||
|--------------|---------|
|
||||
| Load/Store | BoxCallまたはCall(変数もBoxとして扱う) |
|
||||
| UnaryOp | BinOp(例:-x → 0-x, !x → x XOR true) |
|
||||
| ArrayGet/ArraySet | BoxCall |
|
||||
| NewBox | BoxCall(コンストラクタ呼び出し) |
|
||||
| FunctionNew | Const(関数も値) |
|
||||
| RefNew/RefGet/RefSet | BoxCall |
|
||||
| TypeCheck/Cast | TypeOp |
|
||||
| Debug/Print | ExternCall |
|
||||
| Copy/Nop | 不要(最適化で除去) |
|
||||
|
||||
## 設計の革新性
|
||||
|
||||
### 1. 変数アクセスの統一
|
||||
すべての変数アクセスが関数呼び出しとして表現される:
|
||||
```mir
|
||||
// 従来: %1 = Load %x
|
||||
%1 = Call @get_local "x"
|
||||
|
||||
// 従来: Store %y, %1
|
||||
Call @set_local "y" %1
|
||||
```
|
||||
|
||||
### 2. Everything is Box の究極形
|
||||
- 変数もBox
|
||||
- 関数もBox(Constで表現)
|
||||
- すべての操作がBoxCall
|
||||
|
||||
### 3. 実用性とのバランス
|
||||
- Safepointでガベージコレクションをサポート
|
||||
- Barrierで並行性を考慮
|
||||
- ExternCallで拡張性を確保
|
||||
@ -0,0 +1,55 @@
|
||||
# 14命令のミニマルIRによる統一実行基盤設計(MIR14, PHIオフ方針)
|
||||
著者: Nyash Project
|
||||
|
||||
要旨
|
||||
Nyashは「Everything is Box」哲学を核に、14命令(MIR14)の最小IRでInterpreter/VM/JIT/AOT/GUIを目指してきた。本稿ではPhase‑15における設計判断として、MIR側のPHI生成を停止(PHI‑off, エッジコピー合流)し、PHI形成をLLVMハーネス側に委譲する方針を採用した経緯と効果を報告する。現在の評価範囲はPyVM(意味論リファレンス)とLLVM/llvmlite(AOT/EXEハーネス)に限定し、両者のパリティおよびLLVM側の性能・安定性を中心に示す。
|
||||
|
||||
> 更新メモ(2025-09-26): Phase‑15 では PHI-on(MIR14)が既定に復帰したよ。この資料はPHI-off方針をアーカイブとして残しているよ。現行のポリシーは `docs/reference/mir/phi_policy.md` を参照してね。
|
||||
|
||||
## 1. はじめに
|
||||
最小IRで多様な実行形態を統一する挑戦では、IRの表現力と実装コストの均衡が鍵となる。Nyashは命令の削減(27→13→14)とAPI統一(BoxCall)でIRを簡素に保ちつつ、評価基準をPyVM意味論とLLVM生成物に絞ることで、開発・検証速度を高めた。
|
||||
|
||||
## 2. MIR14の設計原則
|
||||
- 命令セット: const/binop/unary/compare/branch/jump/ret/phi/call/boxcall/typeop/arrayget/arrayset/cast/…(詳細は `docs/reference/mir/INSTRUCTION_SET.md`)
|
||||
- Box中心: 呼び出しとABI境界はBoxCall/PluginInvokeに一本化
|
||||
- 可観測性: JSON v0、IRダンプ、PHI配線トレースを整備
|
||||
- 非対象(現段階): MIR側の最適PHI配置の探索・検証(責務をLLVMへ移譲)
|
||||
|
||||
## 3. PHIオフ方針とLLVM側合成
|
||||
- 方針: MIRはPHIを出さず、分岐合流は「合流先で参照される値」を各前任ブロックからエッジコピーで集約
|
||||
- LLVM: ブロック先頭にPHIを形成(typed incoming)、if‑merge前宣言等で安定性向上
|
||||
- 不変条件(LLVM側): PHIはブロック先頭にのみ配置、incomingは型付き `i64 <v>, %bb`(詳細: `docs/reference/mir/phi_invariants.md`)
|
||||
- トグル:
|
||||
- 既定: `NYASH_MIR_NO_PHI=0`(PHI-on)
|
||||
- レガシー再現: `NYASH_MIR_NO_PHI=1`(PHI-off) + `NYASH_VERIFY_ALLOW_NO_PHI=1`
|
||||
|
||||
## 4. 実装概要(評価対象)
|
||||
- PyVM: JSON v0→MIR実行の意味論基準。短絡やtruthy規約の基準線
|
||||
- LLVM/llvmlite: AOT/EXE生成・IRダンプ・PHI合成の実働ライン
|
||||
- 実行例:
|
||||
- LLVMハーネス: `NYASH_LLVM_USE_HARNESS=1 NYASH_LLVM_DUMP_IR=tmp/nyash.ll ...`
|
||||
- PHIトレース: `NYASH_LLVM_TRACE_PHI=1`
|
||||
|
||||
## 5. 評価計画
|
||||
- パリティ: PyVM vs LLVMの出力一致(代表スモーク)
|
||||
- 性能: LLVMの実行時間/起動時間/メモリ
|
||||
- 安定性: PHIトレース整合、空PHI未発生の確認
|
||||
- 再現コマンド:
|
||||
- parity: `tools/parity.sh --lhs pyvm --rhs llvmlite apps/tests/CASE.nyash`
|
||||
- build paper (PDF/TeX): `tools/papers/build.sh a-jp`
|
||||
|
||||
## 6. 関連研究
|
||||
最小IR設計(LLVM/MLIR等)と、多層実行(Truffle/Graal)に対する立ち位置を簡潔に比較。Nyashは「IRは最小・PHIは生成系に委譲」という分担で整合を取る点に新規性。
|
||||
|
||||
## 7. 結論
|
||||
MIR14の簡素化とPHI委譲により、設計・検証・配布ラインを細く強く維持できた。今後はLoopForm(MIR17)や実行器の拡張を、PyVM/LLVMの二系統基準で段階的に進める。
|
||||
|
||||
### 謝辞
|
||||
AI協働(ChatGPT/Gemini)とコミュニティ貢献に感謝する。
|
||||
|
||||
### 付録
|
||||
- 主要トグル: `NYASH_MIR_NO_PHI`, `NYASH_LLVM_USE_HARNESS`, `NYASH_LLVM_TRACE_PHI`
|
||||
- 仕様参照: `docs/reference/mir/INSTRUCTION_SET.md`, `docs/reference/mir/phi_invariants.md`
|
||||
|
||||
### キーワード
|
||||
ミニマルIR, SSA, PHI合成, LLVM, PyVM, BoxCall, 統一実行
|
||||
@ -0,0 +1,38 @@
|
||||
# Minimal Yet Practical: The MIR-14 Instruction Set and Everything-is-Box Philosophy
|
||||
|
||||
## Authors
|
||||
TBD
|
||||
|
||||
## Abstract
|
||||
[See abstract.md]
|
||||
|
||||
## 1. Introduction
|
||||
[See chapters/01-introduction.md]
|
||||
|
||||
## 2. The Evolution of MIR: From 27 to 14
|
||||
[TODO: Detail the systematic reduction and practical restoration process]
|
||||
|
||||
## 3. BoxCall Unification Architecture
|
||||
[TODO: Explain how BoxCall absorbs array/field operations]
|
||||
|
||||
## 4. Optimization Strategies
|
||||
[TODO: IC, AOT, TypedArray optimizations]
|
||||
|
||||
## 5. Implementation
|
||||
[TODO: Compiler architecture and implementation details]
|
||||
|
||||
## 6. Evaluation
|
||||
[TODO: Performance benchmarks and analysis]
|
||||
|
||||
## 7. Related Work
|
||||
[TODO: Comparison with other minimal IRs]
|
||||
|
||||
## 8. Conclusion
|
||||
[TODO: Summary and future directions]
|
||||
|
||||
## References
|
||||
[TODO: Add bibliography]
|
||||
|
||||
---
|
||||
|
||||
*Note: This is the main paper structure. Detailed content is in individual chapter files.*
|
||||
@ -0,0 +1,195 @@
|
||||
# Nyash言語論文 Phase 15更新計画
|
||||
|
||||
最終更新: 2025-09-27
|
||||
|
||||
## 🎯 更新の目的
|
||||
|
||||
Phase 15の最新仕様(Everything is Box完全版、birth統一、try撤廃等)を反映し、論文を完成させる。
|
||||
|
||||
---
|
||||
|
||||
## 📋 更新項目リスト
|
||||
|
||||
### 優先度1(必須更新)
|
||||
|
||||
#### 1. **Everything is Box完全版**
|
||||
- ❌ 古い: データだけBox
|
||||
- ✅ 新: すべてがBox
|
||||
|
||||
**完全なBox化**:
|
||||
- データBox: StringBox, IntegerBox, ArrayBox... ✅
|
||||
- 演算子Box: AddOperator, CompareOperator... ✅(世界初!)
|
||||
- 制御Box: LoopForm ✅(世界初!)
|
||||
|
||||
**更新箇所**:
|
||||
- README.md: Everything is Boxの説明
|
||||
- chapters/02-language-design.md: Box哲学完全版
|
||||
- main-paper-jp.md: 中心的主張
|
||||
|
||||
#### 2. **birth統一**
|
||||
- ❌ 古い: init/birth/pack混在
|
||||
- ✅ 新: birthに完全統一
|
||||
|
||||
**統一内容**:
|
||||
- ビルトインBox: birth
|
||||
- ユーザー定義Box: birth
|
||||
- プラグインBox: birth
|
||||
- デリゲーション: `from ParentBox.birth()`
|
||||
|
||||
**更新箇所**:
|
||||
- chapters/03-memory-model.md: コンストラクタ統一
|
||||
- コード例すべて
|
||||
|
||||
#### 3. **try文撤廃革命**
|
||||
- ❌ 古い: 従来のtry-catch-finally
|
||||
- ✅ 新: postfix catch/cleanup
|
||||
|
||||
**新構文**:
|
||||
```nyash
|
||||
method() catch(Error e) { }
|
||||
method() cleanup { }
|
||||
method()
|
||||
catch(e) { }
|
||||
cleanup { }
|
||||
```
|
||||
|
||||
**追加箇所**:
|
||||
- 新章: Exception Handling Revolution
|
||||
- try撤廃の哲学的意義
|
||||
- ネスト削減の実例
|
||||
|
||||
#### 4. **Property System革命**
|
||||
- 新機能: stored/computed/once/birth_once
|
||||
|
||||
**4種類のProperty**:
|
||||
- `stored`: 通常フィールド
|
||||
- `computed`: 計算プロパティ
|
||||
- `once`: 遅延評価キャッシュ
|
||||
- `birth_once`: 即時評価
|
||||
|
||||
**追加内容**:
|
||||
- Python @property/@cached_property完全マッピング
|
||||
- 10-50x高速化の実証
|
||||
- コード例
|
||||
|
||||
### 優先度2(強く推奨)
|
||||
|
||||
#### 5. **using system**
|
||||
- 新機能: ドット記法、namespace解決
|
||||
|
||||
**特徴**:
|
||||
- `plugin.StringBox` ドット記法
|
||||
- 修飾名・namespace解決
|
||||
- AST using統一(SSOT)
|
||||
- 重複検出自動化
|
||||
|
||||
**追加箇所**:
|
||||
- chapters/02-language-design.md: モジュールシステム
|
||||
|
||||
#### 6. **2本柱実行体制**
|
||||
- ❌ 古い: 5つの実行形態
|
||||
- ✅ 新: 2本柱 + 特殊用途
|
||||
|
||||
**実行モデル**:
|
||||
- Rust VM: 開発・デバッグ・検証
|
||||
- LLVM: 本番・最適化・配布
|
||||
- PyVM: JSON v0ブリッジ専用
|
||||
|
||||
**更新箇所**:
|
||||
- chapters/05-execution-backends.md: 実行モデル刷新
|
||||
|
||||
#### 7. **演算子Box: デバッグ革命**
|
||||
- observe/adopt段階的移行
|
||||
- Void混入即座特定
|
||||
- ChatGPT「最強クラス」評価
|
||||
|
||||
**追加内容**:
|
||||
- 演算子Boxの威力実証
|
||||
- デバッグ事例
|
||||
- AI協働開発での活用
|
||||
|
||||
### 優先度3(あれば尚良)
|
||||
|
||||
#### 8. **P2P Intentモデル**
|
||||
- 既存内容の更新
|
||||
- Box間通信の実例
|
||||
|
||||
#### 9. **match式**
|
||||
- パターンマッチング
|
||||
- ブロック式・値式の統一
|
||||
|
||||
---
|
||||
|
||||
## 📊 章構成(更新後)
|
||||
|
||||
### Introduction
|
||||
- Nyash言語の概要
|
||||
- Everything is Box完全版の主張
|
||||
- 世界初の完全Box言語
|
||||
|
||||
### Chapter 2: Language Design
|
||||
- Everything is Box哲学
|
||||
- データBox
|
||||
- 演算子Box
|
||||
- 制御Box(LoopForm)
|
||||
- birth統一
|
||||
- using system
|
||||
|
||||
### Chapter 3: Memory Model
|
||||
- birth/fini対称性
|
||||
- GCオン/オフ切替
|
||||
- WeakBox設計
|
||||
|
||||
### Chapter 4: Exception Handling Revolution
|
||||
- try文撤廃の哲学
|
||||
- postfix catch/cleanup
|
||||
- 段階的決定モデル
|
||||
- ネスト削減の実例
|
||||
|
||||
### Chapter 5: Property System
|
||||
- 4種類のProperty
|
||||
- Python統合戦略
|
||||
- 10-50x高速化実証
|
||||
|
||||
### Chapter 6: Execution Backends
|
||||
- 2本柱体制
|
||||
- VM/LLVMパリティ
|
||||
- Phase 15戦略
|
||||
|
||||
### Chapter 7: Case Studies
|
||||
- JSON Native
|
||||
- 実アプリケーション
|
||||
- プラグインエコシステム
|
||||
|
||||
### Conclusion
|
||||
- Everything is Boxの完全実現
|
||||
- 世界初の成果
|
||||
- Future Work
|
||||
|
||||
---
|
||||
|
||||
## ✅ 完成チェックリスト
|
||||
|
||||
- [ ] README.md更新
|
||||
- [ ] Chapter 2: Language Design(Everything is Box完全版)
|
||||
- [ ] Chapter 3: Memory Model(birth統一)
|
||||
- [ ] Chapter 4: Exception Handling Revolution(新規作成)
|
||||
- [ ] Chapter 5: Property System(新規作成)
|
||||
- [ ] Chapter 6: Execution Backends(2本柱更新)
|
||||
- [ ] Chapter 7: Case Studies(最新実例)
|
||||
- [ ] main-paper-jp.md統合
|
||||
- [ ] Abstract更新
|
||||
- [ ] AI査読(ChatGPT/Claude)
|
||||
|
||||
---
|
||||
|
||||
## 🗓️ スケジュール
|
||||
|
||||
- **Day 1-2**: 構造更新、Everything is Box完全版
|
||||
- **Day 3-4**: Chapter 2-3(Language Design, Memory Model)
|
||||
- **Day 5-6**: Chapter 4-5(Exception, Property)
|
||||
- **Day 7-8**: Chapter 6-7(Execution, Case Studies)
|
||||
- **Day 9**: 統合、AI査読
|
||||
- **Day 10**: 修正、完成
|
||||
|
||||
**目標**: 10日以内に完成 ✨
|
||||
@ -0,0 +1,142 @@
|
||||
# 論文B: Nyash言語と実行モデル
|
||||
|
||||
> Scope (2025-09-19): 本稿の範囲は PyVM と LLVM/llvmlite の2系統に限定。MIR14 は PHI‑off(合流はエッジコピー)、PHI 形成は LLVM ハーネスで行う。JIT/Interpreter は Phase‑15 では補助扱い。詳細は SCOPE.md を参照。
|
||||
|
||||
## 📚 概要
|
||||
|
||||
**タイトル**: Nyash: A Box-First Programming Language with Symmetric Memory Management and P2P Intent Model
|
||||
|
||||
**主題**: Nyash言語そのものの設計と実装
|
||||
|
||||
**対象読者**: 言語理論・分散システム・アプリ開発寄り
|
||||
|
||||
## 🎯 研究ポイント
|
||||
|
||||
### 1. init/fini対称性によるメモリ管理
|
||||
- コンストラクタ(init/birth/pack)とデストラクタ(fini)の対称設計
|
||||
- 明示的なリソース管理による安全性
|
||||
- GCオン/オフ切り替え可能な柔軟性
|
||||
|
||||
### 2. P2P Intentモデル
|
||||
- Box間の意図ベース通信
|
||||
- 分散アプリケーション向け設計
|
||||
- NyaMeshライブラリによる実装
|
||||
|
||||
### 3. 多層実行アーキテクチャ
|
||||
- **Interpreter**: 開発・デバッグ用
|
||||
- **VM**: 高速実行
|
||||
- **JIT**: 動的最適化
|
||||
- **AOT**: 配布用バイナリ
|
||||
- **WASM**: Web展開
|
||||
|
||||
## 🚀 実装例
|
||||
|
||||
### 1. NyashCoin - P2P暗号通貨
|
||||
```nyash
|
||||
box NyashCoin from P2PBox {
|
||||
init { balance, transactions }
|
||||
|
||||
birth(nodeId, network) {
|
||||
from P2PBox.pack(nodeId, network)
|
||||
me.balance = new MapBox()
|
||||
me.transactions = new ArrayBox()
|
||||
}
|
||||
|
||||
onIntent(intent, data, sender) {
|
||||
switch intent {
|
||||
"transfer": me.handleTransfer(data, sender)
|
||||
"mine": me.handleMining(data, sender)
|
||||
"sync": me.handleSync(data, sender)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. プラグインストア
|
||||
- 動的プラグインロード
|
||||
- TypeBox ABIによる相互運用
|
||||
- セキュアな実行環境
|
||||
|
||||
### 3. GUI/Webアプリケーション
|
||||
- EguiBoxによるGUI開発
|
||||
- WebCanvasBoxによるブラウザ対応
|
||||
- 統一的なBox APIによる開発
|
||||
|
||||
## 📊 評価計画
|
||||
|
||||
### 言語機能の評価
|
||||
- 表現力: 他言語との比較
|
||||
- 学習曲線: 初学者への調査
|
||||
- 開発効率: LOCとバグ率
|
||||
|
||||
### 性能評価
|
||||
- 各バックエンドのベンチマーク
|
||||
- メモリ使用量の比較
|
||||
- 起動時間・応答性
|
||||
|
||||
### 実用性評価
|
||||
- 実アプリケーション開発
|
||||
- プラグインエコシステム
|
||||
- クロスプラットフォーム性
|
||||
|
||||
## 📁 ディレクトリ構造
|
||||
|
||||
```
|
||||
paper-b-nyash-execution-model/
|
||||
├── README.md # このファイル
|
||||
├── abstract.md # 論文概要
|
||||
├── main-paper.md # 本文
|
||||
├── chapters/ # 章別ファイル
|
||||
│ ├── 01-introduction.md
|
||||
│ ├── 02-language-design.md
|
||||
│ ├── 03-memory-model.md
|
||||
│ ├── 04-p2p-intent.md
|
||||
│ ├── 05-execution-backends.md
|
||||
│ ├── 06-case-studies.md
|
||||
│ └── 07-conclusion.md
|
||||
├── figures/ # 図表
|
||||
│ ├── box-hierarchy.png
|
||||
│ ├── execution-flow.svg
|
||||
│ └── p2p-architecture.png
|
||||
├── examples/ # コード例
|
||||
│ ├── nyashcoin/
|
||||
│ ├── plugin-store/
|
||||
│ └── gui-apps/
|
||||
├── data/ # 実験データ
|
||||
│ ├── performance/
|
||||
│ └── usability-study/
|
||||
└── related-work.md # 関連研究
|
||||
```
|
||||
|
||||
## 🗓️ スケジュール
|
||||
|
||||
- **2025年9月**: 実装例の完成・評価実施
|
||||
- **2025年10月**: 執筆開始
|
||||
- **2025年11月**: OOPSLA 2026投稿
|
||||
- **2026年春**: Onward!投稿(設計哲学編)
|
||||
|
||||
## 📝 執筆メモ
|
||||
|
||||
### 強調すべき貢献
|
||||
1. **Everything is Box哲学**: 統一的なオブジェクトモデル
|
||||
2. **対称的メモリ管理**: init/finiによる明示的制御
|
||||
3. **P2P Intentモデル**: 分散アプリケーションの新パラダイム
|
||||
4. **多層実行環境**: 用途に応じた最適な実行方式
|
||||
|
||||
### 新規性
|
||||
- Box中心の言語設計
|
||||
- 意図ベースのメッセージング
|
||||
- プラグイン第一級市民
|
||||
- 実行バックエンドの透過的切り替え
|
||||
|
||||
### 実証
|
||||
- 実動作するアプリケーション群
|
||||
- プラグインエコシステムの構築
|
||||
- クロスプラットフォーム展開
|
||||
|
||||
## 🔗 関連ドキュメント
|
||||
|
||||
- [Language Reference](../../../../reference/language/LANGUAGE_REFERENCE_2025.md)
|
||||
- [Everything is Box](../../../../reference/boxes-system/everything-is-box.md)
|
||||
- [P2P Box Guide](../../../../guides/p2p-guide.md)
|
||||
- [Execution Backends](../../../../reference/architecture/execution-backends.md)
|
||||
@ -0,0 +1,17 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
OUT_DIR=$(cd "$(dirname "$0")" && pwd)
|
||||
OUT_FILE="$OUT_DIR/ENVIRONMENT.txt"
|
||||
|
||||
{
|
||||
echo "== Datetime =="; date -Iseconds || date; echo
|
||||
echo "== OS =="; uname -a || true; lsb_release -a 2>/dev/null || true; sw_vers 2>/dev/null || true; systeminfo 2>/dev/null | head -n 30 || true; echo
|
||||
echo "== CPU =="; lscpu 2>/dev/null || sysctl -a 2>/dev/null | grep machdep.cpu || true; echo
|
||||
echo "== Rust toolchain =="; rustc --version 2>/dev/null || true; cargo --version 2>/dev/null || true; echo
|
||||
echo "== Git =="; git rev-parse HEAD 2>/dev/null || true; echo
|
||||
echo "== Cranelift/JIT features =="; rg -n "cranelift|jit" -S ../../../../ -g '!target' 2>/dev/null || true
|
||||
} > "$OUT_FILE"
|
||||
|
||||
echo "[DONE] Wrote $OUT_FILE"
|
||||
|
||||
@ -0,0 +1,25 @@
|
||||
This folder contains reproducibility artifacts for Paper B (Nyash language & execution model).
|
||||
|
||||
Files
|
||||
- `COLLECT_ENV.sh`: Captures host OS/CPU/toolchain/git info into `ENVIRONMENT.txt`.
|
||||
- `RUN_BENCHMARKS.sh`: Runs interpreter/VM/JIT/AOT (if available) on sample benchmarks and writes CSVs to `results/`.
|
||||
- `results/`: Output CSVs (per benchmark and per mode).
|
||||
|
||||
Usage
|
||||
1) Capture environment
|
||||
./COLLECT_ENV.sh
|
||||
|
||||
2) Build (full)
|
||||
cargo build --release --features cranelift-jit
|
||||
|
||||
3) Run benchmarks
|
||||
./RUN_BENCHMARKS.sh
|
||||
|
||||
Variables:
|
||||
- NYASH_BIN: Path to nyash binary (default: target/release/nyash)
|
||||
- USE_EXE_ONLY=1: Only measure AOT executables (skips interp/vm/jit)
|
||||
|
||||
Notes
|
||||
- AOT requires `tools/build_aot.sh`. If missing, AOT is skipped.
|
||||
- If `hyperfine` is not installed, a simple timing fallback is used.
|
||||
|
||||
@ -0,0 +1,98 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
# Repro benchmarks for Paper B (Nyash language & execution model)
|
||||
# Uses the shared benchmarks folder; writes CSVs under _artifacts/results
|
||||
|
||||
if ROOT_DIR=$(git -C "$(dirname "$0")" rev-parse --show-toplevel 2>/dev/null); then
|
||||
ROOT_DIR="$ROOT_DIR/nyash"
|
||||
[[ -d "$ROOT_DIR" ]] || ROOT_DIR=$(git rev-parse --show-toplevel)
|
||||
else
|
||||
ROOT_DIR=$(cd "$(dirname "$0")/../../../../.." && pwd)
|
||||
fi
|
||||
ART_DIR=$(cd "$(dirname "$0")" && pwd)
|
||||
RES_DIR="$ART_DIR/results"
|
||||
mkdir -p "$RES_DIR"
|
||||
|
||||
NYASH_BIN=${NYASH_BIN:-"$ROOT_DIR/target/release/nyash"}
|
||||
SKIP_INTERP=${SKIP_INTERP:-0}
|
||||
SKIP_AOT=${SKIP_AOT:-0}
|
||||
RUNS=${RUNS:-10}
|
||||
USE_EXE_ONLY=${USE_EXE_ONLY:-0}
|
||||
HYPERFINE=$(command -v hyperfine || true)
|
||||
TIMEOUT_SECS=${TIMEOUT_SECS:-0}
|
||||
TIMEOUT_BIN=$(command -v timeout || true)
|
||||
|
||||
BENCH_DIR="$ROOT_DIR/benchmarks"
|
||||
FILES=(
|
||||
"$BENCH_DIR/bench_light.nyash"
|
||||
"$BENCH_DIR/bench_medium.nyash"
|
||||
"$BENCH_DIR/bench_heavy.nyash"
|
||||
)
|
||||
|
||||
echo "[INFO] NYASH_BIN=$NYASH_BIN"
|
||||
echo "[INFO] USE_EXE_ONLY=$USE_EXE_ONLY (1=EXE only)"
|
||||
echo "[INFO] hyperfine=${HYPERFINE:-not found}"
|
||||
|
||||
if [[ ! -x "$NYASH_BIN" && "$USE_EXE_ONLY" -eq 0 ]]; then
|
||||
echo "[INFO] Building nyash (release, with JIT feature)"
|
||||
(cd "$ROOT_DIR" && cargo build --release --features cranelift-jit)
|
||||
fi
|
||||
|
||||
have_build_aot=0
|
||||
if [[ -x "$ROOT_DIR/tools/build_aot.sh" ]]; then
|
||||
have_build_aot=1
|
||||
fi
|
||||
|
||||
run_cmd() {
|
||||
local cmd="$1" label="$2" csv="$3"
|
||||
local cmd_wrap="$cmd"
|
||||
if [[ -n "$TIMEOUT_BIN" && "$TIMEOUT_SECS" -gt 0 ]]; then
|
||||
cmd_wrap="$TIMEOUT_BIN ${TIMEOUT_SECS}s $cmd"
|
||||
fi
|
||||
if [[ -n "$HYPERFINE" ]]; then
|
||||
$HYPERFINE -w 1 -r "$RUNS" --export-csv "$csv" --show-output "$cmd_wrap"
|
||||
else
|
||||
: > "$csv"
|
||||
for i in $(seq 1 "$RUNS"); do
|
||||
local t0=$(python3 - <<<'import time; print(int(time.time()*1000))')
|
||||
bash -lc "$cmd_wrap" >/dev/null 2>&1 || true
|
||||
local t1=$(python3 - <<<'import time; print(int(time.time()*1000))')
|
||||
echo "$label,$((t1-t0))" >> "$csv"
|
||||
done
|
||||
fi
|
||||
}
|
||||
|
||||
for f in "${FILES[@]}"; do
|
||||
[[ -f "$f" ]] || { echo "[WARN] Skip missing $f"; continue; }
|
||||
base=$(basename "$f" .nyash)
|
||||
|
||||
if [[ "$USE_EXE_ONLY" -eq 0 ]]; then
|
||||
if [[ "$SKIP_INTERP" -eq 0 ]]; then
|
||||
run_cmd "$NYASH_BIN $f" "interp-$base" "$RES_DIR/${base}_interp.csv"
|
||||
else
|
||||
echo "[INFO] SKIP_INTERP=1: skipping interpreter for $f"
|
||||
fi
|
||||
run_cmd "$NYASH_BIN --backend vm $f" "vm-$base" "$RES_DIR/${base}_vm.csv"
|
||||
run_cmd "NYASH_JIT_EXEC=1 $NYASH_BIN --backend vm $f" "jit-$base" "$RES_DIR/${base}_jit.csv"
|
||||
fi
|
||||
|
||||
if [[ $have_build_aot -eq 1 && "$SKIP_AOT" -eq 0 ]]; then
|
||||
out="/tmp/ny_${base}_aot"
|
||||
bash "$ROOT_DIR/tools/build_aot.sh" "$f" -o "$out" >/dev/null 2>&1 || true
|
||||
if [[ -x "$out" ]]; then
|
||||
run_cmd "$out" "aot-$base" "$RES_DIR/${base}_aot.csv"
|
||||
rm -f "$out"
|
||||
else
|
||||
echo "[WARN] AOT build failed for $f"
|
||||
fi
|
||||
else
|
||||
if [[ "$SKIP_AOT" -eq 1 ]]; then
|
||||
echo "[INFO] SKIP_AOT=1: skipping AOT for $f"
|
||||
else
|
||||
echo "[INFO] AOT tool not found; skipping AOT for $f"
|
||||
fi
|
||||
fi
|
||||
done
|
||||
|
||||
echo "[DONE] Results in $RES_DIR"
|
||||
@ -0,0 +1,38 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
|
||||
BIN="$ROOT/nyash/target/release/nyash"
|
||||
|
||||
need() { command -v "$1" >/dev/null 2>&1 || { echo "error: missing: $1" >&2; exit 1; }; }
|
||||
need "$BIN" || (cd "$ROOT/nyash" && cargo build --release >/dev/null)
|
||||
|
||||
declare -A LOOPS
|
||||
LOOPS[bench_box_create_destroy.nyash]=1000000
|
||||
LOOPS[bench_method_call_only.nyash]=2000000
|
||||
|
||||
bench() {
|
||||
local file="$1" loops="$2"
|
||||
local path="$ROOT/nyash/benchmarks/$file"
|
||||
[[ -f "$path" ]] || { echo "[skip] missing $path"; return; }
|
||||
local t0=$(python3 - <<<'import time; print(time.time())')
|
||||
"$BIN" "$path" >/dev/null 2>&1 || true
|
||||
local t1=$(python3 - <<<'import time; print(time.time())')
|
||||
local ms=$(python3 - <<EOF
|
||||
import sys
|
||||
print(int( (float($t1) - float($t0)) * 1000 ))
|
||||
EOF
|
||||
)
|
||||
# ns per op (approx)
|
||||
local ns=$(python3 - <<EOF
|
||||
loops=$loops
|
||||
ms=$ms
|
||||
print(int( (ms*1_000_000.0) / loops ))
|
||||
EOF
|
||||
)
|
||||
echo "$file: ${ms}ms total, ~${ns} ns/op"
|
||||
}
|
||||
|
||||
bench bench_box_create_destroy.nyash ${LOOPS[bench_box_create_destroy.nyash]}
|
||||
bench bench_method_call_only.nyash ${LOOPS[bench_method_call_only.nyash]}
|
||||
|
||||
@ -0,0 +1,62 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
# Time-boxed interpreter microbenchmarks.
|
||||
# Runs each benchmark program repeatedly for TIME_SECS seconds and reports ~ns/op.
|
||||
|
||||
ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
|
||||
BIN="$ROOT/nyash/target/release/nyash"
|
||||
TIME_SECS=${TIME_SECS:-3}
|
||||
|
||||
declare -A LOOPS
|
||||
# Use small-loop variants so each run completes quickly in interpreter
|
||||
LOOPS[bench_box_create_destroy_small.nyash]=10000
|
||||
LOOPS[bench_method_call_only_small.nyash]=5000
|
||||
|
||||
ensure_bin() {
|
||||
if [[ ! -x "$BIN" ]]; then
|
||||
echo "[build] nyash (release)"
|
||||
(cd "$ROOT/nyash" && cargo build --release >/dev/null)
|
||||
fi
|
||||
}
|
||||
|
||||
run_timeboxed() {
|
||||
local file="$1" loops_per_run="$2"
|
||||
local path="$ROOT/nyash/benchmarks/$file"
|
||||
[[ -f "$path" ]] || { echo "[skip] missing $path"; return; }
|
||||
local runs=0
|
||||
local t0=$(python3 - <<<'import time; print(time.time())')
|
||||
local deadline=$(python3 - <<EOF
|
||||
import time
|
||||
print(time.time() + $TIME_SECS)
|
||||
EOF
|
||||
)
|
||||
while :; do
|
||||
"$BIN" "$path" >/dev/null 2>&1 || true
|
||||
runs=$((runs+1))
|
||||
local now=$(python3 - <<<'import time; print(time.time())')
|
||||
awk "BEGIN{exit !(($now) >= ($deadline))}" && break || true
|
||||
done
|
||||
local t1=$(python3 - <<<'import time; print(time.time())')
|
||||
local elapsed_ms=$(python3 - <<EOF
|
||||
print(int( (float($t1) - float($t0)) * 1000 ))
|
||||
EOF
|
||||
)
|
||||
local total_ops=$((runs * loops_per_run))
|
||||
if [[ "$total_ops" -le 0 ]]; then
|
||||
echo "$file: no runs completed"
|
||||
return
|
||||
fi
|
||||
local ns_per_op=$(python3 - <<EOF
|
||||
ops=$total_ops
|
||||
ms=$elapsed_ms
|
||||
print(int((ms*1_000_000.0)/ops))
|
||||
EOF
|
||||
)
|
||||
echo "$file: ${elapsed_ms}ms, runs=$runs, ops=$total_ops, ~${ns_per_op} ns/op"
|
||||
}
|
||||
|
||||
ensure_bin
|
||||
echo "[time-box] TIME_SECS=$TIME_SECS"
|
||||
run_timeboxed bench_box_create_destroy_small.nyash ${LOOPS[bench_box_create_destroy_small.nyash]}
|
||||
run_timeboxed bench_method_call_only_small.nyash ${LOOPS[bench_method_call_only_small.nyash]}
|
||||
@ -0,0 +1,27 @@
|
||||
# Abstract
|
||||
|
||||
## English Version
|
||||
|
||||
We present Nyash, a box-first programming language that introduces symmetric memory management through init/fini pairs and a novel P2P Intent communication model. Unlike traditional object-oriented or functional languages, Nyash's "Everything is Box" philosophy unifies all computational entities—from primitive values to distributed nodes—under a single abstraction. This design enables unprecedented flexibility: seamless transitions between garbage-collected and manual memory management, transparent plugin integration via TypeBox ABI, and natural expression of distributed applications.
|
||||
|
||||
Our key contributions are: (1) the init/fini symmetric lifecycle model that guarantees deterministic resource cleanup while supporting both GC and manual modes; (2) the P2P Intent system that elevates message passing to intent-based communication, enabling elegant distributed application design; (3) a multi-tier execution architecture (Interpreter → VM → JIT → AOT → WASM) with identical semantics across all backends; (4) real-world validation through applications including NyashCoin (P2P cryptocurrency), a plugin marketplace, and cross-platform GUI applications.
|
||||
|
||||
The language is implemented in ~4,000 lines of Rust, demonstrating that a powerful and flexible language can emerge from simple, orthogonal concepts. Performance evaluation shows that Nyash applications achieve near-native speed in AOT mode while maintaining the development convenience of dynamic languages in interpreter mode. User studies indicate that the Box model significantly reduces cognitive load for concurrent and distributed programming.
|
||||
|
||||
This work presents a fresh approach to language design where simplicity and power are not opposing forces but complementary aspects of a unified philosophy.
|
||||
|
||||
## 日本語版
|
||||
|
||||
本研究では、init/finiペアによる対称的メモリ管理と新規のP2P Intent通信モデルを導入するBox中心プログラミング言語Nyashを提示する。従来のオブジェクト指向言語や関数型言語とは異なり、Nyashの「Everything is Box」哲学は、プリミティブ値から分散ノードまで、すべての計算実体を単一の抽象化の下に統一する。この設計により前例のない柔軟性が実現される:ガベージコレクションと手動メモリ管理のシームレスな切り替え、TypeBox ABIによる透過的なプラグイン統合、分散アプリケーションの自然な表現。
|
||||
|
||||
本研究の主要な貢献は以下の通りである:(1)GCモードと手動モードの両方をサポートしながら決定的なリソースクリーンアップを保証するinit/fini対称ライフサイクルモデル、(2)メッセージパッシングを意図ベース通信に昇華させ、エレガントな分散アプリケーション設計を可能にするP2P Intentシステム、(3)すべてのバックエンドで同一のセマンティクスを持つ多層実行アーキテクチャ(インタープリタ → VM → JIT → AOT → WASM)、(4)NyashCoin(P2P暗号通貨)、プラグインマーケットプレイス、クロスプラットフォームGUIアプリケーションを含む実世界アプリケーションによる検証。
|
||||
|
||||
言語は約4,000行のRustで実装されており、シンプルで直交する概念から強力で柔軟な言語が生まれることを実証している。性能評価により、NyashアプリケーションはAOTモードでネイティブに近い速度を達成しながら、インタープリタモードでは動的言語の開発利便性を維持することが示された。ユーザー調査は、Boxモデルが並行・分散プログラミングの認知負荷を大幅に削減することを示している。
|
||||
|
||||
本研究は、シンプルさと強力さが対立する力ではなく、統一された哲学の補完的な側面である言語設計への新鮮なアプローチを提示する。
|
||||
|
||||
## Keywords / キーワード
|
||||
|
||||
Box-first programming, Symmetric memory management, P2P Intent model, Multi-tier execution, Plugin architecture, Distributed systems
|
||||
|
||||
Box中心プログラミング、対称的メモリ管理、P2P Intentモデル、多層実行、プラグインアーキテクチャ、分散システム
|
||||
@ -0,0 +1,113 @@
|
||||
# Chapter 1: Introduction
|
||||
|
||||
## Beyond Objects and Functions
|
||||
|
||||
What if we could design a programming language where every computational entity—from integers to GUI windows, from network sockets to distributed nodes—shared a single, unified abstraction? Not objects with inheritance hierarchies. Not functions with monadic transformations. Just **Boxes**.
|
||||
|
||||
This is Nyash: a language built on the radical premise that "Everything is Box."
|
||||
|
||||
## The Box Philosophy
|
||||
|
||||
In traditional languages, we juggle multiple abstractions:
|
||||
- **Objects** for encapsulation and inheritance
|
||||
- **Functions** for computation and composition
|
||||
- **Primitives** for efficiency
|
||||
- **Pointers** for indirection
|
||||
- **Interfaces** for polymorphism
|
||||
- **Modules** for organization
|
||||
|
||||
Each abstraction brings its own rules, limitations, and cognitive overhead. Nyash replaces this complexity with a single, powerful concept: the Box.
|
||||
|
||||
```nyash
|
||||
// Everything is truly a Box
|
||||
local num = 42 // IntegerBox
|
||||
local str = "Hello" // StringBox
|
||||
local arr = [1, 2, 3] // ArrayBox
|
||||
local gui = new EguiBox() // GUI window is a Box
|
||||
local peer = new P2PBox() // Network node is a Box
|
||||
|
||||
// And they all work the same way
|
||||
num.toString() // "42"
|
||||
gui.toString() // "EguiBox{title: 'App'}"
|
||||
peer.toString() // "P2PBox{id: 'node1'}"
|
||||
```
|
||||
|
||||
## Three Revolutionary Concepts
|
||||
|
||||
### 1. Symmetric Memory Management (init/fini)
|
||||
|
||||
Nyash introduces perfect symmetry between construction and destruction:
|
||||
|
||||
```nyash
|
||||
box DatabaseConnection {
|
||||
init { handle, cache }
|
||||
|
||||
birth(connectionString) {
|
||||
me.handle = NativeDB.connect(connectionString)
|
||||
me.cache = new MapBox()
|
||||
print("Connected to database")
|
||||
}
|
||||
|
||||
fini() {
|
||||
me.handle.close()
|
||||
print("Disconnected from database")
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Every `birth` has its `fini`. Resources are never leaked. Yet this deterministic model coexists with optional garbage collection—developers choose their memory model per-Box.
|
||||
|
||||
### 2. P2P Intent Communication
|
||||
|
||||
Traditional message passing asks "what method to call." Nyash asks "what do you intend to achieve":
|
||||
|
||||
```nyash
|
||||
box ChatNode from P2PBox {
|
||||
onIntent(intent, data, sender) {
|
||||
switch intent {
|
||||
"chat": me.displayMessage(data.text, sender)
|
||||
"file": me.receiveFile(data.content, sender)
|
||||
"presence": me.updateStatus(data.status, sender)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Usage is natural
|
||||
chatNode.send("alice", "chat", {text: "Hello!"})
|
||||
```
|
||||
|
||||
This intent-based model naturally extends from local method calls to distributed communication without changing the programming model.
|
||||
|
||||
### 3. Transparent Multi-Tier Execution
|
||||
|
||||
The same Nyash code runs across five execution tiers:
|
||||
|
||||
1. **Interpreter**: Instant start, perfect debugging
|
||||
2. **VM**: 10x faster, same semantics
|
||||
3. **JIT**: Near-native speed for hot paths
|
||||
4. **AOT**: Deploy as standalone executables
|
||||
5. **WASM**: Run in browsers and edge computing
|
||||
|
||||
Developers write once. The execution tier is a deployment choice, not a language limitation.
|
||||
|
||||
## Real-World Validation
|
||||
|
||||
This isn't theoretical. We've built:
|
||||
|
||||
- **NyashCoin**: A P2P cryptocurrency in 200 lines
|
||||
- **Plugin Marketplace**: Dynamic code loading with security
|
||||
- **Cross-platform GUI Apps**: Same code on Linux/Windows/Web
|
||||
- **Distributed Games**: Real-time multiplayer with P2P intents
|
||||
|
||||
Each demonstrates that simplicity and power are not opposing forces—they're complementary aspects of good design.
|
||||
|
||||
## Paper Organization
|
||||
|
||||
- Chapter 2: The Box model and Everything is Box philosophy
|
||||
- Chapter 3: Symmetric memory management with init/fini
|
||||
- Chapter 4: P2P Intent model for distributed programming
|
||||
- Chapter 5: Multi-tier execution architecture
|
||||
- Chapter 6: Case studies and applications
|
||||
- Chapter 7: Evaluation and performance analysis
|
||||
- Chapter 8: Related work and comparisons
|
||||
- Chapter 9: Conclusion and future directions
|
||||
|
After Width: | Height: | Size: 13 KiB |
@ -0,0 +1,47 @@
|
||||
# Nyash言語と実行モデル——Box‑First設計と二系統実行(PyVM/LLVM)
|
||||
著者: Nyash Project
|
||||
|
||||
要旨
|
||||
NyashはBox‑First設計(Everything is Box)を採用し、birth/init/pack↔finiの対称的メモリ管理、プラグインABI、そして実行系の二系統(PyVM/LLVM)で開発・配布を成り立たせる。本稿ではPhase‑15での現実的な運用範囲として、PyVM(意味論基準)とLLVM(PHI合成・AOT/EXE)に評価を絞り、Boxモデルと実行責務の分担設計を示す。
|
||||
|
||||
## 1. はじめに
|
||||
Boxを言語の第一級抽象として採用し、型・所有・リソース・ABIを単一のメンタルモデルで統一する。設計の簡素さを保ちながら現実的な配布物を得るため、実装コストの高い経路(JIT/Interpreter)はPhase‑15では補助に留め、PyVM/LLVMの二系統を強化した。
|
||||
|
||||
## 2. 言語設計(Box‑First)
|
||||
- Boxモデル: 値・モジュール・リソースの統一表現
|
||||
- 対称メモリ: birth/init/pack と fini による決定的解放(将来GCオン/オフ両立へ拡張可能)
|
||||
- プラグインABI: TypeBox/BID‑FFI(`docs/reference/plugin-system/`)での安定相互運用
|
||||
- 例外と修飾子(将来含む): Block + Modifier の方向性(詳細は別稿)
|
||||
|
||||
## 3. 実行モデル(二系統)
|
||||
- PyVM(基準): 短絡やtruthy規約を含む意味論確認。仕様差検出・パリティ基盤
|
||||
- LLVM(配布): AOT/EXE生成、PHI合成、IRダンプ/トレース
|
||||
- 責務分担:
|
||||
- MIRはPHI‑off(合流はエッジコピー)
|
||||
- LLVMがブロック先頭でPHI合成(typed incoming)
|
||||
- PyVMは意味論の参照実装、LLVMは配布物と性能の源泉
|
||||
|
||||
## 4. ケーススタディ
|
||||
- 文字列/配列/MapなどのBoxメソッド(BoxCall)での一貫API
|
||||
- プラグイン連携(ファイル/パス等)とABI境界の単純化
|
||||
- 短絡・分岐合流でのパリティ(PyVM=意味, LLVM=PHI合成)確認
|
||||
|
||||
## 5. 評価計画(v0)
|
||||
- パリティ: `tools/parity.sh --lhs pyvm --rhs llvmlite apps/tests/CASE.nyash`
|
||||
- 性能: LLVM実行時間/起動時間/メモリ(PyVMは意味論sanity)
|
||||
- トレース: `NYASH_LLVM_TRACE_PHI=1`, `NYASH_LLVM_DUMP_IR=...`
|
||||
|
||||
## 6. 関連研究
|
||||
OOP/Actor/Capability/Plugin指向設計と実行系(LLVM/JVM/WASM)との比較。Nyashの特徴は「Box‑First × 実行責務の分離(PyVM=意味, LLVM=生成)」にある。
|
||||
|
||||
## 7. 結論
|
||||
Box‑First設計と二系統実行の分担により、複雑性を爆発させずに言語の実働ラインを維持できた。次段階ではLoopFormやJITの再統合を段階的に検討する。
|
||||
|
||||
### 再現手順
|
||||
- LLVMハーネス: `NYASH_LLVM_USE_HARNESS=1 ./target/release/nyash --backend llvm apps/tests/CASE.nyash`
|
||||
- パリティ: `tools/parity.sh --lhs pyvm --rhs llvmlite apps/tests/CASE.nyash`
|
||||
- ビルド(PDF): `tools/papers/build.sh b-jp`
|
||||
|
||||
### キーワード
|
||||
Box‑First, 実行モデル, PHI合成, LLVM, PyVM, プラグインABI
|
||||
|
||||
@ -0,0 +1,48 @@
|
||||
# Nyash: A Box-First Programming Language with Symmetric Memory Management and P2P Intent Model
|
||||
|
||||
## Authors
|
||||
TBD
|
||||
|
||||
## Abstract
|
||||
[See abstract.md]
|
||||
|
||||
## 1. Introduction
|
||||
[See chapters/01-introduction.md]
|
||||
|
||||
## 2. The Box Model: Everything is Box
|
||||
[TODO: Explain the unified Box abstraction]
|
||||
|
||||
## 3. Symmetric Memory Management
|
||||
[TODO: Detail init/fini lifecycle design]
|
||||
|
||||
## 4. P2P Intent Model
|
||||
[TODO: Explain intent-based communication]
|
||||
|
||||
## 5. Multi-Tier Execution Architecture
|
||||
[TODO: Interpreter → VM → JIT → AOT → WASM]
|
||||
|
||||
## 6. Case Studies
|
||||
### 6.1 NyashCoin: P2P Cryptocurrency
|
||||
[TODO: Implementation and evaluation]
|
||||
|
||||
### 6.2 Plugin Marketplace
|
||||
[TODO: Dynamic loading and security]
|
||||
|
||||
### 6.3 Cross-Platform GUI Applications
|
||||
[TODO: EguiBox and platform abstraction]
|
||||
|
||||
## 7. Evaluation
|
||||
[TODO: Performance, usability, and expressiveness]
|
||||
|
||||
## 8. Related Work
|
||||
[TODO: Comparison with other languages]
|
||||
|
||||
## 9. Conclusion
|
||||
[TODO: Summary and future vision]
|
||||
|
||||
## References
|
||||
[TODO: Add bibliography]
|
||||
|
||||
---
|
||||
|
||||
*Note: This is the main paper structure. Detailed content is in individual chapter files.*
|
||||
|
Before Width: | Height: | Size: 97 KiB After Width: | Height: | Size: 97 KiB |
|
Before Width: | Height: | Size: 90 KiB After Width: | Height: | Size: 90 KiB |
|
Before Width: | Height: | Size: 95 KiB After Width: | Height: | Size: 95 KiB |
|
Before Width: | Height: | Size: 5.2 KiB After Width: | Height: | Size: 5.2 KiB |
|
Before Width: | Height: | Size: 97 KiB After Width: | Height: | Size: 97 KiB |
|
Before Width: | Height: | Size: 92 KiB After Width: | Height: | Size: 92 KiB |
|
Before Width: | Height: | Size: 95 KiB After Width: | Height: | Size: 95 KiB |
|
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 56 KiB |