Skip to Content.
Sympa Menu

coq-club - Re: [Coq-Club] Reading material on "Program Fixpoint"

coq-club AT inria.fr

Subject: The Coq mailing list

List archive

Re: [Coq-Club] Reading material on "Program Fixpoint"


Chronological Thread 
  • From: Siddharth Bhat <siddu.druid AT gmail.com>
  • To: coq-club AT inria.fr
  • Subject: Re: [Coq-Club] Reading material on "Program Fixpoint"
  • Date: Mon, 22 Jan 2018 10:17:12 +0000
  • Authentication-results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=siddu.druid AT gmail.com; spf=Pass smtp.mailfrom=siddu.druid AT gmail.com; spf=None smtp.helo=postmaster AT mail-qt0-f176.google.com
  • Ironport-phdr: 9a23:a7lIgROgNbpIxb6xF1Ml6mtUPXoX/o7sNwtQ0KIMzox0Lf37rarrMEGX3/hxlliBBdydt6odzbKO+4nbGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1Ov71GonPhMiryuy+4ZLebxlViDanfb9+MAi9oBnMuMURnYZsMLs6xAHTontPdeRWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKHw65NfqtRbYUwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr0yRD+s7bpkSAXwhSgIOT428mHZhMJzgqxGvhyuuwdyzJTIbIyPLvdyYr/RcNEcSGFcXshRTStBAoakYoUSDuoOIPtXr4nnqFsUsRu+BRSnCf7vyjBSmn/9wKo30/8gEQ7bwQMgAsgCv2nOrNXoNacdTPu4zKbNzTrZbvNW3S3x55TPchAkuPyBW697f8nJyUQ3CQ/JklGdpZbmMj6VzOgBrXWX4ut6We6yiWMqqgd8qSW1yMg2kInGnIcVx0jE9SpnxIY1IsW1SEthbt6lFJtcrjiaN5dqTs87TWFkpSQ3x7wctZ60eygKz5snxxrBZPCdb4eI5RfjWP6QITd+mn1lZKqyiwiu/UWk0OHxVcm53ExUoiZYk9TArG0B2h7S58SfT/ty5Eah2TKB1wDJ7eFEJFg5lbHaK5E837Ewi4AfvlnZHi/rmUX5kbSbdkoh+uey6uTnZq/qqYObN49xkg3+KLghmtSjAeQkNQgDR3SU+eOl1LH64UL5RKhKgeYtn6nCsJHaINwbqbSjDw9U1IYj8Re/AC283NQWh3lUZG5CLRmAls3iP0zECPH+F/a2xVq2wxlxwPWTBbztDpXENGTD2J3hdKo1v1VdxAYui9xF+pNYIr4EKfP3HET2sYqLXVcCLwWozrO/W51G3YQEVDfXW/7LAObpqVaNo9kXDayJbY4Rtiz6LqF8tfHrhH4931QaePvwhMdFWDWDBv1jZn6hTz/0mN5YSDUFuwM/SKrhj1jQCWcONUb3ZLo143QAMKzjDYrHQdrz0rmI3SP+B4EOI24fVQ7KHnDveIGJHfwLbXDKLw==

That is interesting information, thank you.

When one uses Program, what happens to the proof obligations one provides? Do those "leak out" as well? (The impression I got from some cursory use is that it does not). If not, how does that work?

I left trying to dependent type my code for a while now, because I don't deally understand how to control proof terms with dependent types.

Cheers
Siddharth


On Mon 22 Jan, 2018, 15:03 Théo Zimmermann, <theo.zimmi AT gmail.com> wrote:
There are on-going debates whether programming definitions using tactics is OK or not but what is agreed on is that building transparent terms (definitions) using automated tactics is not a good idea (you should have a clear idea of what the tactic is doing).

When you want to use an automated tactic to prove a proof obligation as part of a definition, you may encapsulate it into "abstract" to make this part of the term opaque :

Require Import Omega.

Definition positive : { n : nat | n > 0 }.
  exists 1.
  abstract omega.
Defined.

Compute proj1_sig positive. (* 1 *)

About positive. (* ... positive is transparent *)

Print positive.
(* positive =
    exist (fun n : nat => n > 0) 1 positive_subproof
     : {n : nat | n > 0} *)

About positive_subproof.
(* positive_subproof : 1 > 0
    positive_subproof is opaque *)

That being said, I'm not aware of any clear advantage of this method over using Program.

Théo

Le sam. 20 janv. 2018 à 14:27, Siddharth Bhat <siddu.druid AT gmail.com> a écrit :
I've been trying to learn how to write dependently typed code in Coq.

As far as I can tell, there are three styles:
1. Use tactics to fill in Definition blocks.
2. Directly "implement" stuff with dependent types (like Idris)
3. Use Program to delay obligations, so write "normal" code and fulfil obligations later.

The problem I face with #1 is that _proving_ things about Definitions encoded this way is impossible for me. For example, if I use omega in some Definition D, I cannot prove anything about D, because on unfolding D, I see the mess that is the omega implementation, I assume.

So, for proving things about definitions, #1 is out.

#2 is.. challenging, and as a newbie, I find that I often do not know how to express the things I want to say, or do not know how to convince Coq that certain things are impossible (eg: safe indexing into a vector)

So, for now, #3 seems easiest.

I would like references on the third style of implementing things. Could someone please recommend reading material?

Thanks,
Siddharth


--
Sending this from my phone, please excuse any typos!
--
Sending this from my phone, please excuse any typos!



Archive powered by MHonArc 2.6.18.

Top of Page