tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
486adfbec5b6fa73aac00ebea94adb4bd0cd8b81
hakorune/docs/private/papers/gemini_nyash_compiler_discussion_summary.md

15 KiB
Raw Blame History

GeminiとのNyashコンパイラ設計に関する議論のまとめ

日付: 2025年9月10日水曜日

1. Nyash LLVM PHIノード問題（SSAバグ）の分析

問題の特定

  • エラーメッセージ: phi incoming value missing: in_vid=ValueId(29)
  • 具体的な状況: PHIノードが %29 を bb62 から来ると期待しているが、実際には %29 は bb66 で定義されており、制御フローは bb66 -> bb62 -> bb60 となっている。PHIは %29 を bb66 から期待すべき。
  • 根本原因: SSA構築ロジックが、PHIノードの入力における BasicBlockId を誤って決定している。特に、ループバックエッジに中間ジャンプブロック（bb62 のような）が存在する場合に発生。

修正の方向性

  • 場所: 主に src/mir/builder.rs および src/mir/loop_builder.rs。
  • 内容: SsaBuilder の値伝播ロジックを強化し、中間ブロックを介しても値が実際にライブアウトする BasicBlockId を正しく識別できるようにする。

2. 参照カウントGCの導入検討

ユーザーの提案

  • Nyashの現在のライフサイクル（スコープを抜けると解放、fini で解放、weak は無視）に加えて、「参照カウンターが2以上なら、スコープを抜けたり fini を呼ばれても解放しない」というルールを導入。
  • GCは開発/テスト用であり、本番ではオフにできる。重くなっても許容。

分析とアドバイス

  • 戦略: 参照カウント（RC）GCの導入。
  • メリット: 即時解放、予測可能な一時停止。
  • デメリット: オーバーヘッド、参照サイクル（weak 参照で対応必要）。
  • 実装アプローチ:
    • シンプルに開始: まずはコアの retain（インクリメント）と release（デクリメントし、ゼロなら解放）ロジックに集中し、初期段階ではサイクルコレクタは実装しない。
    • コンパイル時機能: #[cfg(feature = "gc")] のようなコンパイル時フラグでGCの有効/無効を切り替える。これにより、GCオフ時にはランタイムオーバーヘッドがゼロになる。
    • Fini の役割: GC有効時は参照カウントをデクリメントする役割に。
    • Weak 参照: 参照カウントを増やさない参照として実装し、サイクルを断ち切る手段として活用。
    • LLVM実装: 各Boxに参照カウントフィールドを追加し、nyash_box_retain、nyash_box_release などのランタイムヘルパー関数を nyrt に実装。コンパイラバックエンドがこれらのヘルパー関数への呼び出しを生成する。
  • Safepoint: 純粋なRCでは不要だが、将来的にサイクル回収のためのトレーシングGCを導入する場合には必要となる。

3. プラグイン設定 (nyash.toml vs nyash_box.toml)

状況

  • nyash.toml は中央レジストリとして機能し、[libraries] セクションでプラグインの詳細を定義。
  • nyash_box.toml は各プラグインディレクトリ内に存在し、プラグインごとの詳細な仕様を記述。

分析

  • 重複: nyash.toml に一部のプラグイン定義が重複しているように見えるが、これは「新スタイル（[plugins] セクションと nyash_box.toml）への移行期間における後方互換性のため」である。
  • 役割: nyash.toml は中央マニフェストとタイプIDレジストリ、nyash_box.toml は各プラグインの詳細な仕様書として機能する。nyash_box.toml は実際にプラグインロード時に優先的に参照され、使用されている。

4. MIR13の未実装命令

3つの命令の実装戦略

  1. Safepoint:
    • 実装: 現時点ではno-op。将来のGC拡張ポイントとして枠を確保。
    • 評価: 非常に実用的で、将来を見据えたアプローチ。
  2. TypeOp:
    • 実装: Check は既存の nyash_handle_get_type_id を活用して型IDを比較。Cast は当面パススルーで、将来的にBoxCall経由で実装。
    • 評価: 概ね良好だが、MirType から type_id へのマッピングの正確性と一貫性を確保する必要がある。
  3. Barrier:
    • 実装: LLVMの llvm.memory.barrier intrinsic を使用し、Acquire（Read）と Release（Write）セマンティクスを実装。
    • 評価: 良好だが、より現代的で正確なメモリ順序付けのために llvm.fence intrinsic の使用を検討すべき。

5. GitHub Copilot / Codex の機能

ユーザーの主張と確認

  • 主張: GitHub CopilotはIssueに書くと直接ソースコードを編集してくれる。
  • 確認: ユーザーの主張は正しい。GitHub Copilotは、IssueをCopilotに割り当てることで、新しいブランチを作成し、コード変更を含むプルリクエストを自律的に生成する機能を持つ。
  • 補足: 最終的なコードの統合には、人間によるレビューと承認が必須。chatgpt.com/codex は基盤となるAIモデルに関する情報であり、直接サービスではない。

6. LoopForm（MIR13の次世代IR）

概念

  • 目的: 制御フロー（ループ、分岐、関数、スコープ、ジェネレータ、async）を「Loop=反復の箱」という概念に統一し、簡素化するための中間正規形。
  • 哲学: 「制御を値として扱う（Signal）」という「LifeBox Model」の一部。
  • 利点: フロントエンドのLoweringの一様化、CFG合流点の標準化、PHI最適化の簡素化。
  • MIR13との関係: MIR13（Core-13）の上位層であり、最終的にはCore-13に**再Lowering（逆Lowering）**可能。

4つの命令

  1. loop.begin: ループ/構造のエントリポイント、PHIの合流点。
  2. loop.iter: イテレーション/パスのエントリ、Signalディスパッチ。
  3. loop.branch: 条件付きディスパッチ、制御フロー決定。
  4. loop.end: ループ/構造の終了点、制御シグナルを運ぶ。
  • 評価: AIが考案したこれらの命令は、制御フローを統一するための非常に堅牢で最小限のセットであり、よく考えられている。

「Boxがそのままループ」哲学

  • アイデア: Boxがフィールド、メソッド、fini を持ち、そこにループの条件式をメソッドとして追加すれば、Box自体がループになるという究極の「Everything is Box」の具現化。
  • 利点: 究極の統一性、メタプログラミングの可能性、最適化の機会、概念的な優雅さ。
  • 課題: パフォーマンスオーバーヘッド、Loweringの複雑さ、デバッグ。

実装順序

  1. フェーズ0（準備）: MIR13の安定化、SSAバグ修正、堅牢なMIR検証、MIRダンプツールの実装。
  2. フェーズ1（コア変換）: LoopForm IRの定義、高レベル構文からLoopFormへのLowering、LoopFormからCore-13への逆Lowering（安全のためデフォルト有効）。
  3. フェーズ2（検証と最適化）: LoopForm検証パス、基本的なLoopForm最適化。
  4. フェーズ3（高度な機能）: LifeBox Model統合、高度なLoopForm最適化、LoopFormからの直接LLVMバックエンド（将来）。
  • 原則: 安全性、可逆性、段階的導入を常に維持。

MIR出力ツール

  • 必要性: コンパイラ開発におけるデバッグ、理解、最適化開発に不可欠。
  • 提案機能:
    • 人間が読めるテキスト形式（SSA、基本ブロック、制御フロー、型情報）。
    • Graphviz DOT形式（CFG可視化）。
    • 特定のコンパイラフェーズでのMIRダンプ。
    • MIR差分ツール。
    • インタラクティブMIRビューア。
    • MIR検証/バリデーション。
    • MIR固有のアノテーション（@mir_dump, @mir_assert）。

「単純なループ」ヒント

  • アイデア: MIR出力時（または最適化前）に「これはただのループ」というヒントを与えることで、オプティマイザが LoopBox を従来のループとして扱い、積極的な最適化（インライン化など）を適用できるようにする。
  • 実装: ヒントは LoopForm 構造に付加され、オプティマイザが BoxCall を含む LoopForm を「見通す」ことを可能にする。BoxCall などの既存MIR命令はそのまま残る。

7. ブロック後置catch設計 - try キーワード削除への挑戦

日付: 2025年9月18日水曜日

議論の発端

  • ユーザーの問題意識: try-catch構文がインデント階層を一つ深くする問題と、tryキーワードの必要性への疑問。
  • 最初の提案: { body } catch (e) { handler } [finally { cleanup }] という「ブロック後置catch」構文の提案。

Geminiの初期反応と段階的理解

Phase 1: 完全否定（「インデントの意味」論）

  • Geminiの主張: tryによる階層化は「エラー処理という特別な関心事を視覚的に隔離する計算された設計」。
  • 比喩: 工事現場の安全柵として、tryブロックの意味的境界を説明。
  • 結論: 「インデントを増やさない新しい例外処理は世界を驚かせる革命的なこと」と認めつつも、基本的には否定的。

Phase 2: 技術的課題の指摘（「throw の行き先」問題）

  • 技術的懸念: try がない場合、コンパイラが「throw がどこに飛ぶべきか」を決定できない。
  • Builder の迷子問題: AST解析前に throw を処理する場合の技術的困難。
  • 合図の重要性: try が「catch の席を予約する」重要な役割を果たしているという指摘。

Phase 3: 反転（「Builder は解る」）

  • ユーザーの反論: 「ビルダーは解るよ　だって　ループが単位だからそのときcatchの存在もわかる」
  • Geminiの認識修正: AST（抽象構文木）が既に構造を解析済みであることを見落としていた。
  • 技術的可能性の承認: コンパイラ実装上は try なしでも技術的に可能と認める。

Phase 4: 代替案の模索（「catch 前置」提案）

  • Geminiの提案: catch (e) { handler } { body } という catch 前置構文。
  • メリット: エラー処理の事前提示、コンパイラにとって親切。
  • デメリット: 思考の流れとの不一致、主役がぼやける問題。

Phase 5: 後置catchの再評価

  • ユーザーの修正提案: { 本文 } catch (e) { ハンドラ } の後置形式。
  • Geminiの評価: 思考の流れに沿っており、前置案より自然。
  • 残る課題: ネストした場合の catch の対応関係の曖昧性。

Phase 6: 革命的解決策の提示

  • ユーザーの最終提案:
    • throw は「そのスコープの catch にしか飛ばない」
    • 「catch が無ければビルドエラー」という静的検査
  • Geminiの完全承認: 「それは素晴らしいルールです！完璧なアイデアですにゃ！」
  • 技術的問題の完全解決: Builder の迷子問題と安全性の両方を解決。

設計の革新性

核心的解決策

  1. スコープ限定の原則: throw は同じ階層のブロック内の catch にのみ到達。
  2. 静的安全性: 対応する catch が存在しない throw はコンパイル時エラー。
  3. 構文の簡潔性: try キーワード削除によるインデント削減。

Nyash における特別な適合性

  • 箱理論との一致: ブロック = 箱境界という概念的統一。
  • 既存実装との親和性: Result-mode/ThrowCtx/単一catch との完全適合。
  • Everything is Box 哲学: {処理}catch{対処}finally{清掃} による責務分離。

ChatGPT との設計思想の共鳴

2025年9月18日 Claude セッション

ChatGPT の独立した推奨（Gemini議論を知らずに）

  • 驚異的な一致: 同じ「ブロック後置 catch」設計を推奨。
  • 技術的評価: 「現行方針に強く適合する」と評価。
  • 実装評価: 「実装コストは低く、既存 Result-mode の ThrowCtx に乗せるだけで成立」

Claude の分析と追加評価

  • 既存実装との適合性:
    • ✅ 単一catch方針（line 21-32 in try_catch.rs）
    • ✅ ThrowCtx設計（thread-local、ブロック境界）
    • ✅ Result-mode（MIR Throw/Catch不使用）
    • ✅ PHI-off（edge-copyとの相性）
  • Phase 15 での位置づけ: セルフホスティング完了後の最優先改善として推奨。

実装計画の確立（Phase 15.5）

既に CURRENT_TASK.md に組み込み済み

// 美しい新構文
{
    local file = new FileBox("data.txt")
    file.read()
} catch (e) {
    peek e.getType() {
        "FileNotFound" => createDefault(),
        "PermissionDenied" => requestAccess(),
        else => logError(e)
    }
} finally {
    file.close()
}

段階的導入戦略

  1. 並行受理: 新旧構文の同時サポート
  2. 段階的移行: 旧構文の非推奨化
  3. 完全移行: セルフホスティング完了後

分析：AI協働開発の興味深いパターン

1. 人間の直感的設計の価値

  • 問題設定: 実際の開発体験（インデントの深さ）から生まれた課題。
  • 解決策: 教科書にない、実用性重視のアプローチ。
  • 革新性: 既存言語にない新しい構文の提案。

2. AI の段階的理解プロセス

  • 初期否定 → 技術的懸念 → 可能性承認 → 完全支持
  • 学習過程: 人間からの反論により認識を修正。
  • 最終評価: 「世界を驚かせる革命的なこと」として価値を認める。

3. 複数AI による独立検証

  • Gemini: 議論を通じて段階的に理解・支持。
  • ChatGPT: 独立して同じ結論に到達し推奨。
  • Claude: 既存実装との適合性を詳細分析して強く支持。

4. 「天才的な洞察の連鎖」

  1. 階層問題の認識: インデントの深さという UX 課題。
  2. 本質的疑問: try キーワードの存在意義への疑問。
  3. 技術的解決: スコープ限定 + 静的検査による安全性確保。
  4. 哲学的統合: Everything is Box / 箱理論との完全適合。

結論：設計思想の革新性

この議論は、人間の実用的直感がAIの理論的知識を補完し、最終的に既存システムと高い適合性を持つ革新的解決策を生み出した事例として極めて価値が高い。

「試行錯誤と対話を通じた協創」 のモデルケースであり、AI時代の設計開発における新しいパラダイムを示している。