Nabble - Coq

Re: coq indenter

2009-11-28T03:52:24Z

Dear all,

> It might be also useful to optionally add ;fail "Expected Goal to be
> Solved" to the end of any statement that solves a goal, or more likley an
> Ltac with a short name that does that.

Yes, that is very useful. I use fail a lot for that purpose and I
organize my proofs in such a way that the reasoning only infrequently
splits. And when it splits I add a comment that says what the purpose
of the branches is. It is quite possible to avoid splitting the
reasoning in lots of cases. If a tactic produces two subgoals and the
second is solved by some short reasoning like just "tauto" or some
other short squence of tactics then just write "tactic; [|tauto]". In
this case no "fail" is needed because tauto already gives an error if
it does not solve the goal. The result is that the reasoning hardly
ever splits and this keeps proof scripts so very much clearer.

All the best,
Chris

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: coq indenter

2009-11-27T11:02:11Z

To this effect you can use "..." in conjunction with
"Proof with solve []", e.g.

Lemma L: P.
Proof with solve [].
induction n.
assert Q.
intuition...
split.
apply H; auto...
exact 3...
rewrite IHn.
ring...
Qed.

JF

On Fri, Nov 27, 2009 at 09:50:24AM -0500, roconnor@... wrote:

> It might be also useful to optionally add ;fail "Expected Goal to be
> Solved" to the end of any statement that solves a goal, or more likley an
> Ltac with a short name that does that.
>
> The idea is to have coq fail as early as possible when a tactic fails to
> solve a goal when the script is expecting it to be solved. Ideally the
> Coq tactic syntax ought to have a different terminator character required
> when a tactic solves the goal.
>
> On Thu, 26 Nov 2009, Bas Spitters wrote:
>
>> Recently, I asked about a coq indenter. Meanwhile we use the following
>> python script which was produced by Eelis.
>> We succesfully tested it on the corn-library.
>>
>> We provide it in the hope it will be useful for others too.
>> http://www.eelis.net/coqindent/
>>
>> coqindent
>>
>> Introduction
>>
>> coqindent is a small crude Python script that indents Coq proof
>> scripts. It works by scanning coqtop's output for "# subgoals" strings
>> and other cues that proofs have begun/ended, which is obviously an
>> entirely fragile and irresponsible way to do it. Nevertheless, it
>> mostly works, so perhaps it might be of use to others.
>>
>> Example
>>
>> Given the input:
>>
>> Lemma L: P.
>> induction n.
>> assert Q.
>> intuition.
>> split.
>> apply H; auto.
>> exact 3.
>> rewrite IHn.
>> ring.
>> Qed.
>>
>> coqindent produces the following output:
>>
>> Lemma L: P.
>> Proof.
>> induction n.
>> assert Q.
>> intuition.
>> split.
>> apply H; auto.
>> exact 3.
>> rewrite IHn.
>> ring.
>> Qed.
>>
>> Thus, coqindent makes indentation depth coincide with the number of
>> pending subgoals, revealing the basic proof structure. If you prefer
>> another layout convention, coqindent is not for you.
>>
>> --------------------------------------------------------
>> Bug reports: http://logical.saclay.inria.fr/coq-bugs
>> Archives: http://pauillac.inria.fr/pipermail/coq-club
>> http://pauillac.inria.fr/bin/wilma/coq-club
>> Info: http://pauillac.inria.fr/mailman/listinfo/coq-club
>>
>
>
> --------------------------------------------------------
> Bug reports: http://logical.saclay.inria.fr/coq-bugs
> Archives: http://pauillac.inria.fr/pipermail/coq-club
> http://pauillac.inria.fr/bin/wilma/coq-club
> Info: http://pauillac.inria.fr/mailman/listinfo/coq-club
>
>

--
Jean-Francois Monin
CNRS-LIAMA, Project FORMES & Universite de Grenoble 1

Office 3-605, FIT, Tsinghua University
Haidian District, Beijing 100084, CHINA
Tel: +86 10 62 79 69 79 ext 605
Fax@LIAMA: +86 10 6264 7458

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: coq indenter

2009-11-27T06:50:24Z

It might be also useful to optionally add ;fail "Expected Goal to be
Solved" to the end of any statement that solves a goal, or more likley an
Ltac with a short name that does that.

The idea is to have coq fail as early as possible when a tactic fails to
solve a goal when the script is expecting it to be solved. Ideally the
Coq tactic syntax ought to have a different terminator character required
when a tactic solves the goal.

On Thu, 26 Nov 2009, Bas Spitters wrote:

> Recently, I asked about a coq indenter. Meanwhile we use the following
> python script which was produced by Eelis.
> We succesfully tested it on the corn-library.
>
> We provide it in the hope it will be useful for others too.
> http://www.eelis.net/coqindent/
>
> coqindent
>
> Introduction
>
> coqindent is a small crude Python script that indents Coq proof
> scripts. It works by scanning coqtop's output for "# subgoals" strings
> and other cues that proofs have begun/ended, which is obviously an
> entirely fragile and irresponsible way to do it. Nevertheless, it
> mostly works, so perhaps it might be of use to others.
>
> Example
>
> Given the input:
>
> Lemma L: P.
> induction n.
> assert Q.
> intuition.
> split.
> apply H; auto.
> exact 3.
> rewrite IHn.
> ring.
> Qed.
>
> coqindent produces the following output:
>
> Lemma L: P.
> Proof.
> induction n.
> assert Q.
> intuition.
> split.
> apply H; auto.
> exact 3.
> rewrite IHn.
> ring.
> Qed.
>
> Thus, coqindent makes indentation depth coincide with the number of
> pending subgoals, revealing the basic proof structure. If you prefer
> another layout convention, coqindent is not for you.
>
> --------------------------------------------------------
> Bug reports: http://logical.saclay.inria.fr/coq-bugs
> Archives: http://pauillac.inria.fr/pipermail/coq-club
> http://pauillac.inria.fr/bin/wilma/coq-club
> Info: http://pauillac.inria.fr/mailman/listinfo/coq-club
>

--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: simple problem

2009-11-26T11:20:01Z

Hello Chung Kil,

Le 26 nov. 09 à 11:34, Chung Kil Hur a écrit :

> Thanks for the detailed explanation.
>
> I heard that Coq + Axiom K is essentailly logically equivalent to
> Agda.
> But, if the propsition I gave is not provable in Coq + Axiom K, then
> it means that the above statement is not true.

It's not. Agda pattern-matching also considers inductive type
constructors injective,
which is independent from K and not derivable in Coq in general, as
far as I
know.

>> Chung Kil Hur wrote:
>>> Hello,
>>>
>>> Can anyone prove the following simple proposition using any sensible
>>> axioms like axiom_K or whatever?
>>>
>>> ===========================
>>> Require Import JMeq.
>>>
>>> Inductive J : bool -> Type :=
>>> C : J true
>>> | D : J false.
>>>
>>> Goal JMeq C D -> False.
>>
>> From JMeq C D we can derive easily that J true = J false, which is
>> not
>> absurd a priori since, informally, these two types are isomorphic
>> (they
>> are both singleton types).
>> We could try to set up a model of Coq where we have:
>> [[J b]] = 1, [[C]] = [[D]] = 0
>> Introduction rules are OK.
>> But then we have a problem with the elimination rule:
>> - The derived scheme J_rect can be interpreted as
>> [[ J_rect ]] = fun P f0 f1 b j => if b then f0 else f1
>> (remember J_rect : forall P : forall b : bool, J b -> Type,
>> P true C -> P false D -> forall (b : bool) (j : J b), P b j)
>> However, this validates
>> J_rect P f0 f1 true C -> f0 (and similarly for D), but
>> not J_rect P f0 f1 b C -> f0, so we need typed reduction (which is
>> not
>> the case of the current presentation of Coq's formalism).
>>
>> - The primitive match construction cannot be interpreted since we
>> do not
>> have the boolean information b
>>
>> We can take that argument backwards and deduce that, in any "simple"
>> model, if JMeq C D holds, then
>> [[J true]] = [[J false]], so [[C]]=[[D]] and then
>> [[True]] = [[match C with C => True | D => False end]] =
>> [[ match D with C => True | D => False end]] = [[False]]
>> which implies that False holds.
>>
>> Now can we prove it ? Probably not. If we try to follow the semantic
>> reasoning above we have a problem to replace C with D. This step
>> can be
>> done if we assume that the match operator is a morphism for JMeq, and
>> not only when types coincide:
>>
>> Axiom Jmatch_morph : forall b b' (j1:J b) (j2:J b')
>> (P:forall b, J b -> Type) f0 f1,
>> JMeq j1 j2 ->
>> JMeq
>> match j1 in J b return P b j1 with C => f0 | D => f1 end
>> match j2 in J b return P b j2 with C => f0 | D => f1 end.
>>
>> Goal JMeq C D -> False.
>> intro.
>> generalize (Jmatch_morph _ _ _ _ (fun _ _ => bool) true false H);
>> intro.
>> discriminate H0.
>> Qed.
>> (* Note that we use the axiom only in the non-dependent case, so we
>> could have assumed
>> forall b b' (j1:J b) (j2:J b') P (f0 f1:P),
>> JMeq j1 j2 ->
>> match j1 with C => f0 | D => f1 end =
>> match j2 with C => f0 | D => f1 end.
>> *)
>>
>> I have no idea how this axiom compares to Streicher's K axiom. What
>> JMeq
>> j1 j2 means (or should mean) outside the diagonal is unclear to me.
>>
>> Bruno Barras.
>>
>
> --------------------------------------------------------
> Bug reports: http://logical.saclay.inria.fr/coq-bugs
> Archives: http://pauillac.inria.fr/pipermail/coq-club
> http://pauillac.inria.fr/bin/wilma/coq-club
> Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: A simple quiz

2009-11-26T09:45:09Z

On Thu, Nov 26, 2009 at 6:36 PM, Taral <taralx@...> wrote:
> I've been looking for this one for a while:
>
> Goal forall A B (a:A) (b:B), JMeq a b -> A = B.
This one is just about destructing the hypothesis : intros; destruct
H; reflexivity.
Maybe you meant something else ?

--
I'm the kind of guy that until it happens, I won't worry about it. -
R.H. RoY05, MVP06

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: A simple quiz

2009-11-26T09:36:49Z

2009/11/25 Chung Kil Hur <Chung-Kil.Hur@...>:
> Goal forall b b' (x:I b) (y:I b'), JMeq x y -> b = b'.

I've been looking for this one for a while:

Goal forall A B (a:A) (b:B), JMeq a b -> A = B.

--
Taral <taralx@...>
"Please let me know if there's any further trouble I can give you."
-- Unknown

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: simple problem

2009-11-26T08:34:50Z

Thanks for the detailed explanation.

I heard that Coq + Axiom K is essentailly logically equivalent to Agda.
But, if the propsition I gave is not provable in Coq + Axiom K, then it means that the above statement is not true.

Best regards,
Chung-Kil Hur

----- Original Message -----
From: "Bruno Barras" <bruno.barras@...>
To: "Chung Kil Hur" <Chung-Kil.Hur@...>
Cc: <coq-club@...>
Sent: Thursday, November 26, 2009 4:09 PM
Subject: Re: [Coq-Club] simple problem

> Chung Kil Hur wrote:
>> Hello,
>>
>> Can anyone prove the following simple proposition using any sensible
>> axioms like axiom_K or whatever?
>>
>> ===========================
>> Require Import JMeq.
>>
>> Inductive J : bool -> Type :=
>> C : J true
>> | D : J false.
>>
>> Goal JMeq C D -> False.
>
> From JMeq C D we can derive easily that J true = J false, which is not
> absurd a priori since, informally, these two types are isomorphic (they
> are both singleton types).
> We could try to set up a model of Coq where we have:
> [[J b]] = 1, [[C]] = [[D]] = 0
> Introduction rules are OK.
> But then we have a problem with the elimination rule:
> - The derived scheme J_rect can be interpreted as
> [[ J_rect ]] = fun P f0 f1 b j => if b then f0 else f1
> (remember J_rect : forall P : forall b : bool, J b -> Type,
> P true C -> P false D -> forall (b : bool) (j : J b), P b j)
> However, this validates
> J_rect P f0 f1 true C -> f0 (and similarly for D), but
> not J_rect P f0 f1 b C -> f0, so we need typed reduction (which is not
> the case of the current presentation of Coq's formalism).
>
> - The primitive match construction cannot be interpreted since we do not
> have the boolean information b
>
> We can take that argument backwards and deduce that, in any "simple"
> model, if JMeq C D holds, then
> [[J true]] = [[J false]], so [[C]]=[[D]] and then
> [[True]] = [[match C with C => True | D => False end]] =
> [[ match D with C => True | D => False end]] = [[False]]
> which implies that False holds.
>
> Now can we prove it ? Probably not. If we try to follow the semantic
> reasoning above we have a problem to replace C with D. This step can be
> done if we assume that the match operator is a morphism for JMeq, and
> not only when types coincide:
>
> Axiom Jmatch_morph : forall b b' (j1:J b) (j2:J b')
> (P:forall b, J b -> Type) f0 f1,
> JMeq j1 j2 ->
> JMeq
> match j1 in J b return P b j1 with C => f0 | D => f1 end
> match j2 in J b return P b j2 with C => f0 | D => f1 end.
>
> Goal JMeq C D -> False.
> intro.
> generalize (Jmatch_morph _ _ _ _ (fun _ _ => bool) true false H); intro.
> discriminate H0.
> Qed.
> (* Note that we use the axiom only in the non-dependent case, so we
> could have assumed
> forall b b' (j1:J b) (j2:J b') P (f0 f1:P),
> JMeq j1 j2 ->
> match j1 with C => f0 | D => f1 end =
> match j2 with C => f0 | D => f1 end.
> *)
>
> I have no idea how this axiom compares to Streicher's K axiom. What JMeq
> j1 j2 means (or should mean) outside the diagonal is unclear to me.
>
> Bruno Barras.
>

coq indenter

2009-11-26T07:50:22Z

Recently, I asked about a coq indenter. Meanwhile we use the following
python script which was produced by Eelis.
We succesfully tested it on the corn-library.

We provide it in the hope it will be useful for others too.
http://www.eelis.net/coqindent/

coqindent

Introduction

coqindent is a small crude Python script that indents Coq proof
scripts. It works by scanning coqtop's output for "# subgoals" strings
and other cues that proofs have begun/ended, which is obviously an
entirely fragile and irresponsible way to do it. Nevertheless, it
mostly works, so perhaps it might be of use to others.

Example

Given the input:

Lemma L: P.
induction n.
assert Q.
intuition.
split.
apply H; auto.
exact 3.
rewrite IHn.
ring.
Qed.

coqindent produces the following output:

Lemma L: P.
Proof.
induction n.
assert Q.
intuition.
split.
apply H; auto.
exact 3.
rewrite IHn.
ring.
Qed.

Thus, coqindent makes indentation depth coincide with the number of
pending subgoals, revealing the basic proof structure. If you prefer
another layout convention, coqindent is not for you.

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: simple problem

2009-11-26T07:12:20Z

Rather than JMeq you might have more luck with: Definition Jeq i j x y := existT J i x = existT J j y.

Re: simple problem

2009-11-26T07:09:52Z

Chung Kil Hur wrote:

> Hello,
>
> Can anyone prove the following simple proposition using any sensible
> axioms like axiom_K or whatever?
>
> ===========================
> Require Import JMeq.
>
> Inductive J : bool -> Type :=
> C : J true
> | D : J false.
>
> Goal JMeq C D -> False.

From JMeq C D we can derive easily that J true = J false, which is not
absurd a priori since, informally, these two types are isomorphic (they
are both singleton types).
We could try to set up a model of Coq where we have:
[[J b]] = 1, [[C]] = [[D]] = 0
Introduction rules are OK.
But then we have a problem with the elimination rule:
- The derived scheme J_rect can be interpreted as
[[ J_rect ]] = fun P f0 f1 b j => if b then f0 else f1
(remember J_rect : forall P : forall b : bool, J b -> Type,
P true C -> P false D -> forall (b : bool) (j : J b), P b j)
However, this validates
J_rect P f0 f1 true C -> f0 (and similarly for D), but
not J_rect P f0 f1 b C -> f0, so we need typed reduction (which is not
the case of the current presentation of Coq's formalism).

- The primitive match construction cannot be interpreted since we do not
have the boolean information b

We can take that argument backwards and deduce that, in any "simple"
model, if JMeq C D holds, then
[[J true]] = [[J false]], so [[C]]=[[D]] and then
[[True]] = [[match C with C => True | D => False end]] =
[[ match D with C => True | D => False end]] = [[False]]
which implies that False holds.

Now can we prove it ? Probably not. If we try to follow the semantic
reasoning above we have a problem to replace C with D. This step can be
done if we assume that the match operator is a morphism for JMeq, and
not only when types coincide:

Axiom Jmatch_morph : forall b b' (j1:J b) (j2:J b')
(P:forall b, J b -> Type) f0 f1,
JMeq j1 j2 ->
JMeq
match j1 in J b return P b j1 with C => f0 | D => f1 end
match j2 in J b return P b j2 with C => f0 | D => f1 end.

Goal JMeq C D -> False.
intro.
generalize (Jmatch_morph _ _ _ _ (fun _ _ => bool) true false H); intro.
discriminate H0.
Qed.
(* Note that we use the axiom only in the non-dependent case, so we
could have assumed
forall b b' (j1:J b) (j2:J b') P (f0 f1:P),
JMeq j1 j2 ->
match j1 with C => f0 | D => f1 end =
match j2 with C => f0 | D => f1 end.
*)

I have no idea how this axiom compares to Streicher's K axiom. What JMeq
j1 j2 means (or should mean) outside the diagonal is unclear to me.

Bruno Barras.

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: simple problem

2009-11-26T07:02:36Z

Chung Kil Hur wrote:
> Can anyone prove the following simple proposition using any sensible
> axioms like axiom_K or whatever?
> ===========================
> Require Import JMeq.
> Inductive J : bool -> Type :=
> C : J true
> | D : J false.
> Goal JMeq C D -> False.
> ===========================

That's a tricky one. It might be easiest to define another judgment that
refines [JMeq], such that your new judgment also asserts that the [J]
indices of the two arguments are equal.

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

simple problem

2009-11-26T00:08:45Z

Hello,

Can anyone prove the following simple proposition using any sensible axioms like axiom_K or whatever?

===========================

Require Import JMeq.

Inductive J : bool -> Type :=
C : J true
| D : J false.

Goal JMeq C D -> False.
===========================

If the above is true, so is the following, which is what I really want to prove.

Goal forall b b' (x:J b) (y:J b'), JMeq x y -> b = b'.

These propositions are proved in Agda just by dependent pattern match.

But, I don't see how to prove it in Coq, or maybe it is not provable?

Thanks,

Chung-Kil Hur

A simple quiz

2009-11-25T14:09:49Z

Hello,

Can anybody prove the following simple proposition using any sensible axioms like axiom_K or whatever?

===========================

Require Import JMeq.

Inductive J : bool -> Type :=
C : J true
| D : J false.

Goal JMeq C D -> False.
===========================

If the above is true, so is the following, which is what I really want to prove.

Goal forall b b' (x:I b) (y:I b'), JMeq x y -> b = b'.

These propositions are provable in Agda just by dependent pattern match.

But, I don't see how to prove it in Coq, or maybe it is not provable?

Cheers,

Chung-Kil Hur

Re: Problem with types

2009-11-25T09:18:08Z

Jeffrey Harris wrote:
> I do not. After I did the dependent rewrite suggested by the previous
> poster, I got stuck on the sup F <= sup F case. I do not know of a
> paper proof, but the author seems confident that all the "standard"
> things are true.
>
Hint: prove
Lemma le_LimO_r : forall a o n,
Omega_le a (o n) ->
Omega_le a (LimO o).
by induction on a, then the "sup F <= sup F" case is trivial.

Bruno Barras.

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: Problem with types

2009-11-25T07:45:59Z

I do not. After I did the dependent rewrite suggested by the previous poster, I got stuck on the sup F <= sup F case. I do not know of a paper proof, but the author seems confident that all the "standard" things are true.

Thanks,
Jeffrey.

On Wed, Nov 25, 2009 at 8:51 AM, muad <muad.dib.space@...> wrote:

Hi, That Peter Hancock text is really interesting and I can show you my
definitions for it, but I have no idea how to prove this test (<=
reflexivity) theorem you were looking at (not because of type issues, just
because it's a hard theorem -- do you know an on-paper proof?).

Inductive Nat : Set := ZeroN | SuccN (_:Nat).
Inductive Omega : Set := ZeroO | SuccO (_:Omega) | LimO (_:Nat -> Omega).

Definition Fam (A : Type) : Type := { I : Set & I -> A }.
Definition Pow (A : Type) : Type := A -> Set.

Fixpoint Pd (o : Omega) : Set :=
match o with
| ZeroO => False
| SuccO a => (unit + Pd a)%type
| LimO a_ => { n : Nat & Pd (a_ n) }
end.

Definition Zero z := Pd z -> False.

Notation "!" := (False_rect _).

Fixpoint Pd_pd (a : Omega) : Pd a -> Omega :=
match a with
| ZeroO => !
| SuccO a => fun i =>
match i with
| inl tt => a
| inr t => Pd_pd a t
end
| LimO a_ => fun i =>
match i with
| existT n t => Pd_pd (a_ n) t
end
end.

Definition pd (a : Omega) : Fam Omega := existT _ (Pd a) (Pd_pd a).

Fixpoint Omega_le (a b : Omega) : Set :=
match a with
| ZeroO => unit
| SuccO a => { t : Pd b & Omega_le a (Pd_pd b t) }
| LimO a_ => forall n : Nat, Omega_le (a_ n) b
end.

Definition Omega_eq (a b : Omega) := (Omega_le a b, Omega_le b a).

Definition Omega_lt (a b : Omega) := { t : Pd b & Omega_le a (Pd_pd b t) }.

--
View this message in context: http://old.nabble.com/Problem-with-types-tp26488959p26513879.html
Sent from the Coq mailing list archive at Nabble.com.

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Call for Participation: TLDI'10

2009-11-25T07:07:31Z

*********************************************************************
CALL FOR PARTICIPATION

TLDI 2010

ACM SIGPLAN Workshop on
Types in Language Design and Implementation

23 January 2010
Madrid, Spain

To be held in conjunction with POPL 2010

http://research.microsoft.com/~akenn/tldi2010/
*********************************************************************

IMPORTANT DATES

Hotel reservation deadline: December 28, 2009 (Monday)

VENUE

TLDI'10 and all POPL'10 affiliated events will take place at the Melia Castilla Hotel, Madrid.

REGISTRATION

To register for TLDI'10, follow the link from the POPL 2010 page, at

http://www.cse.psu.edu/popl/10/

SCOPE

The role of types and proofs in all aspects of language design,
compiler construction, and software development has expanded greatly
in recent years. Type systems, type-based analyses and type-theoretic
deductive systems have been central to advances in compilation
techniques for modern programming languages, verification of safety
and security properties of programs, program transformation and
optimization, and many other areas. The ACM SIGPLAN Workshop on Types
in Language Design and Implementation brings researchers together to
share new ideas and results concerning all aspects of types and
programming, and is now an annual event.

INVITED SPEAKER

Matthias Felleisen, Northeastern University, Boston

PRELIMINARY PROGRAM

----------------------
Opening remarks: 9:20-9:30

Invited talk 9:30-10:30

*** Adding Types to Untyped Languages
Matthias Felleisen, Northeastern University, Boston

----------------------
** Session I 11:00-12:30

*** Effects for Cooperable and Serializable Threads
Jaeheon Yi and Cormac Flanagan

*** Race-free and Memory-safe Multithreading: Design and Implementation in Cyclone
Prodromos Gerakios, Nikolaos Papaspyrou and Konstantinos Sagonas

*** Distributed programming with distributed authorization
Kumar Avijit, Anupam Datta and Robert Harper

----------------------
** Session II 2:30-4:00

*** let should not be generalized
Dimitrios Vytiniotis, Simon Peyton Jones and Tom Schrijvers

*** Pointwise Generalized Algebraic Data Types
Chuan-kai Lin and Tim Sheard

*** Verifying Event-Driven Programs using Ramified Frame Properties
Neelakantan Krishnaswami, Lars Birkedal and Jonathan Aldrich

----------------------
** Session III 4:30-5:30

*** Lightweight Linear Types in System F^o
Karl Mazurak, Jianzhou Zhao and Steve Zdancewic

*** F-ing Modules
Andreas Rossberg, Claudio Russo and Derek Dreyer

----------------------

GENERAL CHAIR

Andrew Kennedy, Microsoft Research, Cambridge

PROGRAM CHAIR

Nick Benton, Microsoft Research, Cambridge

PROGRAM COMMITTEE

Gilles Barthe, IMDEA Software, Spain
Viviana Bono, University of Torino, Italy
Giorgio Ghelli, University of Pisa, Italy
Dan Grossman, University of Washington, USA
Atsushi Igarashi, Kyoto University, Japan
Conor McBride, University of Strathclyde, UK
Jeremy Siek, University of Colorado at Boulder, USA
Zhong Shao, Yale University, USA
Matthieu Sozeau, Harvard University, USA
Chris Stone, Harvey Mudd College, USA
Kristian Støvring, ITU Copenhagen, Denmark

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: Problem with types

2009-11-25T06:51:08Z

Hi, That Peter Hancock text is really interesting and I can show you my definitions for it, but I have no idea how to prove this test (<= reflexivity) theorem you were looking at (not because of type issues, just because it's a hard theorem -- do you know an on-paper proof?).

Inductive Nat : Set := ZeroN | SuccN (_:Nat).
Inductive Omega : Set := ZeroO | SuccO (_:Omega) | LimO (_:Nat -> Omega).

Definition Fam (A : Type) : Type := { I : Set & I -> A }.
Definition Pow (A : Type) : Type := A -> Set.

Fixpoint Pd (o : Omega) : Set :=
match o with
| ZeroO => False
| SuccO a => (unit + Pd a)%type
| LimO a_ => { n : Nat & Pd (a_ n) }
end.

Definition Zero z := Pd z -> False.

Notation "!" := (False_rect _).

Fixpoint Pd_pd (a : Omega) : Pd a -> Omega :=
match a with
| ZeroO => !
| SuccO a => fun i =>
match i with
| inl tt => a
| inr t => Pd_pd a t
end
| LimO a_ => fun i =>
match i with
| existT n t => Pd_pd (a_ n) t
end
end.

Definition pd (a : Omega) : Fam Omega := existT _ (Pd a) (Pd_pd a).

Fixpoint Omega_le (a b : Omega) : Set :=
match a with
| ZeroO => unit
| SuccO a => { t : Pd b & Omega_le a (Pd_pd b t) }
| LimO a_ => forall n : Nat, Omega_le (a_ n) b
end.

Definition Omega_eq (a b : Omega) := (Omega_le a b, Omega_le b a).

Definition Omega_lt (a b : Omega) := { t : Pd b & Omega_le a (Pd_pd b t) }.

Re: problem with xml output in 8.2

2009-11-24T10:42:03Z

Hi,

> mv: cannot stat `/home/ben/coq/xml/.*.html': No such file or directory
> Anomaly: Error executing "mv /home/ben/coq/xml/.*.html
> /home/ben/coq/xml/apply.theory.xml ".
> Please report.

This is solved in branch v8.2 and trunk of the svn repository.

Hugo Herbelin

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: Problem with types

2009-11-23T18:09:28Z

Jeffrey Harris wrote:
> I've run into a snag involving two types which should be equal but
> somehow aren't

I wouldn't describe the problem that way. The problem is that your
proposed rewrite leads to an ill-typed proof state. Try running
[generalize dependent p] before the rewrite; you need to move all
occurrences of the term to rewrite into the goal, so that they can all
be changed at once. I was able to finish that proof case pretty simply
after that.

> Another thing--how come even if I define Null as the empty Type,
> "Check Null" returns "Null:Prop"?

That's the fake universe polymorphism. When possible, particular uses
of inductive definitions are replaced with references to specialized
definition clones that use lower-level universes. [Prop] is the lowest
level universe that is legal here.

P.S.: I think it's a mistake to define [copath] with tactics. You could
consult my draft book for information on writing dependently-typed
functions directly:
http://adam.chlipala.net/cpdt/

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Problem with types

2009-11-23T17:05:57Z

Hello all!

I'm trying to implement in Coq the definition of ordering on Brouwer ordinals given in this paper: http://events.cs.bham.ac.uk/mgs2008/notes/proofTheory.pdf. I've run into a snag involving two types which should be equal but somehow aren't--what I'd *like* to do is written in-between the lines of asterisks near the bottom of the code, but Coq isn't letting me do that. Anyone know a way around this? (It's possible that this definition of ordering is the same as a simpler definition I wrote a while back, but that one seemed suboptimal, so I don't know). Another thing--how come even if I define Null as the empty Type, "Check Null" returns "Null:Prop"?

Thanks,
Jeffrey

Inductive ord_Br:Type :=
| ord_Br_O: ord_Br
| ord_Br_S: ord_Br -> ord_Br
| ord_Br_sup: (nat -> ord_Br) -> ord_Br.

Inductive Null:Type :=.

Inductive Unit:Type :=
| One: Unit.

Fixpoint pred_type (alpha:ord_Br):Type :=
match alpha with
| ord_Br_O => Null
| ord_Br_S alpha' => sum Unit (pred_type alpha')
| ord_Br_sup F => {n:nat & (pred_type (F n))}
end.

Definition copath (alpha:ord_Br) (p:pred_type alpha):ord_Br.
Proof.
induction alpha.
intro p; inversion p.
intro p; inversion p.
exact alpha.
apply IHalpha in X.
exact X.
intro p; inversion p.
apply X in X0.
exact X0.
Defined.

Inductive ord_Br_le: ord_Br -> ord_Br -> Prop :=
| ord_le_O: forall alpha:ord_Br, ord_Br_le ord_Br_O alpha
| ord_le_S: forall (alpha beta:ord_Br) (p:pred_type beta),
ord_Br_le alpha (copath beta p) -> ord_Br_le (ord_Br_S alpha) beta
| ord_le_sup: forall (F:nat -> ord_Br) (beta:ord_Br),
(forall n:nat, ord_Br_le (F n) beta) -> ord_Br_le (ord_Br_sup F) beta.

(*

Theorem test:forall alpha:ord_Br, ord_Br_le alpha alpha.
Proof.
induction alpha.
constructor.
inversion IHalpha; subst.
apply ord_le_S with (inl Null One).
simpl.
constructor.
apply ord_le_S with (inl (pred_type (ord_Br_S alpha0)) One).
simpl.
assumption.
apply ord_le_S with (inl (pred_type (ord_Br_sup F)) One).
simpl.
assumption.
apply ord_le_sup.
intro m.
assert (ord_Br_le (o m) (o m)).
apply H.
inversion H0; subst.
constructor.

***********************************************
rewrite H1 in p.
apply ord_le_S with (existT pred_type (o m) p).
***********************************************

*)

Coq for Windows 7?

2009-11-23T08:49:17Z

Hi Jeffrey,

I'm working with CoqIde under Windows 7 and it seems to work fine.

The only thing is that I cannot use the export functionality due to the
error "The system cannot find the path specified." But this might be a
problem just with my installation. Unfortunately, the error message does not
help me to locate the source of that error.

So long,
Thomas

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Coq for Windows 7?

2009-11-23T06:43:18Z

Hello!

I just got the new Windows operating system, and before I tried to install Coq onto it, I was wondering if anyone out there knew of any issues which might arise in doing so.

Thanks!
Jeffrey

Inductive relation is a function

2009-11-22T22:00:49Z

Thanks for your help!

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: Inductive relation is a function

2009-11-22T21:37:44Z

Hi,

You have to generalize over l' so that your induction hypothesis is
quantified over l'.

Fact sub_unique : forall k l l',
sub k l ->
sub k l' ->
l = l'.
Proof .
intros k l l' H; revert l' .
induction H; inversion 1; intuition (f_equal; eauto) .
Qed .

Thomas Thüm wrote:

> Hi all,
>
> I defined an inductive relation on lists. A list of pairs may or may not be
> in relation with a list of numbers. I need to proof that the relation
> expresses a function, i.e., for a given list of pairs there is at most one
> list of numbers in the relation.
>
> My function cannot be expressed using Fixpoint, since the returned list
> depends on a value [p] of type Prop:
>
> Require Export List.
>
> Inductive sub : list (Prop*nat) -> list nat -> Prop :=
> | s_nil : sub nil nil
> | s_cons : forall k l (p:Prop) n,
> sub k l ->
> p ->
> sub ((p,n)::k) (n::l)
> | s_nocons : forall k l (p:Prop) n,
> sub k l ->
> ~p ->
> sub ((p,n)::k) l.
>
> Fact sub_unique : forall k l l',
> sub k l ->
> sub k l' ->
> l = l'.
>
> I tried induction over [k], over [l], and over [sub k l] without success.
> The reason is, that the induction hypothesis in all these cases is useless.
> How can I proof this in Coq?
>
> Thanks,
> Thomas
>
> --------------------------------------------------------
> Bug reports: http://logical.saclay.inria.fr/coq-bugs
> Archives: http://pauillac.inria.fr/pipermail/coq-club
> http://pauillac.inria.fr/bin/wilma/coq-club
> Info: http://pauillac.inria.fr/mailman/listinfo/coq-club
>

Benchmarking a permutation-solving tactic

2009-11-22T21:02:18Z

I've been trying to speed up some of my tactics, so I did some
benchmarking. I thought the results might be worth sharing.

I'm writing a tactic to solve goals involving permutations of lists,
where some of the information is available in premises, for example:

forall E F G H: list A,
Permutation (G ++ H) F ->
Permutation (E ++ F) (G ++ E ++ H).

(This is slightly more involved than the permutation tactic example
in the reference manual.) As a subroutine to the main tactic, I have a
tactic that "reduces" a permutation by removing common components until
either none remains or the two sides are equal. Three examples:

(bench1)
Permutation (A ++ B ++ C ++ D) (E ++ F ++ A ++ G ++ H)
(removes A, and finds nothing else to remove:)
Permutation (B ++ C ++ D) (E ++ F ++ G ++ H)

(bench2)
Permutation (E ++ D ++ B ++ C ++ A) (A ++ B ++ C ++ D ++ E).
(removes components until it is trivial by reflexivity:)
Permutation A A

(bench3)
Permutation (A ++ B ++ C ++ D) (E ++ F ++ G ++ H).
(can't remove anything)
Permutation (A ++ B ++ C ++ D) (E ++ F ++ G ++ H).

The main tactic calls the subroutine several times, depending on the
size of the goal, and given the amount of waiting I'm doing, it seemed
worth optimizing. To this end, I wrote six versions of the permutation
reduction tactic (code below), and timed them on the above three
examples:

Time in seconds for 25 iterations, minus start-up time,
on my two-year-old MacBook

bench1 bench2 bench3 total
permut1 1.13 1.42 0.50 3.05
permut2 0.75 1.09 *0.23 2.07
permut3 1.60 1.15 1.94 4.69
permut4 *0.47 *0.79 0.42 *1.68
permut5 0.83 1.31 0.78 2.92
permut6 2.78 2.27 2.31 7.36

(* = best)

I'm not sure what conclusions to draw from this. I'd expect the
built-in search done by "match" to do better than search coded in Ltac,
in general. This is almost true, except that the hybrid approach in
permut4, with some search done by an outer Ltac loop, beats permut2. As
far as I can tell, permut2 should be O(n m k) and permut4 should be O(n
m), where n and m are the lengths of the lists and k is the number of
common components. That would explain why permut2 pulls ahead for bench
3, where there are no common components.

I've been using Coq for only a month or so, so please forgive me and let
me know if I've done this strangely.

Cheers,
Jesse

[permut_benchmark.v]

Require Import Coq.Lists.List.
Require Import Coq.Program.Equality.
Require Import Coq.Setoids.Setoid.

Hint Constructors Permutation : permut.
Hint Resolve Permutation_sym Permutation_trans Permutation_refl
Permutation_app
Permutation_app_swap Permutation_app_inv
Permutation_cons_inv Permutation_cons_app_inv
Permutation_app_inv_l Permutation_app_inv_r : permut.

(** Permutations form an equivalence relation *)
Add Parametric Relation {A} : (list A) (@Permutation A)
reflexivity proved by (@Permutation_refl A)
symmetry proved by (@Permutation_sym A)
transitivity proved by (@Permutation_trans A)
as Permutation_Equiv.

Lemma app_nil_start {A: Set} {E: list A} : nil ++ E = E.
Proof. reflexivity. Qed.

Hint Rewrite @app_ass : simpl_list.
Hint Rewrite <- @app_nil_end : simpl_list.
Hint Rewrite @app_nil_start : simpl_list.

(** ** Some extra, helpful permutation lemmas. *)

Lemma Permutation_rem_mid {A: Set} {G E1 E2 F1 F2: list A} :
Permutation (E1 ++ G ++ E2) (F1 ++ G ++ F2) ->
Permutation (E1 ++ E2) (F1 ++ F2).
Proof.
induction G; eauto using Permutation_app_inv.
Qed.

Lemma Permutation_add_mid {A: Set} {G E1 E2 F1 F2: list A} :
Permutation (E1 ++ E2) (F1 ++ F2) ->
Permutation (E1 ++ G ++ E2) (F1 ++ G ++ F2).
Proof.
intros.
do 2 (symmetry; rewrite Permutation_app_swap).
autorewrite with simpl_list.
apply Permutation_app_head.
eauto with permut.
Qed.

Lemma Permutation_swap_left {A: Set} {E1 E2 F: list A} :
Permutation (E1 ++ E2) F ->
Permutation (E2 ++ E1) F.
Proof. eauto with permut. Qed.

Lemma Permutation_swap_right {A: Set} {E F1 F2: list A} :
Permutation E (F1 ++ F2) ->
Permutation E (F2 ++ F1).
Proof. eauto with permut. Qed.

Lemma Permutation_add_front_mid {A: Set} {C E F1 F2: list A} :
Permutation E (F1 ++ F2) ->
Permutation (C ++ E) (F1 ++ C ++ F2).
Proof.
induction C; simpl; eauto using Permutation_cons_app.
Qed.

Lemma Permutation_add_front_back {A: Set} {C E F: list A} :
Permutation E F ->
Permutation (C ++ E) (F ++ C).
Proof.
intros.
induction C; autorewrite with simpl_list; simpl;
eauto using Permutation_cons_app.
Qed.

(** ** Auxiliary tactics *)

(** Given a sublist X of a list L, re-associates L to the form
L1 ++ X ++ L2. *)
Ltac focus_env_rec X L :=
match L with
| X => constr:(nil ++ L ++ nil)
| X ++ ?L2 => constr:(nil ++ X ++ L2)
| ?L1 ++ X => constr:(L1 ++ X ++ nil)
| _ ++ X ++ _ => L
| ?L1 ++ ?L2 =>
match L1 with
| context [X] => match focus_env_rec X L1 with
?L11 ++ X ++ ?L12 =>
constr:(L11 ++ X ++ (L12 ++ L2))
end
| _ => match focus_env_rec X L2 with
?L21 ++ X ++ ?L22 =>
constr:((L1 ++ L21) ++ X ++ L22)
end
end
end.

(** Re-associates a list in the conclusion to focus on some sublist X. *)
Tactic Notation "focus_env" constr(X) :=
match goal with
[ |- context [?L] ] =>
let L' := focus_env_rec X L in
replace L with L' by (autorewrite with simpl_list; reflexivity)
end.

(** The number of appended components in a (right-associated) list. *)
Ltac app_length L :=
match L with
| _ ++ ?L' => let len' := app_length L' in constr:(S len')
| _ => constr:1
end.

(** Rotate a list to the right or left. *)
Ltac rotate_left := apply Permutation_swap_left; repeat rewrite app_ass.
Ltac rotate_right := apply Permutation_swap_right; repeat rewrite app_ass.

(** Temporarily hide some subterm of the conclusion while performing
the given tactic. *)
Tactic Notation "hiding" constr(C) "[" tactic(tac) "]" :=
let temp := fresh "temp" in
set (temp := C); tac; subst temp.

Tactic Notation "hiding" "left" "[" tactic(tac) "]" :=
match goal with
[ |- Permutation ?E _ ] => hiding E [ tac ]
end.

Tactic Notation "hiding" "right" "[" tactic(tac) "]" :=
match goal with
[ |- Permutation _ ?F ] => hiding F [ tac ]
end.

(** First attempt: Relies mostly on pattern matching and backtracking. *)
Ltac permut1 :=
repeat match goal with
[ |- Permutation ?E ?F ] =>
match E with context [?X] =>
match F with context [X] =>
hiding E [ focus_env X ];
focus_env X;
apply Permutation_add_mid;
autorewrite with simpl_list
end end end.

(** Like first attempt, but doesn't check whether X appears in F
before attempting to focus on it. *)
Ltac permut2 :=
repeat match goal with
[ |- Permutation ?E _ ] =>
match E with context [?X] =>
hiding E [ focus_env X ];
focus_env X;
apply Permutation_add_mid;
autorewrite with simpl_list
end end.

(** Using explicit iteration as in section 10.9.2 of the reference manual.
Tracking the length of left list in the third parameter to loop saves
about 12%. Matching the goal to decide what to do, rather than trying
to apply Permutation_app_head and rotating on failure saves another
6%. *)
Ltac permut3 :=
let rec loop i j m :=
match goal with
| [ |- Permutation (?C ++ _) (?C ++ _) ] =>
apply Permutation_app_head;
match constr:(i, m) with
| (S ?i', S ?m') => loop i' m' m'
| _ => idtac
end
| [ |- Permutation (_ ++ _) (_ ++ _) ] =>
match j with
| S ?j' => rotate_right; loop i j' m
| _ =>
match i with
| S ?i' => rotate_left; loop i' m m
| _ => idtac
end
end
| _ => idtac
end in
match goal with [ |- Permutation ?E ?F ] =>
let n := app_length E in
let m := app_length F in
loop n m m
end.

(** Uses explicit iteration for left list as in the previous
attempt, but uses pattern matching a la permut1 to try to
locate a matching component in the right list. *)
Ltac permut4 :=
let rec loop i :=
match goal with
| [ |- Permutation (?C ++ ?E) ?F ] =>
first
[ hiding (C ++ E) [ focus_env C ];
apply Permutation_add_front_mid
| rotate_left ];
match i with
| S ?i' => loop i'
| _ => idtac
end
| _ => idtac
end in
match goal with [ |- Permutation ?E _ ] =>
let n := app_length E in
loop n
end.

(** Similar to the previous attempt, but relies on type-checking failure
more than explicit pattern matching. *)
Ltac permut5 :=
let rec loop i :=
match goal with
| [ |- Permutation ?E _ ] =>
hiding E [ repeat rewrite <- app_ass ];
try apply Permutation_add_front_back;
repeat (rewrite app_ass; try apply Permutation_add_front_mid);
try apply Permutation_app_head;
match i with
| S ?i' => loop i'
| _ => idtac
end
| _ => idtac
end in
match goal with [ |- Permutation ?E _ ] =>
let n := app_length E in
loop n
end.

(** The previous approach taken to its logical conclusion:
no explicit pattern matching. *)
Ltac permut6 :=
match goal with [ |- Permutation ?E ?F ] =>
replace E with (nil ++ E ++ nil)
by (autorewrite with simpl_list; reflexivity);
replace F with (nil ++ F ++ nil)
by (autorewrite with simpl_list; reflexivity)
end;
repeat rewrite <- app_ass;
repeat
(hiding right [ rewrite app_ass ];
hiding left [ repeat rewrite <- app_ass ];
repeat
(hiding left [ rewrite app_ass ];
repeat apply Permutation_add_mid));
autorewrite with simpl_list.

Definition bench1 :=
forall S : Set,
forall A B C D E F G H : list S,
Permutation (A ++ B ++ C ++ D) (E ++ F ++ A ++ G ++ H).

Definition bench2 :=
forall S : Set,
forall A B C D E : list S,
Permutation (E ++ D ++ B ++ C ++ A) (A ++ B ++ C ++ D ++ A).

Definition bench3 :=
forall S : Set,
forall A B C D E F G H : list S,
Permutation (A ++ B ++ C ++ D) (E ++ F ++ G ++ H).

[permut_benchmark.sh]

#!/bin/sh

src=permut_benchmark
tmp=benchmark_tmp

benchs=3
tactics=6

trial () {
iters=$1
bench=$2
tactic=$3

echo "Require Import $src." > $tmp.v

iter=0
while [ $iter -lt $iters ]; do
echo "Goal $bench. unfold $bench; intros; $tactic. Abort."
iter=`expr $iter + 1`
done >> $tmp.v

echo "iters=$iters bench=$bench tactic=$tactic"
/usr/bin/time coqc $tmp 2>&1
}

coqc $src

i=1; while [ $i -le $benchs ]; do
trial $1 bench$i idtac

j=1; while [ $j -le $tactics ]; do
trial $1 bench$i permut$j
j=`expr $j + 1`
done

i=`expr $i + 1`
done

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Inductive relation is a function

2009-11-21T06:58:55Z

Hi all,

I defined an inductive relation on lists. A list of pairs may or may not be
in relation with a list of numbers. I need to proof that the relation
expresses a function, i.e., for a given list of pairs there is at most one
list of numbers in the relation.

My function cannot be expressed using Fixpoint, since the returned list
depends on a value [p] of type Prop:

Require Export List.

Inductive sub : list (Prop*nat) -> list nat -> Prop :=
| s_nil : sub nil nil
| s_cons : forall k l (p:Prop) n,
sub k l ->
p ->
sub ((p,n)::k) (n::l)
| s_nocons : forall k l (p:Prop) n,
sub k l ->
~p ->
sub ((p,n)::k) l.

Fact sub_unique : forall k l l',
sub k l ->
sub k l' ->
l = l'.

I tried induction over [k], over [l], and over [sub k l] without success.
The reason is, that the induction hypothesis in all these cases is useless.
How can I proof this in Coq?

Thanks,
Thomas

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

ITP 2010 - Second Call for Papers

2009-11-20T06:35:12Z

Call for Papers
ITP 2010: Conference on Interactive Theorem Proving
11-14 July 2010, Edinburgh, Scotland
http://www.floc-conference.org/ITP-cfp.html

-----

ITP brings together researchers working in all areas of interactive
theorem proving. It combines the communities of two venerable
meetings: the TPHOLs conference and the ACL2 workshop. The inaugural
meeting of ITP will be held on 11-14 July 2010 in Edinburgh, Scotland,
as part of the Federated Logic Conference (FLoC, 9-21 July 2010),
co-located with the other FLoC conferences (CAV, ICLP, IJCAR, LICS,
RTA, SAT) and workshops.

The program committee welcomes submissions on all aspects of
interactive theorem proving and its applications. Examples of typical
topics include formal aspects of hardware or software (specification,
verification, semantics, synthesis, refinement, compilation, etc.);
formalization of significant bodies of mathematics; advances in
theorem prover technology (automation, decision procedures, induction,
combinations of systems and tools, etc.); other topics including those
relating to user interfaces, education, comparisons of systems, and
mechanizable logics; and concise and elegant worked examples ("Proof
Pearls").

Submission details:

All papers must be submitted electronically, via EasyChair:

http://www.easychair.org/conferences/?conf=itp10

Papers may be no longer than 16 pages and are to be submitted in PDF
using the Springer "llncs" format. Instructions may be found at
ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/instruct/authors/typeinst.pdf
with Latex source file typeinst.tex in the same directory.
Submissions must describe original unpublished work not submitted for
publication elsewhere, presented in a way that users of other systems
can understand. The proceedings will be published as a volume in the
Lecture Notes in Computer Science series and will be available to
participants at the conference.

In addition to regular submissions, described above, there will be a
"rough diamonds" section. Rough diamond submissions are limited to
four pages and may consist of an extended abstract. They will be
refereed: they will be expected to present innovative and promising
ideas, possibly in an early form and without supporting evidence.
Accepted diamonds will be published in the main proceedings. They
will be presented at the conference venue in a poster session.

Authors of accepted papers are expected to present their papers at the
conference, and will be required to sign copyright release forms.
All submissions must be written in English.

Important dates (midnight GMT):

Abstract submission deadline: 15 January 2010
Paper submission deadline: 22 January 2010
Notification of paper decisions: 15 March 2010
Camera-ready papers due from authors: 9 April 2010
Conference dates: 11-14 July 2010

Web page:

http://www.floc-conference.org/ITP-cfp.html

Conference co-chairs:

Matt Kaufmann, University of Texas at Austin, USA
Larry Paulson, University of Cambridge, United Kingdom

Program Committee:

Thorsten Altenkirch, Nottingham University, United Kingdom
David Aspinall, Edinburgh University, United Kingdom
Jeremy Avigad, Carnegie Mellon University, USA
Gilles Barthe, IMDEA, Spain
Jens Brandt, University of Kaiserslautern, Germany
Thierry Coquand, Chalmers University, Sweden
Ruben Gamboa, University of Wyoming, USA
Georges Gonthier, Microsoft Research, United Kingdom
David Greve, Rockwell Collins Inc., USA
Elsa Gunter, University of Illinois at Urbana-Champaign, USA
John Harrison, Intel Corporation, USA
Joe Hurd, Galois Inc., USA
Matt Kaufmann, University of Texas at Austin, USA
Gerwin Klein, NICTA, Australia
Xavier Leroy, INRIA, France
Assia Mahboubi, INRIA, France
Panagiotis Manolios, Northeastern University, USA
John Matthews, Galois Inc., USA
J Moore, University of Texas at Austin, USA
Cesar Munoz, NASA, USA
Tobias Nipkow, TU Muenchen, Germany
Michael Norrish, NICTA, Australia
David Pichardie, INRIA Rennes, France
Brigitte Pientka, McGill University, Canada
Lee Pike, Galois Inc., USA
Sandip Ray, University of Texas at Austin, USA
Jose Luis Ruiz-Reina, Universidad de Sevilla, Spain
Larry Paulson, University of Cambridge, United Kingdom
David Russinoff, Advanced Micro Devices Inc., USA
Peter Sewell, University of Cambridge, United Kingdom
Konrad Slind, Rockwell Collins Inc., USA
Sofiene Tahar, Concordia University, Canada
Christian Urban, TU Muenchen, Germany

Workshop Chair:

Michael Norrish, NICTA, Australia

Local Arrangements:

David Aspinall, Edinburgh University, United Kingdom

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

breaking mutual induction with records

2009-11-19T04:44:28Z

(** How to break induction with records **)
(* I just thought of a way to have recursive records,
* but I found some error, which surprises me a little bit.
* I won't be surprised it is a well known error, but
* as far as I remember, I didn't find it on the club list.
* In fact, I think the error message should be different,
* and I am not sure if it is the kernel which rejects it
* or the constrinterns...
*)

(* How to break induction with records *)
(*
Record unit_labelled_list_record (L : Type) := Build_list
{ head : unit;
tail : L
}.
*)
Inductive unit_labelled_list_record (L : Type) :=
Build_list : unit -> L -> unit_labelled_list_record L.

Inductive unit_labelled_list :=
| Nil : unit_labelled_list
| Cons : unit_labelled_list_record unit_labelled_list ->
unit_labelled_list.

(* for trunkists *)
(*
Fixpoint length l :=
match l with
| Nil => O
| Cons {|tail := l|} => S (length l)
end.

Fixpoint length2 l :=
match l with
| Nil => O
| Cons u => ulength u
end
with ulength u :=
match u with
{|tail := l|} => S (length2 l)
end.
*)
(* for standardists *)

Fixpoint length l :=
match l with
| Nil => O
| Cons (Build_list _ l) => S (length l)
end.

Fixpoint length2 (l : unit_labelled_list) :=
match l with
| Nil => O
| Cons u => ulength u
end
with ulength (u : unit_labelled_list_record unit_labelled_list) :=
match u with
Build_list _ l => S (length2 l)
end.

--
Cédric AUGER

Univ Paris-Sud, Laboratoire LRI, UMR 8623, F-91405, Orsay

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: Match_subterm?

2009-11-19T03:08:30Z

Hello,

I don't know why Coq does not give a more descriptive message. I can
only show how this example can be done.

First, when the type of P is not specified in the goal, by default it
becomes A -> Type. So either its type should be set explicitly to A ->
Set, or egal_rec should be replaced with egal_rect.

It is also understandable why unification fails. egal_rect ends with (Q
y y0 e) (I renamed the bound variable). Before "apply egal_rec" the goal
is P y. These two things can only be unified through higher-order
unification, e.g., Q = fun x y e => P x. As far as I know, Coq generally
needs some user hints to deal with higher-order unification.

The following works:

Goal forall (A:Set) (x y:A) P, (egal A x y) -> P x -> P y.
intros A x y P H.
apply egal_rect with (A := A) (P := fun (x : A) (y : A) _ => P x -> P y).

The same error occurs in this example:

Axiom a : forall (A : Set) (Q : A -> A -> Set) (x y : A), Q x y.
Goal forall (A : Set) (P : A -> Set) (x : A), P x.
intros A P x.
apply a.

This does not work, but "apply a with (A := A) (Q := fun (x y : A) => P
x)" works.

Evgeny

Cody Roux a écrit :

> Hello,
>
>
> I was playing with the following code:
>
> Inductive egal (A:Set):A->A->Set:=
> |reflexivite : forall x:A, egal A x x.
>
>
> Goal forall (A:Set) (x y:A) P, (egal A x y) ->P x ->P y.
> intros.
> apply egal_rec.
>
> And I got the following error:
>
> Error: Match_subterm
>
> Which seems a bit mysterious. What does it mean? Please note that I am
> not attempting to prove the above goal, so I guess this is more like a
> bug report :)
>
> thanks,
>
> Cody
>
> --------------------------------------------------------
> Bug reports: http://logical.saclay.inria.fr/coq-bugs
> Archives: http://pauillac.inria.fr/pipermail/coq-club
> http://pauillac.inria.fr/bin/wilma/coq-club
> Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Match_subterm?

2009-11-18T19:25:17Z

Hello,

I was playing with the following code:

Inductive egal (A:Set):A->A->Set:=
|reflexivite : forall x:A, egal A x x.

Goal forall (A:Set) (x y:A) P, (egal A x y) ->P x ->P y.
intros.
apply egal_rec.

And I got the following error:

Error: Match_subterm

Which seems a bit mysterious. What does it mean? Please note that I am
not attempting to prove the above goal, so I guess this is more like a
bug report :)

thanks,

Cody

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Call for Participation - PEPM'10 (co-located with POPL'10)

2009-11-18T09:49:47Z

===============================================================
CALL FOR PARTICIPATION
ACM SIGPLAN 2010 Workshop on
Partial Evaluation and Program Manipulation (PEPM'10)
Madrid, January 18-19, 2010

(Affiliated with POPL'10)

http://www.program-transformation.org/PEPM10
===============================================================

Abstracts of all papers and presentations are available from the
above web site.

INVITED TALKS:

* Lennart Augustsson (Standard Chartered Bank, UK)
Title: O, Partial Evaluator, Where Art Thou?

* Jeremy Siek (University of Colorado at Boulder, USA)
Title: General Purpose Languages Should be Metalanguages.

CONTRIBUTED TALKS:

* Nabil el Boustani and Jurriaan Hage.
Corrective Hints for Type Incorrect Generic Java Programs.

* Johannes Rudolph and Peter Thiemann.
Mnemonics: Type-safe Bytecode Generation at Run Time.

* Elvira Albert, Miguel Gomez-Zamalloa and German Puebla.
PET: A Partial Evaluation-based Test Case Generation Tool for Java
Bytecode.

* Martin Hofmann.
Igor2 - an Analytical Inductive Functional Programming System.

* José Pedro Magalhães, Stefan Holdermans, Johan Jeuring and Andres Löh.
Optimizing Generics Is Easy!

* Michele Baggi, María Alpuente, Demis Ballis and Moreno Falaschi.
A Fold/Unfold Transformation Framework for Rewrite Theories extended
to CCT.

* Hugh Anderson and Siau-Cheng KHOO.
Regular Approximation and Bounded Domains for Size-Change Termination.

* Évelyne Contejean, Pierre Courtieu, Julien Forest, Andrei Paskevich,
Olivier Pons and Xavier Urbain.
A3PAT, an Approach for Certified Automated Termination Proofs.

* Fritz Henglein.
Optimizing Relational Algebra Operations Using Generic Equivalence
Discriminators and Lazy Products.

* Adrian Riesco and Juan Rodriguez-Hortala.
Programming with Singular and Plural Non-deterministic Functions.

* Martin Hofmann and Emanuel Kitzelmann.
I/O Guided Detection of List Catamorphisms.

* Andrew Moss and Dan Page.
Bridging the Gap Between Symbolic and Efficient AES Implementations.

* Christopher Brown and Simon Thompson.
Clone Detection and Elimination for Haskell.

* Stefan Holdermans and Jurriaan Hage.
Making Stricterness More Relevant.

* Arun Lakhotia, Davidson Boccardo, Anshuman Singh and Aleardo Manacero
Júnior.
Context-Sensitive Analysis of Obfuscated x86 Executables.

* Xin Li and Mizuhito Ogawa.
Conditional Weighted Pushdown Systems and Applications.

* Ivan Lazar Miljenovic.
The SourceGraph Program.

* Florian Haftmann.
From Higher-Order Logic to Haskell: There and Back Again.

SPECIAL FEATURE:

* Andy Gill, Garrin Kimmell and Kevin Matlage.
Capturing Functions and Catching Satellites.

IMPORTANT DATES:

* Early registration deadline: December 22, 2009
* Hotel registration deadline: December 28, 2009

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

problem with xml output in 8.2

2009-11-18T06:46:21Z

Hello,

I compiled Coq 8.2pl1 from source without any errors during compilation.
However, coqc -xml file.v does not work properly. The XML files are
produced without problems, but the theory file with the table of
contents is not:

ben@bigfoot:~/coq$ coqc -xml apply.v

Writing on file "/home/ben/coq/xml/apply/apply.con.xml" was succesful

Writing on file "/home/ben/coq/xml/apply/apply.con.body.xml" was succesful

Writing on file "/home/ben/coq/xml/apply/apply.con.types.xml" was succesful
Warning: file /home/ben/coq/xml/apply.theory.glob cannot be used; links
will not be available: Sys_error("/home/ben/coq/xml/apply.theory.glob:
No such file or directory")
mv: cannot stat `/home/ben/coq/xml/.*.html': No such file or directory
Anomaly: Error executing "mv /home/ben/coq/xml/.*.html
/home/ben/coq/xml/apply.theory.xml ".
Please report.

The following files are produced during the coqc run (for the example
from above):
- apply.glob
- apply.theory.v
- xml.apply.theory.html
- the gzipped xml files

The same happens with the latest coq from SVN, and on the OS Ubuntu
8.04, 9.10 and - as I was told - on Mac.

On Coq 8.1pl5 it was reported to work.

What would I have to change to fix this problem?

Greetings
ben

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: more on vectors

2009-11-18T05:19:29Z

Dimitri Hendriks wrote:
> I still wonder, though, why [size] is accepted and [size'] not (see my
> previous mail).

Coq uses a pretty primitive termination-checking algorithm. It has
special-case handling of nested inductive types, which you used for
[size] but not [size'].

> It seems hard (again risking to be refuted within 20 minutes :) to
> destruct an object of type [Fin (S n)]. Instead we have to use
> inversion / complicated return types.

Well, it's taken more than 20 minutes, but only because of how early you
posted the question, in my time zone. ;) Here's a simple way to define
what you want.

Definition vcons (x : A) n (v : vector n) : vector (S n) :=
fun i =>
match i in Fin Sn return match Sn with
| O => Empty_set
| S n => vector n -> A
end with
| First _ => fun _ => x
| Next _ i' => fun v => v i'
end v.

My answer to your more general question of how to choose dependent
datatype encodings can be found at the end of the chapter on "Dependent
Data Structures" in my draft textbook:
http://adam.chlipala.net/cpdt/
The design patterns I've been using in this list thread are also covered
in that chapter and elsewhere in the book.

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

Re: more on vectors (was: guardedness hidden by induction)

2009-11-18T04:43:39Z

Dimitri Hendriks-2 wrote:

Thanks again Adam!

Indeed, a little reorganization, and fold is defined just like that. I
am impressed by the simplicity of the use of this representation of
vectors, as opposed to the one of the standard library. I still
wonder, though, why [size] is accepted and [size'] not (see my
previous mail).

It seems hard (again risking to be refuted within 20 minutes :) to
destruct an object of type [Fin (S n)]. Instead we have to use
inversion / complicated return types.

If, instead of the inductive definition, we define [Fin2 n] as the sum
[unit + ... + unit + empty], we have the advantage that the type [Fin2
(S n)] reduces to [unit + Fin2 n], and an object of that type is easy
to destruct.

As an example, below you find two versions of prepending an element to
a vector: [vcons] and [vcons2] for both versions of vectors.

Do you agree that [Fin2] is easier to work with than [Fin] ?

Best,
Dimitri

Inductive empty : Set := .

Inductive Fin : nat -> Type :=
| First : forall n, Fin (S n)
| Next : forall n, Fin n -> Fin (S n).

Fixpoint Fin2 (n : nat) : Type :=
match n with
| O => empty
| S n => (unit + Fin2 n) % type
end.

Section vectors.

Variable A : Type.

Definition vector (n : nat) := Fin n -> A.

Definition vector2 (n : nat) := Fin2 n -> A.

Definition vnil : vector 0.
intro i; inversion i.
Defined.

Definition vnil2 : vector2 0 :=
fun e => match e with end.

(*
Definition vcons : A -> forall n, vector n -> vector (S n).
intros a [|n]; intros v i.
exact a.
inversion_clear i as [| n' i' H].
exact a.
exact (v i').
Defined.

Print vcons.
*)

Definition vcons : A -> forall n, vector n -> vector (S n) :=
fun a n =>
match n return vector n -> vector (S n) with
| O => fun _ _ => a
| S n =>
fun (v : vector (S n)) (i : Fin (S (S n))) =>
let X :=
match i in Fin m return S (S n) = m -> A with
| First _ => fun _ => a
| Next m i' =>
fun (H : S (S n) = S m) =>
eq_rect (S n) (fun n1 => Fin n1 -> A) v m
(f_equal (fun e => match e with 0 => m | S n1 => n1
end) H) i'
end
in X (refl_equal (S (S n)))
end.

Definition vcons2 : A -> forall n, vector2 n -> vector2 (S n) :=
fun a n v i =>
match i with
| inl tt => a
| inr i' => v i'
end.

End vectors.

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club

I was just thinking that it might be nice to reuse the old code by making use of the isomorphism between the inductive and the recursive definitions of vector, but actually it's not really possible to say that v1 = v2 for the recursive case, we need to use forall i, v1 i = v2 i (So it's really some kind of setoid) and having to prove things respect that equality might be more trouble than it's worth.. then again it might not? I'm not sure but maybe someone could shed some light on it?

Re: more on vectors (was: guardedness hidden by induction)

2009-11-18T02:56:36Z

Thanks again Adam!

Indeed, a little reorganization, and fold is defined just like that. I
am impressed by the simplicity of the use of this representation of
vectors, as opposed to the one of the standard library. I still
wonder, though, why [size] is accepted and [size'] not (see my
previous mail).

It seems hard (again risking to be refuted within 20 minutes :) to
destruct an object of type [Fin (S n)]. Instead we have to use
inversion / complicated return types.

If, instead of the inductive definition, we define [Fin2 n] as the sum
[unit + ... + unit + empty], we have the advantage that the type [Fin2
(S n)] reduces to [unit + Fin2 n], and an object of that type is easy
to destruct.

As an example, below you find two versions of prepending an element to
a vector: [vcons] and [vcons2] for both versions of vectors.

Do you agree that [Fin2] is easier to work with than [Fin] ?

Best,
Dimitri

Inductive empty : Set := .

Inductive Fin : nat -> Type :=
| First : forall n, Fin (S n)
| Next : forall n, Fin n -> Fin (S n).

Fixpoint Fin2 (n : nat) : Type :=
match n with
| O => empty
| S n => (unit + Fin2 n) % type
end.

Section vectors.

Variable A : Type.

Definition vector (n : nat) := Fin n -> A.

Definition vector2 (n : nat) := Fin2 n -> A.

Definition vnil : vector 0.
intro i; inversion i.
Defined.

Definition vnil2 : vector2 0 :=
fun e => match e with end.

(*
Definition vcons : A -> forall n, vector n -> vector (S n).
intros a [|n]; intros v i.
exact a.
inversion_clear i as [| n' i' H].
exact a.
exact (v i').
Defined.

Print vcons.
*)

Definition vcons : A -> forall n, vector n -> vector (S n) :=
fun a n =>
match n return vector n -> vector (S n) with
| O => fun _ _ => a
| S n =>
fun (v : vector (S n)) (i : Fin (S (S n))) =>
let X :=
match i in Fin m return S (S n) = m -> A with
| First _ => fun _ => a
| Next m i' =>
fun (H : S (S n) = S m) =>
eq_rect (S n) (fun n1 => Fin n1 -> A) v m
(f_equal (fun e => match e with 0 => m | S n1 => n1
end) H) i'
end
in X (refl_equal (S (S n)))
end.

Definition vcons2 : A -> forall n, vector2 n -> vector2 (S n) :=
fun a n v i =>
match i with
| inl tt => a
| inr i' => v i'
end.

End vectors.

--------------------------------------------------------
Bug reports: http://logical.saclay.inria.fr/coq-bugs
Archives: http://pauillac.inria.fr/pipermail/coq-club
http://pauillac.inria.fr/bin/wilma/coq-club
Info: http://pauillac.inria.fr/mailman/listinfo/coq-club