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

This commit is contained in:
nyash-codex
2025-09-27 08:45:25 +09:00
parent fcf8042b06
commit cb236b7f5a
263 changed files with 12990 additions and 272 deletions

View 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本。完成してから次へ

View File

@ -0,0 +1,89 @@
# MIR14 Core14 Specification (Draft)
本メモは、MIR14Core14命令体系の確定仕様と、レガシー命令の廃止方針をまとめる。実装は"Core14既定ON・forbidlegacy"を前提とする。
## 1. Core14 命令一覧(最小限+実践的)
| 区分 | 命令 | 役割(要点) |
|------|------|---------------|
| 値 | 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 バリアはCore13で抽象化し、下位で最適化。
## 3. 高位→Core13 への標準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 IRloop.begin/iter/branch/endに正規化。
- 最終: LoopForm → Core13 へ逆LoweringBranch/Jump/Phi/Return へ落とす)。
これにより、言語表記の自由度とIRの直交性正規形を両立する。
## 4. LoopFormLoopSignal IRとの整合
- LoopForm は“中間正規形”として `loop.begin/iter/branch/end` を導入Core13の上位層
- 逆Lowering: LoopForm → Core13 は以下の基本変換で常時可能:
- `loop.begin` → ヘッダBlock生成Phi配置
- `loop.iter` → 条件/stepコードをヘッダ/ボディに分配
- `loop.branch``switch/Branch` + `Jump`
- `loop.end` → 合流先にReturn/JumpSignal種別に応じる
- Safepoint/Barrier は Core13 層で維持。LoopFormは制御の正規化に専念。
## 5. レガシー命令の廃止マップ
- Load/Store / ArrayGet/ArraySet / RefGet/RefSet / WeakNew/WeakLoad → BoxCall必要時Barrier/Safepoint併用
- TypeCheck/Cast → TypeOp
- PluginInvoke → ExternCall / BoxCallABIに応じて
- Nop/Copy/UnOp 等の補助命令 → 最適化/ビルダ内部に吸収表面APIから排除
## 6. ExternCall の階層化(境界の明示)
- iface例:
- `env.runtime`: ランタイム内部APIcheckpoint等
- `env.gc`: GC操作将来
- `plugin.*`: プラグイン提供のFFI群
- 指針: BoxCallで表現可能な操作は BoxCall を優先抽象度維持。どうしてもhost境界を越える必要がある場合のみ ExternCall。
## 7. 妥当性検査Lint/Verify
- Phi配置の正当性支配木チェック
- 終端命令の整合
- EffectとSafepointの整合長期ループでの安全点確保
- レガシー命令検出forbidlegacy がONであること
## 8. 移行計画(段階導入)
1) フラグ: Core13 既定ON/forbidlegacy を実装側で保証nyash.tomlも同値
2) レガシー→Core13 置換を段階実施(ビルダ/最適化/バックエンドを横断)
3) LoopForm任意を導入し、while/for/scope から正規化→逆LoweringでCore13へ落とす
4) 検証: 既存スイート + 再現ベンチAOT/VM/JIT + Lint で差分監視
---
この文書は“仕様の真実の源泉single source of truth”として、Core13 と上位LoopFormの整合と廃止路線を明示する。実装の進捗に合わせて更新する。

View File

@ -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 enumGlobal/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新規追加
- 制御BoxLoopForm
### 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日以内に完成 ✨

View File

@ -0,0 +1,105 @@
# 論文A: MIR14で作る万能実行系
> Scope (2025-09-19): 本稿の実験・評価は PyVM意味論リファレンスと LLVM/llvmliteAOT/EXEハーネスに限定する。MIR は PHIoff合流はエッジコピーで、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/)

View File

@ -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"

View 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.

View File

@ -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"

View File

@ -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()

View File

@ -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を提示する。この進化は、コンパイラ設計における理論的ミニマリズムと実践的効率性の間の緊張関係を示している。
本研究の主要な貢献は以下の通りである1Core-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コンパイル

View File

@ -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.

View File

@ -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.

View File

@ -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
- 関数もBoxConstで表現
- すべての操作がBoxCall
### 3. 実用性とのバランス
- Safepointでガベージコレクションをサポート
- Barrierで並行性を考慮
- ExternCallで拡張性を確保

View File

@ -0,0 +1,55 @@
# 14命令のミニマルIRによる統一実行基盤設計MIR14, PHIオフ方針
著者: Nyash Project
要旨
Nyashは「Everything is Box」哲学を核に、14命令MIR14の最小IRでInterpreter/VM/JIT/AOT/GUIを目指してきた。本稿ではPhase15における設計判断として、MIR側のPHI生成を停止PHIoff, エッジコピー合流し、PHI形成をLLVMハーネス側に委譲する方針を採用した経緯と効果を報告する。現在の評価範囲はPyVM意味論リファレンスとLLVM/llvmliteAOT/EXEハーネスに限定し、両者のパリティおよびLLVM側の性能・安定性を中心に示す。
> 更新メモ2025-09-26: Phase15 では PHI-onMIR14が既定に復帰したよ。この資料は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、ifmerge前宣言等で安定性向上
- 不変条件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委譲により、設計・検証・配布ラインを細く強く維持できた。今後はLoopFormMIR17や実行器の拡張を、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, 統一実行

View File

@ -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.*

View File

@ -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
- 制御BoxLoopForm
- 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 DesignEverything is Box完全版
- [ ] Chapter 3: Memory Modelbirth統一
- [ ] Chapter 4: Exception Handling Revolution新規作成
- [ ] Chapter 5: Property System新規作成
- [ ] Chapter 6: Execution Backends2本柱更新
- [ ] Chapter 7: Case Studies最新実例
- [ ] main-paper-jp.md統合
- [ ] Abstract更新
- [ ] AI査読ChatGPT/Claude
---
## 🗓️ スケジュール
- **Day 1-2**: 構造更新、Everything is Box完全版
- **Day 3-4**: Chapter 2-3Language Design, Memory Model
- **Day 5-6**: Chapter 4-5Exception, Property
- **Day 7-8**: Chapter 6-7Execution, Case Studies
- **Day 9**: 統合、AI査読
- **Day 10**: 修正、完成
**目標**: 10日以内に完成 ✨

View File

@ -0,0 +1,142 @@
# 論文B: Nyash言語と実行モデル
> Scope (2025-09-19): 本稿の範囲は PyVM と LLVM/llvmlite の2系統に限定。MIR14 は PHIoff合流はエッジコピー、PHI 形成は LLVM ハーネスで行う。JIT/Interpreter は Phase15 では補助扱い。詳細は 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)

View File

@ -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"

View 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.

View File

@ -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"

View File

@ -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]}

View File

@ -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]}

View File

@ -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による透過的なプラグイン統合、分散アプリケーションの自然な表現。
本研究の主要な貢献は以下の通りである1GCモードと手動モードの両方をサポートしながら決定的なリソースクリーンアップを保証するinit/fini対称ライフサイクルモデル、2メッセージパッシングを意図ベース通信に昇華させ、エレガントな分散アプリケーション設計を可能にするP2P Intentシステム、3すべてのバックエンドで同一のセマンティクスを持つ多層実行アーキテクチャインタープリタ → VM → JIT → AOT → WASM4NyashCoinP2P暗号通貨、プラグインマーケットプレイス、クロスプラットフォーム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モデル、多層実行、プラグインアーキテクチャ、分散システム

View File

@ -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

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

View File

@ -0,0 +1,47 @@
# Nyash言語と実行モデル——BoxFirst設計と二系統実行PyVM/LLVM
著者: Nyash Project
要旨
NyashはBoxFirst設計Everything is Boxを採用し、birth/init/pack↔finiの対称的メモリ管理、プラグインABI、そして実行系の二系統PyVM/LLVMで開発・配布を成り立たせる。本稿ではPhase15での現実的な運用範囲として、PyVM意味論基準とLLVMPHI合成・AOT/EXEに評価を絞り、Boxモデルと実行責務の分担設計を示す。
## 1. はじめに
Boxを言語の第一級抽象として採用し、型・所有・リソース・ABIを単一のメンタルモデルで統一する。設計の簡素さを保ちながら現実的な配布物を得るため、実装コストの高い経路JIT/InterpreterはPhase15では補助に留め、PyVM/LLVMの二系統を強化した。
## 2. 言語設計BoxFirst
- Boxモデル: 値・モジュール・リソースの統一表現
- 対称メモリ: birth/init/pack と fini による決定的解放将来GCオン/オフ両立へ拡張可能)
- プラグインABI: TypeBox/BIDFFI`docs/reference/plugin-system/`)での安定相互運用
- 例外と修飾子(将来含む): Block + Modifier の方向性(詳細は別稿)
## 3. 実行モデル(二系統)
- PyVM基準: 短絡やtruthy規約を含む意味論確認。仕様差検出・パリティ基盤
- LLVM配布: AOT/EXE生成、PHI合成、IRダンプ/トレース
- 責務分担:
- MIRはPHIoff合流はエッジコピー
- 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の特徴は「BoxFirst × 実行責務の分離PyVM=意味, LLVM=生成)」にある。
## 7. 結論
BoxFirst設計と二系統実行の分担により、複雑性を爆発させずに言語の実働ラインを維持できた。次段階では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`
### キーワード
BoxFirst, 実行モデル, PHI合成, LLVM, PyVM, プラグインABI

View File

@ -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.*

Some files were not shown because too many files have changed in this diff Show More