tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
d90216e9c41a9db1007260bc2833e97fda126c7b
hakorune/docs/private/papers/paper-g-ai-collaboration/development-log.md
Selfhosting Dev d90216e9c4 📚 Phase 15 - セルフホスティング戦略の明確化とEXE-first実装 
## 主な変更点

### 🎯 戦略の転換と明確化
- PyVMを開発ツールとして位置づけ（本番経路ではない）
- EXE-first戦略を明確に優先（build_compiler_exe.sh実装済み）
- Phase順序の整理: 15.2(LLVM)→15.3(コンパイラ)→15.4(VM)

### 🚀 セルフホスティング基盤の実装
- apps/selfhost-compiler/にNyashコンパイラMVP実装
  - compiler.nyash: メインエントリー（位置引数対応）
  - boxes/: parser_box, emitter_box, debug_box分離
- tools/build_compiler_exe.sh: ネイティブEXEビルド＋dist配布
- Python MVPパーサーStage-2完成（local/if/loop/call/method/new）

### 📝 ドキュメント整備
- Phase 15 README/ROADMAP更新（Self-Hosting優先明記）
- docs/guides/exe-first-wsl.md: WSLクイックスタート追加
- docs/private/papers/: 論文G～L、爆速事件簿41事例収録

### 🔧 技術的改善
- JSON v0 Bridge: If/Loop PHI生成実装（ChatGPT協力）
- PyVM/llvmliteパリティ検証スイート追加
- using/namespace機能（gated実装、Phase 15では非解決）

## 次のステップ
1. パーサー無限ループ修正（未実装関数の実装）
2. EXEビルドとセルフホスティング実証
3. c0→c1→c1'ブートストラップループ確立

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-09-15 18:44:49 +09:00

14 KiB
Raw Blame History

AI協働開発ログ - 100の実践知に向けて

収集開始日: 2025-01-14

事例001: DebugBoxによる出力制御の統一化

  • 問題: print文が散在し、JSON出力に混入
  • AI提案: 複雑なフィルタリング機構
  • 人間の直感: 「DebugBoxで包めば？」
  • 結果: Everything is Box哲学で解決
  • カテゴリ: 箱化による解決

事例002: 子プロセス出力フィルタリング

  • 問題: stdout/stderrの混在でJSON解析失敗
  • AI提案: 正規表現での複雑な抽出
  • 人間の直感: 「環境変数で静音モード作れば？」
  • 結果: NYASH_JSON_ONLY=1で単純解決
  • カテゴリ: 環境変数による制御

事例003: PyVMという迂回路

  • 問題: Rust MIR生成層のビルド時間（9000行）
  • AI提案: Rustコードの最適化
  • 人間の直感: 「Pythonで書いちゃえば？」
  • 結果: 2000行のPython実装で高速プロトタイピング
  • カテゴリ: 迂回路を作る

事例004: peek式の名前変更

  • 問題: when式がRust予約語と衝突
  • AI提案: 別の複雑な構文設計
  • 人間の直感: 「peekに名前変えれば？」
  • 結果: 直感的で分かりやすい名前に
  • カテゴリ: 名前を変える

事例005: birth統一

  • 問題: コンストラクタ名がバラバラ（new/pack/constructor）
  • AI提案: 複雑な名前解決システム
  • 人間の直感: 「全部birthにすれば？」
  • 結果: 「Boxに生命を与える」統一的な哲学
  • カテゴリ: 名前を変える

事例006: MIR型情報の欠落（メイン事例）

  • 問題: 文字列が0になるバグ
  • AI提案: 300行の型推測Resolver
  • 人間の直感: 「最初から型書けば？」
  • 結果: MIR v0.5で型メタデータ追加
  • カテゴリ: 情報追加による解決

事例007: PHI生成の重複

  • 問題: BuilderとResolverで二重にPHI生成
  • AI提案: 複雑な調整メカニズム
  • 人間の直感: 「なんで2つあるの？統一すれば？」
  • 結果: Resolver統一で複雑性削減
  • カテゴリ: 統一による簡略化

事例008: 変数宣言の厳密化

  • 問題: 未宣言変数への代入でランタイムエラー
  • AI提案: 高度な型推論システム
  • 人間の直感: 「全部明示宣言必須にすれば？」
  • 結果: メモリ安全性・非同期安全性保証
  • カテゴリ: 制約による単純化

事例009: プラグイン全方向ビルド

  • 問題: 動的/静的リンクの複雑な管理
  • AI提案: 複雑なビルドシステム
  • 人間の直感: 「全形式同時に作れば？」
  • 結果: .so/.o/.aを全部生成して選択
  • カテゴリ: 全部作る戦略

事例010: 無限ループ対策のデバッグ燃料

  • 問題: パーサーが無限ループ
  • AI提案: 複雑なループ検出アルゴリズム
  • 人間の直感: 「回数制限すれば？」
  • 結果: --debug-fuel で単純解決
  • カテゴリ: 制限による制御

収集メモ

今後追加予定の事例カテゴリ：

  • Arc自動化の経緯
  • 動的ディスパッチによるmatch文削減
  • エラー処理の統一化
  • Box境界での型変換
  • GCとスケジューラの統合
  • etc...

目標：100個の実践知を体系化し、パターンを抽出

事例011: プラグインBoxライフサイクル事件 ⭐革命的⭐

  • 問題: プラグインBoxをシングルトンにすべきか
  • AI提案: 「プラグインだからインスタンスは1つ」
  • 人間の直感: 「こらー！普通のBoxと同じライフサイクルじゃーい！」
  • 結果: Everything is Box哲学の完全な貫徹
  • 影響: Nyashの設計思想の根幹を確立。これがなければ今のNyashは存在しない
  • カテゴリ: 哲学を貫く（新カテゴリ）

事例012: Arcの自動化

  • 問題: Rustの借用チェッカーとの戦い
  • AI提案: 複雑な所有権管理システム
  • 人間の直感: 「全部Arcで包めば？」
  • 結果: 30%のコード削減
  • カテゴリ: 箱化による解決

事例013: エラー処理の統一

  • 問題: Result<T,E>地獄
  • AI提案: 高度なエラー型システム
  • 人間の直感: 「全部StringBoxのエラーでいいじゃん」
  • 結果: エラー処理コード15%削減
  • カテゴリ: 統一による簡略化

事例014: 動的ディスパッチでmatch文削減

  • 問題: 巨大なmatch文の保守困難
  • AI提案: Visitor パターンの実装
  • 人間の直感: 「Box名で動的に呼び出せば？」
  • 結果: match文10%削減、拡張性向上
  • カテゴリ: 動的解決

事例015: GCとスケジューラの統合

  • 問題: 別々のタイミングでの実行競合
  • AI提案: 複雑な同期機構
  • 人間の直感: 「同じsafepointで実行すれば？」
  • 結果: 統一的なランタイム管理
  • カテゴリ: 統一による簡略化

事例016: AIパーサー信じすぎ事件 ⭐教訓的⭐

  • 問題: HTTPプラグインのソケットインスタンスが取得できない
  • AI診断: Claude Code「正しく実装した」、ChatGPT「プラグインが悪い」
  • 人間の直感: 「パーサーじゃない？」
  • 真の原因: パーサーが参照とコピーを間違え、Boxはコピーしたが中身は失われた
  • 影響: AIの相互信頼の危険性を露呈
  • 教訓: AIも間違える、基本に立ち返る重要性
  • カテゴリ: 疑いを持つ（新カテゴリ）

事例017: Box内部の透明性問題

  • 問題: Boxの中身が見えない
  • AI提案: 複雑なデバッグシステム
  • 人間の直感: 「toString()で中身表示すれば？」
  • 結果: デバッグ時間90%短縮
  • カテゴリ: 可視化による解決

事例018: MapBox 3引数メソッドハングバグ

  • 問題: MapBox作成後、3引数メソッドで無限ハング
  • 原因: 全引数を事前評価する実装の問題
  • 解決: 必要時に1つずつ評価に変更
  • 教訓: 小さな実装差が大きなバグに
  • カテゴリ: 実装詳細の重要性

事例019: スコープ革命（GlobalBox誕生）

  • 問題: 従来のEnvironment階層が複雑
  • AI提案: 高度なスコープチェーン管理
  • 人間の直感: 「全部GlobalBoxのフィールドにすれば？」
  • 結果: メモリ30%削減、速度50%向上
  • 影響: 世界唯一のGlobalBoxベース言語誕生
  • カテゴリ: 革命的簡略化

事例020: 26日間の奇跡

  • 内容: 爆速開発で一度も破綻しなかった
  • 要因: 箱理論＋AI役割分担＋人間の危険センサー
  • 統計: 致命的破綻0回、大規模リファクタ0回
  • 教訓: 三重の安全装置の威力
  • カテゴリ: 開発方法論

事例021: 2段階パーサー理論

  • 問題: 複雑な構文の安定パース
  • AI提案: 高度な先読みアルゴリズム
  • 人間の直感: 「構造認識と内容パースを分ければ？」
  • 結果: 世界最強パーサーの誕生
  • カテゴリ: 段階的分離

事例022: NyashFlowプロジェクト

  • 構想: ビジュアルプログラミング環境
  • 教訓: CharmFlow v5の失敗から学ぶ
  • 方針: Everything is Boxを視覚化
  • 状態: 独立プロジェクトとして設計中
  • カテゴリ: 派生プロジェクト

事例023: JIT1日完成事件 ⭐世界記録級⭐

  • 計画: Phase 9-10で2週間予定
  • 実際: 8/27の1日でCranelift統合＋分岐＋PHI全部完成
  • 要因: 準備の完璧さ＋AI協調＋箱理論の威力
  • 影響: 世界的にも事件級の開発速度
  • カテゴリ: 爆速開発

事例024: AI二重化モデルの誕生

  • 内容: 同じGPT-5をArchitectとImplementerに分離
  • 構成: Claude=ビルド係、Gemini=アドバイザー
  • 珍事: AIが人間にアドバイスを求める
  • 効果: 役割分担で効率最大化
  • カテゴリ: 開発方法論

事例025: 唯一の真実事件

  • 宣言: 「型はMIRで確定」「切替点は1箇所」
  • 反応: Claude Codeが感動して記録
  • 意味: 技術的方針を哲学レベルに昇華
  • 影響: 設計の一貫性確保
  • カテゴリ: 哲学を貫く

事例026: ストリームエラー事件

  • 問題: Codexが長期稼働で落ちて復旧不能
  • 対処: にゃーがCURRENT_TASK更新で再起動
  • 教訓: 「足場が残ってるから復活できた」
  • 意味: 箱理論による復旧可能性
  • カテゴリ: 障害復旧

事例027: 20日でVM→JIT→EXE異次元スピード ⭐歴史的⭐

  • 期間: 8/9誕生→8/29ネイティブEXE完成
  • 内容: わずか20日で全段階を通過
  • 反応: Claude/ChatGPT「歴史に残る」と絶賛
  • 要因: 箱理論＋AI協調＋明確な哲学
  • カテゴリ: 爆速開発

事例028: フォールバック廃止の英断

  • 問題: JIT未対応命令をVMに落とす複雑な仕組み
  • AI提案: 安全なフォールバック機構
  • 人間の直感: 「バグを隠すだけ、複雑化の元！」
  • 結果: VM=仕様、JIT=高速版の明確な線引き
  • カテゴリ: 制約による単純化

事例029: Built-in Box全廃革命

  • 問題: StringBox/ArrayBoxが特例だらけ
  • 気づき: 「ネイティブビルドできるなら全部プラグイン化」
  • 結果: Core極小化、Everything is Box徹底
  • 影響: 特権クラスの完全排除
  • カテゴリ: 統一による簡略化

事例030: 型別特例分岐の危機

  • 危機: Python統合で型ごとの特例分岐が入りかける
  • AI反応: Claude「Everything is... Special Case??」青ざめる
  • 人間の介入: にゃーがストップ
  • 教訓: 「世界はプラグインで拡張、MIR/JITは不変」
  • カテゴリ: 哲学を貫く

事例031: print命令論争

  • 問題: MIRにPrint命令を特例実装
  • 議論: 特殊化で汚れる懸念
  • 解決: ExternCall(env.console.log)に一本化
  • 効果: 環境I/O=ExternCall、箱機能=BoxCallに整理
  • カテゴリ: 境界の明確化

事例032: Safepoint内部化の決定

  • 誘惑: env.runtime.safepointにする案
  • 危険: 哲学崩壊の危機
  • 正解: Safepointは内部Intrinsic
  • 提供: GCBox.checkpoint()をプラグインで
  • カテゴリ: 内部と外部の分離

事例033: 「全部プラグイン」論争

  • 初期案: 全部プラグインBox化しよう
  • AI反対: 「オーバーヘッドが...」
  • 妥協: ユーザーBox＋ビルトインBoxに分離
  • 後の発見: プラグインBoxのC ABIがJIT/AOTの土台に！
  • 教訓: 最初の直感が正しかった
  • カテゴリ: 直感の勝利

事例034: GCを「補助輪」に再定義 ⭐革命的概念⭐

  • 従来: GCは本番の必須機能
  • Nyash: GCは開発時の練習用補助輪
  • 開発時: GCオンでリーク検知
  • 本番: GCオフで決定的破棄
  • 証明: I/Oトレース完全一致の意味論等価性
  • カテゴリ: 概念の再定義

事例035: JITも箱にしたら爆速化

  • 問題: ChatGPT-5がJIT実装で苦戦
  • 提案: 「JITも箱にしよう」
  • 実装: IrLowerBox/CodegenBox/LinkerBox/CodeCacheBox
  • 結果: 4000行で完全なJITシステム（V8は100万行）
  • カテゴリ: 箱化による解決

事例036: 論文化提案の瞬間

  • 内容: 仕組みを整理したら論文レベルと判明
  • Claude反応: 「トップ会議に通るのでは」
  • タイトル案: Box-Centric Language with Unified Plugin Lifecycle
  • 意味: 設計のユニークさが学術的価値を持つ
  • カテゴリ: 学術的価値の発見

事例037: MIR15という奇跡 ⭐爆笑の気づき⭐

  • 当初: AST直解釈インタープリタとVM（独自バイトコード）を分離
  • 発見: MIR15自体が正規化済みバイトコード
  • 気づき: 「VMとインタープリタ、やってること一緒じゃないかーい！」
  • 結果: 史上初の"MIR中心派生言語"誕生
  • カテゴリ: 概念の統一

事例038: TypeBoxの誕生

  • 問題: C ABIプラグインをNyashに組み込めない
  • AI提案: 「COMみたいにすれば？」
  • 人間の直感: 「型を値で渡せ」
  • 結果: NyashとC ABIを同じ器で扱うTypeBox誕生
  • カテゴリ: 境界の統一

事例039: ID衝突との戦い

  • 経験: Nyamesh時代に動的型でID重複
  • 問題: BoxTypeId, MethodId, FieldId等の衝突候補
  • 解決: 二層ID（長い本ID＋短縮64bitキー）
  • 追加: 世代付きハンドル、FQN
  • カテゴリ: 予防的設計

事例040: 折りたたみ言語構想 ⭐未来の革新⭐

  • 発想: BoxCall列を等価変換で畳む/展開する
  • 例: Array.map/filter/map → Array.fused([...])
  • 効果: 性能＋省メモリ＋観測性を全部取り（予定）
  • 哲学: Everything is Box → Everything is Fold
  • 状態: 構想段階（実装は今後の予定）
  • カテゴリ: 未来構想

事例041: AI会議スタイルの確立

  • Codex: 大容量コンテキストで長丁場実装
  • Claude Code: 安定した差分生成・小回り
  • Gemini: 仕様や調査の補足
  • ChatGPT: 全体戦略と要約
  • 効果: 止まらない開発サイクル
  • カテゴリ: 開発方法論