Skip to Content.
Sympa Menu

coq-club - Re: [Coq-Club] Lean Theorem Prover

coq-club AT inria.fr

Subject: The Coq mailing list

List archive

Re: [Coq-Club] Lean Theorem Prover


Chronological Thread 
  • From: Abhishek Anand <abhishek.anand.iitg AT gmail.com>
  • To: coq-club <coq-club AT inria.fr>
  • Subject: Re: [Coq-Club] Lean Theorem Prover
  • Date: Thu, 25 Feb 2016 17:46:05 -0500
  • Authentication-results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=abhishek.anand.iitg AT gmail.com; spf=Pass smtp.mailfrom=abhishek.anand.iitg AT gmail.com; spf=None smtp.helo=postmaster AT mail-yk0-f176.google.com
  • Ironport-phdr: 9a23:Z/ZN1BbfTC4/sQAuC7+fkZz/LSx+4OfEezUN459isYplN5qZpcmybnLW6fgltlLVR4KTs6sC0LqJ9f66EjRcqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7/0pceYO1kArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIYTGZn9Kq8/VPlTCCksezQ+49Suvh3eRyOO4GEdWyMYiEwbLRLC6UTTVJfwqSv3taJU3iCcMYWiRLo0WC+i4qQtQRnhjitBNj8l/0nYj8VxiORQpxf39E83+JLdfIzAbKk2RajaZ95PHWc=

MathClasses has something similar, which I like a lot:

http://www.cs.cornell.edu/~aa755/ROSCoq/coqdoc/MathClasses.misc.decision.html




On Thu, Feb 25, 2016 at 5:39 PM, Daniel Schepler <dschepler AT gmail.com> wrote:
On Wed, Feb 24, 2016 at 4:17 PM, Saulo Araujo <saulo2 AT gmail.com> wrote:
> Hi,
>
> I recently discovered the Lean Theorem Prover
> (https://leanprover.github.io/about/). I did some toy experiments with it
> and and, at least in this first contact, it seemed similar to Coq. I am
> curious about how the Coq community sees Lean. Does it see Lean as
> "competitor" of Coq? Is it possible for Coq to bridge the gap betweem
> interactive and automated theorem proving like Lean aims to do?

One thing I did notice in my quick browse through the tutorial: its
standard library includes a typeclass for decision procedures for
propositions (though I'd call it Decision instead of decidable as Lean
does, as the last suggests the proposition (P \/ ~P) rather than
something with extractable information).  It also includes a notation
for defining a proof by inferring a decision procedure and then
running it.

This is something I've thought of proposing as an addition to the Coq
standard library at various times - and I might even have mentioned
some elements of my thinking in some previous messages to the list.
So, the basic outline would be something like:

Class Decision (P:Prop) : Set :=
decide : {P} + {~P}.

Arguments decide P [Decision].

Instance true_dec : Decision True := left _ I.
Instance and_dec {P Q:Prop}
  `{!Decision P} `{!Decision Q} : Decision (P /\ Q) := ...
...
Instance bounded_nat_dec {P : nat -> Prop}
  `{!forall m:nat, Decision (P m)}
  (n : nat) : Decision (forall m:nat, m < n -> P m) :=
fix ...
Instance Forall_dec {A:Type} {P : A -> Type}
  `{!forall x:A, Decision (P x)}
  (l : list A) : Decision (Forall P l) :=
fix ...
...

Ltac decide :=  (* untested *)
match goal with
|- ?P =>
  let dec := hnf (decide P) in
  match dec with
  | left _ ?pf => exact pf
  | right _ _ => error 2 "statement is false"
  | _ => error 2 "could not evaluate decision procedure"
  end
end.
Notation decision_pf := ltac:(decide).

Example my_max (m n:nat) : nat :=
if decide (m <= n) then n else m.

Maybe it could also include some framework for enumerating all
elements of finite types, which would be useful for things like
Definition bor_assoc (x y z:bool) :
  bor x (bor y z) = bor (bor x y) z := decision_pf.
--
Daniel Schepler




Archive powered by MHonArc 2.6.18.

Top of Page