Open BoltonBailey opened 1 year ago
Hello @BoltonBailey Nice list. I like the idea of a formatter that can run automatically and get rid of the small pesky annoyances during review. I am however not optimistic about such a formatter working in Lean4. This is based on the following observation:
Here is a list I collected from comments on a PR a while ago:
(A: Type)
to (A : Type)
(A:Type )
to (A : Type)
... etc.(A : Type)(B : Type)
becomes (A : Type) (B : Type)
def myMatrix(m n : Nat): Matrix (Fin m) (Fin n) Nat
becomes def myMatrix (m n : Nat) : Matrix (Fin m) (Fin n) Nat
\.
B⬝A
becomes B ⬝ A
The second to last item in your current list is "Non-terminal simp". My understanding is a terminal simp
is a simp
without only
and possibly a list of lemmas. If my understanding of this term is correct, then I have a data point against this being something a linter or formatter should warn against.
See this https://github.com/leanprover-community/mathlib4/pull/6052#discussion_r1281812334
@MohanadAhmed A "terminal" simp means a simp at the end of a tactic block. The example in that comment is of a terminal simp. So the linter warning would be for a simp
without only
, which is followed by more tactics rather than being the last tactic in a sequence. There are exceptions for this too, for example maybe simp; simp
or simp; ring
is okay, but the allowed exceptions could presumably be added to the linter.
@digama0 Thanks for the correction.
I am curios what is your opinion on how feasible is it to make a formatter in Lean code that runs almost instantly (say like javascript or similar in VSCode) ? Is it reasonable to expect Lean in the near future to instantly parse and reformat say 300 line file?
Significant architectural changes are required to make a formatter which runs faster than lake build
. See https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/quick.20and.20dirty.20mode for context.
I am compiling a list of things we might like our linter / possible future code formatters / reviewdog to detect/correct/comment on. Feel free to add to this list, or augment items with related issues.
Linters
Style Guide Items
:
and:=
and infix operators:
and:=
go before linebreaks.:
,:=
by
is placed on the line prior to the first tactic↦
preferred to=>
(only slightly)λ
disallowed in favor offun
Items not in the style guide which might nevertheless be nice
simp
(calls to simp that do not close the goal) should be replaced withsimp?
output.simp at
andsimp [...]
calls should be linted as well.variables
keyword in the file when possible.Shake
)<-
to←
.rw
/simp only
into one call, when this doesn't affect proof readability.simp
/simp only
withsimp_rw
where possible/not too verbose, so that readers can use their cursor to inspect the effect of each step.rw
with unspecified arguments, this makes the proof harder to read.variable {α : Type*}
at the top of the file, and then the same declaration again below.(∀ i, α i)
or((i : X) -> α i)
according to whether theα i
values areProp
ssimp only
calls don't use unnecessary lemmasFormatters
A formatter does not exist yet, but when it does, the above issues should be revisited.
(Thanks to Floris, @MohanadAhmed, Sebastien Gouezel for contributing points)