Zulip Chat Archive

Stream: PR reviews

Topic: lean#770


Kyle Miller (Sep 26 2022 at 13:54):

This PR is a possible improvement to the Lean pretty printer. I'm not sure if it will be merged, but it seems like it's worth thinking about. The PR came from some experimentation after a question by @Dan Velleman in this topic about Lean 4's pretty printing rules for foralls.

The basic motivation is that it is occasionally (and pedagogically) surprising when a non-dependent forall switches from being pretty printed with the forall notation to using the function arrow. Foralls are fairly special as far as pi types go. Recall that if A : Sort u and B : A → Sort v then

Π (a : A), B a : Sort (imax u v)

If v is 0 then this is ∀ (a : A), B a : Prop, but if v is nonzero then this is Π (a : A), B a : Sort (max u v) (definitely not a Prop).

The current pretty printing rules are that if B is non-dependent (say B : Sort v), then Π (a : A), B pretty prints as A → B in both cases. An observation is that the "surprising" case is when v is zero and u is nonzero, since A → B : Prop but A is not a proposition.

What this PR does is cause the pretty printer to show ∀ (_ : A), B in this case, to let the user know that this is a pi type in Prop with a non-Prop binder. The _ indicates that this is a non-dependent forall, so pretty printing this way provides strictly more information to the user than before. Prop-to-prop implications still pretty print as A → B.

Furthermore, since it was simpler to implement this way, the PR has the pretty printer replace non-dependent binders in pi types with _ in general, for instance Π {_ : ℕ}, ℤ rather than Π {n : ℕ}, ℤ (but still ℕ → ℤ rather than Π (n : ℕ), ℤ for non-dependent explicit binders). It seems to be more useful to know that a pi is non-dependent than to know the name of the binder.

Johan Commelin (Sep 27 2022 at 02:57):

Sounds great to me

Kyle Miller (Sep 27 2022 at 14:17):

Are there any Lean 3 -> Lean 4 concerns with this change?

Mario Carneiro (Sep 27 2022 at 18:04):

It's a bit different from the lean 4 heuristic, which was most recently changed in https://github.com/ydewit/lean4/commit/85925535b0e22e430b8f72c8cdf456a8575e4103

Mario Carneiro (Sep 27 2022 at 18:05):

I think this needs to go through an issue or RFC on the lean 4 side

Kyle Miller (Sep 27 2022 at 18:20):

@Mario Carneiro Could you clarify what you mean? That this should not be merged unless something similar is accepted in Lean 4?

Mario Carneiro (Sep 27 2022 at 18:21):

no, I think it's independent, but we should try to make them align

Mario Carneiro (Sep 27 2022 at 18:22):

I don't see any issues with merging this PR now at least on the design side

Kyle Miller (Sep 27 2022 at 18:23):

Thanks, yeah I'll submit a Lean 4 RFC

Eric Wieser (Nov 15 2022 at 09:24):

What's the status of this? Are we waiting on an RFC, or is this good to merge (once CI is happy with my conflict resolution)?

Kyle Miller (Nov 15 2022 at 10:45):

I've created an RFC: lean4#1834


Last updated: Dec 20 2023 at 11:08 UTC