Skip to Content.
Sympa Menu

coq-club - Re: [Coq-Club] Re: Simple example

coq-club AT inria.fr

Subject: The Coq mailing list

List archive

Re: [Coq-Club] Re: Simple example


chronological Thread 
  • From: Adam Koprowski <adam.koprowski AT gmail.com>
  • To: coq-club AT pauillac.inria.fr
  • Cc: adamc AT hcoop.net
  • Subject: Re: [Coq-Club] Re: Simple example
  • Date: Sun, 22 Feb 2009 16:50:47 +0100
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Cm+xaUW99Dxk9a0GMQ1cNbr68XwdyHifzZGyhn+X1otpixZEUI/mHCN+q7G1gnF54y 8Em3BYDPLA7Rbc2P0+LYg7MiMdLiK8AgmlxmgWJjQiYBn71qtlPQl9f8MekHssotAWtr t4kdU8z/n7R6o0nT3hlMuI71JDTcy2m1g6x1c=
  • List-archive: <http://pauillac.inria.fr/pipermail/coq-club/>


Adam Koprowski wrote:
>   ... or if you are not a huge fun of 'refine' and you don't like to
> define things by means of tactics, then the new Program feature of Coq
> is your friend. You can define your function in pretty much the same
> way as you'd do in some functional programming language and then you
> can prove properties about this function; and the two steps are nicely
> coupled together with Program (see solution below, which gives exactly
> the same program as the previous solution but I think the definitions
> & proofs are cleaner; although that's always a matter of taste).

"Program" is a useful feature, but I think a lot of Coq users (and
potential users) have gotten a very inaccurate idea of what it
provides.  It may be discomfiting at first to build a program using the
[refine] tactic, but there is really no practical difference between
that style and the style of [Program].  [Program] provides some new
features that [refine] doesn't, but, for instance, your example of
[is_prefix_dec] uses just one of those features, which lets you avoid
annotations on dependent [match]es.  A little extra verbosity (of the
easy-to-write-and-follow kind) makes up for that in the implementation I
sent to the list earlier, and I believe 8.2 is doing some new [match]
annotation inference that either now or in future iterations will remove
this advantage altogether.
  Still I completely miss why would Program be any inferior to refine for such examples, which you seem to be implicitly claiming. Your solution, using your proof-in-one-go style, can be similarly expressed using Program (see attached script) resulting in a cleaner, shorter script. And I think that using Program merely as a substitute for refine (without using more advanced features of Program), already takes the advantage of the Program syntax (equivalent of the syntax of "normal" definitions), which nicely separates the definition (skeleton) and the generated proof obligations (which is not the case with refine, which operates on the level of proof tactics).

--
=====================================================
Adam.Koprowski AT gmail.com, http://www.cs.ru.nl/~Adam.Koprowski
The difference between impossible and possible
lies in determination (Tommy Lasorda)
=====================================================

Attachment: prefix-ac.v
Description: Binary data




Archive powered by MhonArc 2.6.16.

Top of Page