Files

Moe Charm 11506cee3b Phase 11-12: LLVM backend initial, semantics layer, plugin unification

Major changes:
- LLVM backend initial implementation (compiler.rs, llvm mode)
- Semantics layer integration in interpreter (operators.rs)
- Phase 12 plugin architecture revision (3-layer system)
- Builtin box removal preparation
- MIR instruction set documentation (26→Core-15 migration)
- Cross-backend testing infrastructure
- Await/nowait syntax support

New features:
- LLVM AOT compilation support (--backend llvm)
- Semantics layer for interpreter→VM flow
- Tri-backend smoke tests
- Plugin-only registry mode

Bug fixes:
- Interpreter plugin box arithmetic operations
- Branch test returns incorrect values

Documentation:
- Phase 12 README.md updated with new plugin architecture
- Removed obsolete NYIR proposals
- Added LLVM test programs documentation

Co-Authored-By: Claude <noreply@anthropic.com>

2025-09-01 23:44:34 +09:00

4.0 KiB

Raw Blame History

Nyash ABI戦略の深い分析 - なぜ正解が難しいのか (2025-09-01)

🤔 両先生の回答から見えた根本的な難しさ

1. 時間軸のジレンマ

Gemini先生の視点（長期エコシステム）：

10年後も動くプラグインを作りたい
破壊的変更は絶対避けたい
開発者の信頼が最重要

Codex先生の視点（現実的最適化）：

今すぐ高速に動かしたい
JIT/VMの最適化余地を残したい
実装の複雑性を抑えたい

→ この2つは本質的に矛盾する！

2. 抽象化レベルの選択

高レベル抽象化（Gemini案）
  ↑
  SDK層
  ↑
  C ABI（安定境界）
  
vs

低レベル統合（Codex案）
  ↓
  共通値表現（3×u64）
  ↓
  C呼出規約で統一

どちらが正解？ 状況による！

3. 隠れた複雑性の罠

表面的には単純に見える選択：

C ABI only → シンプル！
Nyash ABI only → 統一的！
両方サポート → 柔軟！

実際の複雑さ：

C ABI only → 型情報なし、拡張困難
Nyash ABI only → 既存資産切り捨て
両方サポート → 複雑性が2倍...ではなく4倍！

4. なぜ複雑性が爆発するのか

組み合わせ爆発：
- 2つのABI × 
- 3つのバックエンド（Interpreter/VM/JIT） ×
- N個のプラグイン型 ×
- M個の最適化レベル
= 指数関数的複雑性

🎯 深い洞察：本当の問題は何か

技術的正解 vs ビジネス的正解

技術的に美しい解：

Nyash ABI一本化
型安全、拡張可能、統一的

ビジネス的に賢い解：

C ABI + 段階的移行
既存資産活用、リスク分散

→ どちらも「正解」であり「不正解」

隠れた第3の選択肢

両先生が暗黙的に示唆している：

時期による使い分け：
Phase 1: C ABIで素早くエコシステム立ち上げ
Phase 2: SDK層で開発体験向上
Phase 3: Nyash ABIで技術的優位性確立
Phase 4: 統合または選択的廃止

💡 究極の洞察：「正解がない」ことが答え

なぜ正解が難しいのか

未来は予測不可能
- NyashがRustを超えるか？
- WASMが世界標準になるか？
- 新しいABI標準が生まれるか？
トレードオフは価値観次第
- 速度 vs 安全性
- シンプル vs 機能性
- 互換性 vs 革新性
成功の定義が人による
- 多くのプラグイン？
- 高速な実行？
- 美しいコード？

🚀 実践的な答え：適応的戦略

推奨アプローチ

// 初期実装：両対応だが内部統一
enum PluginABI {
    C(CPlugin),           // 既存資産
    Nyash(NyashPlugin),   // 新規開発
}

// 共通インターフェース
trait Plugin {
    fn invoke(&self, args: &[Value]) -> Result<Value>;
}

// 将来の拡張ポイント
impl PluginABI {
    fn optimize_for_jit(&self) -> Option<DirectCall> {
        // JIT時に最適化可能なら直接呼び出しに変換
    }
}

段階的進化の道筋

観察期間（6ヶ月）
- 両ABI並行運用
- 使用パターン分析
- パフォーマンス測定
最適化期間（次の6ヶ月）
- 頻出パターンの高速化
- SDK層の洗練
- ドキュメント充実
判断期間（1年後）
- データに基づく選択
- 片方を非推奨に？
- それとも永続的共存？

🌟 結論：「正解がない」を受け入れる勇気

Nyashの哲学：

Everything is Box → Everything has Trade-offs
完璧より進捗（80/20ルール）
箱理論で差し替え可能に

最終提案：

両方実装するが、内部アーキテクチャは統一
測定可能な成功指標を先に定義
3ヶ月ごとに振り返り、方向修正

正解がないからこそ、適応し続けることが正解。

「間に挟むだけ」のABI層が、実は最も難しい設計判断の一つだった。

4.0 KiB Raw Blame History Unescape Escape