Live data from Hacker News

Are We Stuck with Lean?

mathoverflow.net

11–20 of 73 posts

Re: Are We Stuck with Lean?

#11
Recent posts on formal proofs usually talk about Lean, Rocq, Isabelle and (due to this post) Metamath.

What do people think of F* [1]? At least, for non-mathematics projects, doesn't it seem to be a more appropriate option [2]? It seems even the CS community is gravitating towards Lean.

[1] https://fstar-lang.org/

[2] https://fstarlang.github.io/lowstar/html/Introduction.html

Re: Are We Stuck with Lean?

#12

I find it really strange that people who don't use lean don't just get on and use the alternatives rather that trying to get everyone who is using lean to use something else. It feels exactly like if all the emacs users in the world tried to force all vim users to use emacs. It's important to meet reality head on: Every mathematician is not going to collaborate on the same tooling (as wonderful as that might seem on…

Agreed. In addition I think a big reason why we are discussing formalization so much at the moment is that it has only recently become viable to do large scale formalization of mainstream mathematics, using LLMs. These same LLMs will make it much easier to translate from one language to another and port even larger codebases over.

My prediction would therefore be that the LLMs will let us work more-or-less using standard mathematical prose that then gets to codified to some machine-readable and checkable language, but what the language used by the proof checker actually is will be more of a technical detail. In particular, I suspect people will not care too much about the language used for proofs themselves, which means that we might allow for more boilerplate if it is faster to elaborate/compile, unlike current interactive theorem provers which are meant to ease the work of humans. How the language looks like for the statements of the theorems and definitions is probably more important however, since humans will want still to be able to check that what is being formalized corresponds to what they had in mind.

Re: Are We Stuck with Lean?

#13

Reminds me of the idea of Radical Monopolies from Ivan Illich in a way. If a technology or service becomes so wide spread within society, even though many different versions of the technology or service may exist, a Radical Monopoly means that non users will suffer for their non use. Cars and non drivers in cities are the typical example. And I wonder, whether mathematicians who don't user theorem provers will soon s…

> Cars and non drivers in cities are the typical example.

Have a look at Dutch cities for how to avoid this.

Re: Are We Stuck with Lean?

#14
post #3

> Metamath is based on set theory, and would therefore address some concerns one might have with the propositions-as-types philosophy used by Lean Isn't the entire point mathematicians adopted Lean where they spurned Haskell is because of the batteries-included ZFC object language in the former? Metamath implements a set theory object language just the same, it's not based on it at all in this sense. You just changed…

I don't think Haskell would have been useful anyway? You'd want a dependently typed language for this, not Haskell. Haskell's types can't really express anything non-trivial.

Re: Are We Stuck with Lean?

#15

I find it really strange that people who don't use lean don't just get on and use the alternatives rather that trying to get everyone who is using lean to use something else. It feels exactly like if all the emacs users in the world tried to force all vim users to use emacs. It's important to meet reality head on: Every mathematician is not going to collaborate on the same tooling (as wonderful as that might seem on…

I think it’s a lot like R vs SAS or Python and not any departure from the norm.

Mathematicians are not highly technical users that generally like programming. If you give them a path of importing someone else’s work they’ll do that instead of redoing it in their theorem prover of choice.

See the old mathematician joke:

A mathematician is asked to make tea. They take the kettle from the shelf, fill it with water, put it on the stove, turn on the heat and boil the water, then pour it into a cup.

The next day someone asks the mathematician to make tea again. The kettle is still on the stove from yesterday and there’s some leftover water in it, enough for tea.

The mathematician dumps the kettle out and puts the it away on the shelf. The mathematician says the system is in a known previously solved state and therefore trivially solved.

Now substitute 1500 lines of coq or lean for the kettle. As far as I know the outputs aren’t interchangeable like a vim or eMacs text file.

Re: Are We Stuck with Lean?

#17
post #13

Reminds me of the idea of Radical Monopolies from Ivan Illich in a way. If a technology or service becomes so wide spread within society, even though many different versions of the technology or service may exist, a Radical Monopoly means that non users will suffer for their non use. Cars and non drivers in cities are the typical example. And I wonder, whether mathematicians who don't user theorem provers will soon s…

> Cars and non drivers in cities are the typical example. Have a look at Dutch cities for how to avoid this.

I immediately thought that’s not totally fair due to the size of the Netherlands vs other countries.

I asked Mistral to do an analysis: nearly zero R^2 for car ownership vs log country area, and it’s the same with proportion of urban population in OECD countries.

Netherlands isn’t very different from peers in car ownership, they just treat cyclists very well it seems.

This is a total tangent, just found it interesting.

Re: Are We Stuck with Lean?

#19

I find it really strange that people who don't use lean don't just get on and use the alternatives rather that trying to get everyone who is using lean to use something else. It feels exactly like if all the emacs users in the world tried to force all vim users to use emacs. It's important to meet reality head on: Every mathematician is not going to collaborate on the same tooling (as wonderful as that might seem on…

Agreed. In addition I think a big reason why we are discussing formalization so much at the moment is that it has only recently become viable to do large scale formalization of mainstream mathematics, using LLMs. These same LLMs will make it much easier to translate from one language to another and port even larger codebases over. My prediction would therefore be that the LLMs will let us work more-or-less using stan…

This is horseshit. Mathlib3 and mathlib4 all existed prior to LLMs. Unimath of Agda, mathematical components of Rocq, the list goes on.

LLMs have done nothing for "making large scale mechanization viable." They have been viable. The only thing has changed is the perception of the random developer who never wanted to put the effort into learning what actually needed to be learned and are instead happy to spit our complete garbage, spec and all, and say it's a proof of something.

It's not shocking at all that the people who seem to get any benefit out of LLMs in the proof assistant space are the ones who could have just don't it themselves anyway.

Re: Are We Stuck with Lean?

#20

Metamath's Python verifier - its trusted kernel - is just 700 lines of Python short: https://github.com/david-a-wheeler/mmverify.py/blob/master/m... Metamath Zero's Haskell implementation 700, and the C implementation 1000 lines (or 1800 overall) https://github.com/digama0/mm0 How do other proof systems compare? Some bug counts: https://tristan.st/blog/in_search_of_falsehood

My favorite minimalistic example of the Metamath base language (which higher level languages can compile down to), which, saved as, say, prop.mm can be verified with the verifier:

  $c  wff  $.        $( we use this $constant as a type of formula (well formed formula) $)
  $c  ( ) ! ->  $.   $( brackets, negation, implication $)

  $v  A B C  $.      $( $variables to be used in formulas $)

  wa  $f  wff A  $.  $( $floating hypothesis "wa" which says, that A is a well-formed formula $)
  wb  $f  wff B  $.
  wc  $f  wff C  $.

  $( The following assertions define the rules to create formulas $)
  $( In Metamath (unlike Metamath Zero), definitions also use the $axiom statement type $)
  wng  $a wff ! A $.           $( "not A is a well-formed-formula" - mandatory hypotheses are (wa) $)
  wim  $a wff ( A -> B ) $.    $( "A implies B is a well-formed-formula" - mandatory hypotheses are (wa, wb) $)

  $c  |-  $.         $( this $constant will be used as a type of provable formula  $)

  $( Schemes of $axioms of propositional logic $)
  a1  $a |- ( A -> ( B -> A ) ) $.
  a2  $a |- (    ( A -> ( B -> C ) )   ->    ( ( A -> B ) -> ( A -> C ) )    ) $.
  a3  $a |- ( ( ! A -> ! B )  ->  ( B -> A ) ) $.  

  $( Definition of the Modus Ponens rule of inference in new scope; otherwise $essential hypotheses (inputs) mp1, mp2 will become mandatory for all upcoming assertions $)
  ${
      mp1 $e |- A $.                
      mp2 $e |- ( A -> B ) $.
      mp  $a |- B $.               $( mandatory hypotheses of "mp" are (wa, wb, mp1, mp2) $)
  $}

  $( A $proof states the string of symbols to be proven, followed by a list of labels used by the stack machine $)
  $( $floating and $essential hypotheses are pushed onto the top of the stack, $axioms and $proofs transform it by using the top of the stack as inputs $)
  $( When the stack is empty at the end, the proof is successful, and the proved statement can be reused in further proofs using its label $)

  $( " A implies ( B implies C) is a well-formed-formula" $)
  formula1 $p  wff ( A -> ( B -> C ) )  $= wa wb wc wim wim $.

  $( "( A -> A ) -> ( A -> A ) is true (follows from the axioms)" $)
  formula2 $p  |- ( ( A -> A ) -> ( A -> A ) )  $= wa wa wa wim wim    
                                                   wa wa wim wa wa wim  wim  
                                                   wa wa a1    
                                                   wa wa wa a2    
                                                   mp  $.
Post reply on HN