abstract / elaborate

a.txt

  不改的壞處(全是工程債,無 soundness)

  1. 渲染邏輯被迫雙份維護(最實際的成本)
  Abstract 和 Typed 各有一份幾乎平行的 handleExpr(Render Expr),Pretty 也各一套。任何「表達式怎麼顯示」的調整要改兩處,且容易
  drift——現在兩份已有細微差異。

  2. 拔不掉 Abstract render/pretty cluster(你的原始目標被擋住)
  Render Expr/Chain/CaseClause/Interval/... 一整包得留著,純粹因為 array bound 還是 Abstract.Expr。死重量。

  3. 心智模型是假的,會誤導人
  「elaborate 之後都是 Typed」是錯的——Typed AST 裡有 Abstract.Expr 孤島(array bound)。你這次花了很長時間才釐清;下一個人若寫了「Typed.Program ⇒ 全
  Typed.Expr」的假設,就會踩坑。屬於認知/onboarding 成本。

  4. bound 沒有型別資訊(輕度)
  validateEndpoint 用 void (typeCheck ...),檢查完把 typed 結果丟了。將來若有功能想拿 bound 的型別/elaborated 形式(更精細的 array index WP 推理、hover
  顯示 bound 型別、化簡 bound),都得重做一次。目前沒有這種需求,所以只是「未來可能」。

  5. 一個 cosmetic 角落(極少觸發,且非 soundness)
  term-level substitution 不會遞迴進型別標注。所以若 array 邊界引用了會被代換的可變 var(如 var n; var a : array [0..n)),代換後型別標注裡的 n
  不會更新,顯示時可能走味。但:慣例邊界都是 con(常數),且要那個型別真的被 render 才看得到,還純粹是顯示問題。

  一張表

  ┌──────────────────────────────┬──────────────┬───────────────────────┐
  │             壞處             │    嚴重度    │   會不會出錯的結果?   │
  ├──────────────────────────────┼──────────────┼───────────────────────┤
  │ render/pretty 雙份維護       │ 中(持續)     │ 不會,但煩             │
  ├──────────────────────────────┼──────────────┼───────────────────────┤
  │ 拔不掉 Abstract cluster      │ 低–中        │ 不會,死碼             │
  ├──────────────────────────────┼──────────────┼───────────────────────┤
  │ 「假裝全 Typed」認知陷阱     │ 中           │ 不會,但易誤導         │
  ├──────────────────────────────┼──────────────┼───────────────────────┤
  │ bound 無型別資訊             │ 低(未來才痛) │ 不會                  │
  ├──────────────────────────────┼──────────────┼───────────────────────┤
  │ var-dependent bound 顯示走味 │ 極低         │ 顯示走味,非 soundness │
  └──────────────────────────────┴──────────────┴───────────────────────┘

  一句話

  ▎ 不改,不會有任何正確性問題;代價純粹是「兩份渲染碼的維護債 + 拔不掉那包 Abstract cluster + 『elaborate 後全是
  ▎ Typed』這個會誤導人的假象」,外加一個幾乎碰不到的顯示走味角落。所以這是「要不要還技術債」的取捨,而不是「有 bug
  ▎ 要修」。近期若沒有相關需求,延後完全合理。