tomoaki/hakorune
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
34be7d2d797d840cc33d7c1e21abb042f3e2100e
hakorune/docs/private/research/papers-active/nyash-box-first-language/design-insights/2025-09-27-method-resolution-deep-dive.md
nyash-codex 34be7d2d79 vm/router: minimal special-method extension (equals/1); toString mapping kept 
mir: add TypeCertainty to Callee::Method (diagnostic only); plumb through builder/JSON/printer; backends ignore behaviorally

using: confirm unified prelude resolver entry for all runner modes

docs: update Callee architecture with certainty; update call-instructions; CURRENT_TASK note

tests: quick 40/40 PASS; integration (LLVM) 17/17 PASS
2025-09-28 01:33:58 +09:00

8.8 KiB
Raw Blame History

メソッド解決の深堀り - ユーザーBoxメソッドの実装挑戦

日付: 2025-09-27 コンテキスト: Phase 15完了間近、HN投稿準備中 参加者: ユーザー + Claude + ChatGPT5 Pro

📋 会話のきっかけ

ユーザーからの質問：

"instance boxcallが フォールバックであってるかな？ usingの時に解決、動的に解決、まずこのパターンであってますかにゃ？"

→ これがNyashの設計の核心を明らかにする会話に発展

🎯 Nyash名前解決の二本立て設計

静的解決（using時）

  • 対象: ユーザー定義Box、prelude
  • タイミング: ビルド時
  • 方式: 関数化（materialize）
  • prod設定: nyash.toml経由のみ、file-using禁止

動的解決（ランタイム）

  • 対象: プラグインBox、Extern/HostCall
  • タイミング: 実行時
  • 方式: ディスパッチ
  • prod設定: プラグイン動的OK、ユーザーInstance BoxCall禁止

🔥 「一番難しいところ」の正体

なぜ難しいのか

  1. 複数レイヤーにまたがる

    • パーサー → MIRビルダー → MIR表現 → VM実行 → プラグイン
    • どの層でも取りこぼしが起きる可能性

  2. 静的 vs 動的の境界があいまい

    • プラグインBox（動的でOK）
    • ユーザーBox（静的に変換すべき）
    • でも実装上は両方とも BoxCall 命令
    • 見分けるのが難しい

  3. 既存コードとの互換性

    • 破壊的変更ができない
    • 全部動かし続けながら改善

  4. 取りこぼしパターンが10種類

    • プレリュード関数化漏れ
    • static/instanceフラグ誤り
    • 宣言パース逸脱
    • Stage/構文ゲート干渉
    • 名前/アリティ不一致
    • クラス名推定失敗
    • 名前衝突/誤一致
    • 依存解決の取り違い
    • 生成順序の問題
    • birth/コンストラクタ経路副作用

💎 ChatGPT5 Pro の客観評価

総評

✅ "かなり凄い（学術的にも新規性あり）"
⚠️ "実装コストと運用負荷が高い"

何が「普通じゃない」か

  1. Operator-as-Box の徹底

    • すべての演算を OperatorBox.apply に一本化
    • Smalltalkの"演算子＝メッセージ"を超えて、演算子を実体（Box）として持つ
    • 観測・差し替え・委譲・最適化を1箇所で制御

  2. 静的（rewrite）と動的（BoxCall）の透過統合

    • obj.m() が ユーザーBoxなら関数化、プラグインはBoxCall
    • dev/prod でのフォールバック/禁止をきめ細かく切替可能

  3. LoopForm 正規化＋Pin/PHI

    • preheader→header(φ)→body→latch→exit に正規化
    • 支配関係バグの位置特定を容易化
    • pin（slot化）で未定義参照を構造で潰す

技術的難易度比較

言語 低レベル制御 動的解決 静的最適化 複雑性
C ✅✅✅ ❌ ✅（手動） 低（シンプル）
Python ❌ ✅✅✅ ❌ 低（シンプル）
Rust ✅✅ ❌ ✅✅✅ 中（明示的）
Nyash ✅✅（C FFI） ✅✅（Plugin） ✅✅（rewrite） 超高

客観的結論: Nyashは異常に高度なことをしている

🎨 設計の本質 - 小さなルールの合成

ChatGPT5 Pro の洞察：

"シンプルなルールの合成が大きな力を生んだ典型例"

6つの小さなルール

  1. Everything is Box → 呼び出しを全部Box化
  2. Call は 1形 + Callee → 全呼び出しが同一メカニズム
  3. Loop-Form + Pin/PHI → 構造的バグ防止
  4. SSOT + rewrite → 静的・動的の透過統合
  5. NyABI + 再入ガード → 安全性と性能両立
  6. フラグ・メトリクス・検証 → 安全な進化

合成の魔法

C++風の箱
  +
単一呼び出しモデル
  +
SSAの形
  +
SSOT
  =
（静的×動的×演算子）全部ひとつの箱に！

✅ 採用判断（ChatGPT5 Pro推奨）

機能 判定 条件
Operator-as-Box ✅ 採用推奨（既定ON） 3ガード同時運用
instance→function rewrite ✅ 採用推奨（prod含む） 既定ON、解決不能時エラー
LoopForm正規化+Pin/PHI ✅ 採用必須 VM_VERIFY_MIR常時
NewBox→birth不変条件 ✅ 採用必須 Builder verify + VM assert
stringify(Void)→"null" ⚠️ 暫定採用 WARN+カウンタ、0継続でOFF
heavy スモークプローブ ✅ 採用 末尾"ok"厳密比較

3ガード（Operator-as-Box の条件）

  1. 再入ガード: 同演算子の自己再帰 → NyABI直行
  2. フォールバック: 型未対応/例外時 → 従来実装 + 計測
  3. 二重置換抑止: Operator実装内では演算子糖衣展開しない

🚀 運用・ロールアウト指針

段階的展開

Phase 1: dev 既定ON
  ↓
Phase 2: quick/integration 安定
  ↓
Phase 3: prod 段階ON
  ├─ まず Compare
  ├─ 次に Add
  └─ その他

メトリクス基準

✅ fallback率 == 0%
✅ 再入ガード発火 == 0
✅ birth_me_void_hits == 0

継続期間: 数日間
性能: ±10%以内

📚 研究/論文としての価値

新規性

  • Operator-as-Box の徹底
  • 静的/動的統一
  • LoopForm + Pin による SSA安定化

実証

  • JSON VM ライン差分ゼロPASS
  • 段階採用の運用モデル
  • 回避策の計測

比較対象

  • Smalltalk（演算子=メッセージ）
  • Haskell（型クラス）
  • 一般的JIT/VM

📋 最小チェックリスト（運用可能な品質へ）

  • OperatorBox: 再入ガード + フォールバック + 二重置換抑止
  • Builder: instance→function rewrite 既定ON（曖昧時エラー）
  • VM: user Instance BoxCall 原則禁止（dev のみフォールバック）
  • LoopForm: φ検証・diamond正規化・pin徹底
  • NewBox→birth: Builder verify + VM assert
  • stringify(Void): 暫定安全弁（WARN+カウンタ）
  • heavy プローブ: 末尾"ok"厳密比較
  • メトリクス: fallback率/guard発火/birth_me_void をCI可視化

💡 ChatGPT5 Pro 最終コメント

凄いか？ → 設計として新しく、十分"凄い" 普通か？ → 実務でここまで統一する例は少なく、普通ではない やる価値？ → Yes。ただし不変条件・検証・フォールバックを同時に入れて"運用可能"にすることが鍵

結論: この方針なら、正しさ→既定ON→痩せ の順で、特級の完成度に届くはず

🎯 一週間攻略プラン

Day 1-2: 可視化・診断強化

  • ビルダーデバッグログ強化
  • materialize検出WARN追加
  • MIRダンプの改善

Day 3-4: 最優先取りこぼし対策

  • プレリュード関数化を徹底
  • instance/static 両方を関数化
  • user_defined_boxes に確実登録

Day 5: クラス名推定強化

  • annotate_call_result_from_func_name の適用域拡大
  • PHI命令に value_origin_newbox 伝播
  • 関数戻り値の型タグ保持

Day 6: テスト・検証

  • method_resolution_is_eof_vm (prod+AST版)
  • quick profile 全PASS確認
  • integration profile 全PASS確認

Day 7: ドキュメント化・まとめ

  • docs/design/using-and-dispatch.md 完成
  • docs/design/method-resolution.md 追加
  • 論文用の技術メモ作成

🎉 重要な気づき

この会話で明らかになったこと：

  1. Nyashは最高難度の実装に挑戦している

    • 低レベル（C FFI）+ 動的（プラグイン）+ 静的（rewrite）の統合
    • 他の言語でも稀な組み合わせ

  2. でも「魔法」ではない

    • 小さな不変条件の積み重ね
    • シンプルなルールの合成効果

  3. 「一番難しいところ」は正しい認識

    • メソッド解決は言語実装の最難関の一つ
    • Rust/Swift と同じレベルの問題

  4. 一週間で詰められる理由

    • 問題が特定されている
    • 解決策がある（ChatGPTロードマップ）
    • AI協働が機能している

  5. ChatGPT5 Proのお墨付き

    • 学術的新規性あり
    • 特級の完成度に届く可能性
    • でも丁寧な実装が必須

📝 関連ドキュメント

保存日: 2025-09-27 ステータス: 実装準備完了、一週間攻略開始