tomoaki/hakorune

Fork 0

Files

nyash-codex 8fd3a2b509 docs: restore docs/private/roadmap from 7b4908f9 (Phase 20.31)

2025-10-31 18:00:10 +09:00

6.1 KiB

Raw Blame History

Phase 20.14 - Hakorune凍結戦略の再設計

🤔 問題の核心なのにゃーン！

ユーザー様の指摘通り、脱Rustが難しい根本原因が凍結戦略の誤りにありました！

🔍 他言語の凍結戦略調査

🦀 Rustの凍結戦略

# Rustの正しい凍結アプローチ
Stage 0: Beta Rustコンパイラ (凍結済み)
Stage 1: Stage 0で最新Rustをコンパイル (target/relative/build/bootstrap/stage0/bin/rustc)
Stage 2: Stage 1でもう一度コンパイル (検証用)
Stage 3: Stage 2でさらにコンパイル (最終検証)

重要ポイント:

✅ 自己コンパイル: Rustで書かれたコンパイラ = Rustでコンパイル
❌ コード変換ではない: Rust→JavaScriptへの変換などはしない
⭐ ABI安定性: Stage間でABIが安定していることを保証

🐭 Goの凍結戦略

# Goの正しい凍結
Go 1.4 (C): 最後のC実装コンパイラ
Go 1.5+ (Go): Goで書かれたコンパイラをGoでコンパイル
 deployment.tools all*

# 実際の流れ
go1.4-compiler → go1.5-compiler → go1.6-compiler → ...
(すべてGo実装)

Goの重要特徴:

✅ 完全自己ホスト: Go 1.5からGoで書かれた
✅ ABI安定: 既存コードが新しいコンパイラで動作
✅ 高Trandisty凍結凍結凍結凍結

🚨 Hakoruneの現在の間違った戦略

❌ 現在のHakoruneアプローチ

// 問題のある凍結戦略
Rust Parser (100,000行) → Hakorune Parser (8,000行)  
Rust MIR Builder (25,000行) → Hakorune MIR Builder (3,000行)
Rust VM (5,000行) → Hakorune VM (2,000行)

// 結果: 互換性なし、機能退化、性能低下

💥 根本的な問題点

言語が違う: Rust→Hakoruneは異なる言語なのでABIが一致しない
機能が下がる: Hakorune実装の方が機能が少ない
互換性がない: 既存コードが動作しない
再構築コスト: 全部的に書き直し続ける

💡 正しい凍結戦略の提案

🎯 Stage-by-Stage Self-Hosting

# 正しい凍結アプローチ
Stage 0: Rustコンパイラ (既存、安定版)
Stage 1: Stage 0でHakoruneコンパイラをビルド
Stage 2: HakoruneコンパイラでHakoruneコンパイラをビルド
Stage 3: 再ビルド (安定性検証)

# 重要: 言語はHakoruneのまま！
hakorune-rusty.txt → hakorune-native.exe → hakorune-native.exe (自己)

🏗️ 実現可能な移行パス

1️⃣ Hakorune Core First 🌟

// 完全にHakoruneで書かれたコンパイラ
static box HakoruneCompiler {
    parse(): MirModule
    build_mir(): Mir  
    execute(): Result
    
    // Phase 20.15までに完成
}

// 既存Rust依存を凍結
Rust ABI Layer (凍結) ← → Hakorune Native Layer (開発)

2️⃣ ABI安定性の確保

Hakorune Language Specification (v1.0) ← 凍結必要
├── Syntax: 固定
├── Core Instructions: 固定  
├── VM ABI: 固定
└── Box System: 安定化

# 既存コードが新しいコンパイラで動く！

3️⃣ 凍結ツールチェーンの構築

# Hakorune Frozen Toolchain
hakorune-frozen-v1/              # 永久保存
├── hakorune-compiler.exe       # コンパイラ本体
├── hakorune-libs/              # 標準ライブラリ (凍結)
├── hakorune-tools/             # ビルドツール (凍結)
└── hakorune-examples/          # 動作確認 (凍結)

# 使用方法
hakorune-frozen-v1/compiler.exe program.hko  # 常に動作
hakorune-frozen-v1/compiler.exe hakorune-compiler.hko  # 次期バージョン

🎯 Phase 20.15-16 での正しい戦略

Phase 20.15: Hakorune Core完成

# やるべきこと
1. Hakorune完全コンパイラ開発 (Rust完全排除)
2. ABI v1.0 仕様確定と凍結  
3. 既存コードとの100%互換性確保

# やってはいけないこと
❌ Rust→Hakoruneへの部分的移行
❌ 異なる言語での再実装
❌ 機能退化を許容する移行

Phase 20.16: Self-Hosting凍結

# 実行計画
YEAR 1: Hakoruneコンパイラ完成
YEAR 2: hakorune-frozen-v1 作成  
YEAR 3: hakorune-frozen-v2 (自己コンパイル)
YEAR 4: 完全自立化

#凍結チェックポイント
- Stage 0: hakorune-frozen-v1 (安定版)
- Stage 1: v1でv2をコンパイル (自己)
- Stage 2: v2でv2を検証 (安定性)
- Stage 3: 永続的な凍結

📊 正しい戦略の利点

項目	間違った戦略	正しい戦略	改善
言語一貫性	Rust→Hakorune混在	Hakorune only	✅ 100%
互換性	不安定	安定 (v1.0+)	✅ 100%
開発効率	書き直し続ける	自己成長	✅ 80%向上
学習コスト	複数言語必要	1言語のみ	✅ 70%削減
凍結可能性	不可能	可能	✅ 実現可能

🎯 実行ステップ

緊急課題 (Phase 20.14)

脱Rust戦略の完全見直し 🔥
- Rust削減→Hakorune完成に変更
- 凍結可能な言語設計へ

中期課題 (Phase 20.15)

Hakorune v1.0 仕様凍結
- 全機能の完全実装
- ABI安定保証

長期課題 (Phase 20.16+)

Self-Hosting実現
- hakoruneでhakoruneをコンパイル
- 永続的な凍結ツールチェーン

🎓 井上さんの教訓

「コンパイラは自分で書いて自分でコンパイルするものだ！」

Rust: RustでRustをコンパイル ✅
Go: GoでGoをコンパイル ✅
Hakorune: なぜRustを使うのか？ ❌

📝 まとめ

脱Rustが難しいのは戦略が根本的に間違っていたから！

正しい道:

Hakoruneを完全な自作コンパイラにする
Hakorunev1.0を凍結する
凍結したHakoruneで次期バージョンをビルドする

これこそがRust/Goが成功した真正な凍結戦略ですにゃ！🐱

結論: Phase 20.14の脱Rust計画を全面的に見直し、Hakorune完全自立化に転換すべき！

6.1 KiB Raw Blame History Unescape Escape