Skip to content

[Umbrella] Explicit-g cascade: drop [HasMetric I M] auto-resolution from Riemannian stack #9

@Xinze-Li-Moqian

Description

@Xinze-Li-Moqian

Goal

Replace the [hm : HasMetric I M] typeclass auto-resolution + _g-style notation dispatch with explicit-g, method-call style throughout the Riemannian stack. The Riemannian metric g becomes a first-class Lean term in every signature; _g notations (which are currently just string suffixes hiding HasMetric.metric) are deleted in favour of g.metricInner, g.ricciTensor, etc.

End-state target (BG illustration):

theorem bishopGromov_volume_comparison
    (g : RiemannianMetric I M)
    (hRic : ∀ x v, ((n_M : ℝ) - 1) * K * g.metricInner x v v ≤ g.ricciTensor x v v)
    (p : M) ... :
    dV_g[g].real B(p, R) / V_K^n_M(R) ≤ dV_g[g].real B(p, r) / V_K^n_M(r)

Sub-issues (sequential, each session-sized)

Phased invariant

Throughout 9a–9e, the `_g`-style scoped notations are kept temporarily as a backward-compat layer that auto-fills `HasMetric.metric`. This lets each sub-issue's commit produce a green build with no API-surface break to downstream that hasn't migrated yet. 9f deletes the notation layer in one final atomic commit, completing the Mathlib-idiom transition.

Total scope

~1150 LOC across 17 files. Sequenced as 6 sub-PRs over multiple sessions, each one passing CI cleanly.

Foundation already in place

  • Metric/RiemannianMetric.lean already explicit-g (commit 6312583).
  • g.metricInner, g.metricNormSq, g.metricInnerSection, g.metricNormSqSection, g.metricRiesz all live as method-call APIs on g : RiemannianMetric I M.

Why it matters

The current _g suffix is misleading — it suggests g is a parameter, but g is hidden behind typeclass HasMetric.metric. Multiple metrics on the same manifold cannot coexist in a signature. BG's signature was forced into dV_g[(HasMetric.metric : RiemannianMetric I M)] workaround. The refactor removes this ambiguity at the foundation.

Metadata

Metadata

Labels

architectureDesign / module organization changesmathMathematical content / proof workrefactorCode restructuring / reorganization

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions