Nabble - Mathematical Logics

Hint management in Modules and Module types.

2008-12-02T14:49:37Z

It appears that hints in module types are only used on modules declared
to have that module type, but not on modules satisfying that module
type. Is there a means of creating a module that satisfies a module
type and has all of its hints without needing to redeclare them?

For example, suppose I have the module type "foo" which contains some
hints.

Module Type foo.
Parameter def1 : <type_spec1>.
Hint Resolve def1.
End foo.

If "bar" is a module that satisfies "foo", I would like it to have these
hints as well, as they are more general the implementation. I do not
know how to do this without loosing access to the implementation of "def1".

Module bar <: foo.
Definition def1 := <def1_impl>.
End bar.

The following declaration hides the definition of "def1" but utilizes
the hints. Because "bar" is a specialization, the hints will be useful
when proving properties about a "bar" as a "foo", but the implementation
is important for proving additional properties about "bar".

Module baz : foo := bar.

How can I utilize the hints of the Module Type of "foo" with the module
"bar" without redeclaring them?

Scott Doerrie

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

TSI numéro spécial ANALYSE STATIQUE et COMPILATION: extension des envois au 15 février

2008-12-02T05:42:29Z

[Veuillez nous excuser pour les réceptions multiples éventuelles.

N'hésitez pas à diffuser largement cet appel.]

Extension de la date limite de soumission au

************** 15 février 2009 ****************

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

Technique et Science Informatiques (TSI)

Appel à propositions d'articles sur le thème

APPLICATION DES MÉTHODES FORMELLES À

L'ANALYSE STATIQUE ET LA COMPILATION

Coordonateur: Sandrine Blazy (ENSIIE, laboratoire CEDRIC, Évry)

Date limite de soumission: 15 février 2009

Ce numéro spécial vise à faire le point sur les travaux de recherche et les

techniques fondés sur les méthodes formelles améliorant la conception sûre

d'analyses statiques et de compilateurs.

Les méthodes formelles permettent de spécifier des systèmes de plus en plus

complexes. Il est désormais envisageable de vérifier formellement un

compilateur optimisant et réaliste, ou encore de concevoir des analyses

statiques entièrement automatiques. Ceci est rendu possible grâce à des

progrès récents accomplis dans différents domaines utilisés par l'analyse

statique et la compilation. Citons par exemple la sémantique formelle des

langages de programmation, les modèles de mémoire pour la concurrence,

l'interprétation abstraite, les formalismes logiques pour la preuve de

programmes, la mécanisation du raisonnement dans les assistants à la

preuve.

L'objectif de ce numéro thématique est de faire le point des travaux dans le

domaine de la conception formelle d'analyses statiques et de compilateurs, en

abordant notamment les thèmes suivants:

interprétation abstraite,
domaines abstraits,
analyses de pointeurs,
détection de bogues,
analyses fondées sur les types,

application des techniques de programmation par contraintes,
analyse de flot d'information,
compilateurs pour langages spécialisés,
compilateurs pour langages synchrones,
compilateurs pour systèmes hétérogènes distribués,
compilation à la volée,
interaction entre compilateur et architecture,
validation de traducteurs,
code auto-certifié,
gestion de la mémoire,
optimisations de programmes,

vérification logique de programmes,
... .

Soumission.

TSI est une revue francophone; les articles doivent être rédigés en

français sauf si _aucun_ des auteurs n'est francophone.

Les articles seront lus par deux lecteurs de la rédaction de TSI et

deux membres du comité de lecture.

Les décisions seront prises sur la base de leurs avis et des discussions

qui en découleront.

Les propositions d'articles devront respecter les règles de présentation et de

soumission usuelles de la revue TSI (voir http://tsi.e-revues.com/appel.jsp).

Les articles peuvent apparaître dans 3 rubriques : article de recherche

(entre 22 et 26 pages), de synthèse (jusqu'à 30 pages) ou d'application

(jusqu'à 20 pages).

La soumission se fait par envoi de l'article, au format PDF, par courrier

électronique à Laurence Sourdillon - sourdillon@...

Si vous ne recevez pas de message confirmant sa bonne réception moins d'une

semaine après envoi, nous vous demandons de nous contacter directement.

Comité de lecture:

- Yves Bertot, INRIA Sophia-Antipolis Méditerranée

- Sandrine Blazy, ENSIIE, Évry

- Arnaud Gotlieb, INRIA, Rennes - Bretagne Atlantique

- Bertrand Jeannet, INRIA Rhône-Alpes, Grenoble

- Benjamin Monate, CEA LIST, Saclay

- Pierre-Etienne Moreau, INRIA Nancy - Grand Est

- Dillon Pariente, Dassault Aviation, Saint-Cloud

- Marc Pouzet, Université Paris-Sud, Orsay

- Xavier Rival, ENS, Paris

- Nadia Tawbi, Université Laval, Canada

From forum: Coq

Re: General outer product

2008-12-01T09:11:39Z

Thank you, Wendy and Bruno. This discussion has been illuminating.

On Mon, Dec 1, 2008 at 8:58 AM, Bruno Barras <bruno.barras@...> wrote:

> You probably want the elements of Tuple to be in the max of the types in
> the list (i.e. you want Type_b >= Type_a). So the types must not be
> arguments of the constructors. This is possible since version 8.1 thanks
> to non-uniform parameters:
>
> Definition hd l := match l with Nil => Empty_set | Cons x _ => x end.
> Definition tl l := match l with Nil => TNil | Cons _ l' => l' end.
>
> Inductive Tuple (L:List Type) :=
> | TNil : L=Nil -> Tuple L
> | TCons : forall (x:hd L) (xs:Tuple (tl L)), Tuple L.
> (* note the trick with Empty_set to rule out L=Nil in TCons *)

Hmm, yes, I seem to recall running into similar troubles when I have
quantified over types in constructors on other occasions.

> PS: another way to proceed is to define Tuple as a recursive function
> instead of an inductive type:
> Fixpoint Tuple (L:List Type) :=
> match L with
> | Nil => Empty_set
> | Cons t Nil => t
> | Cons t L' => t * Tuple L'
> end.

Heh. My programmer-shaped mind still doesn't think of writing a
function to work on types. Thanks for the suggestion :-)

Luke

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Re: General outer product

2008-12-01T07:58:31Z

Hi Wendy and Luke,

Wendy Verbruggen wrote:

> In your case I think the problem is in the way you've used your
> definition of "map". Below I have given a minimal definition that causes
> the same problem, marked each occurrence of "Type" with a number to
> distinguish them and noted the constraints introduced at various points
> (these are mostly to give you a feel for how these constraints work, the
> only constraint involved in the inconsistency is at the very end).
>
> ---------------------------------------------
>
> Inductive List (A : Type(*1*)) : Type(*2*) :=
> | Nil : A -> List A
> | Cons : A -> List A -> List A.
> (* This introduces the constraint Type1 <= Type2 *)
>
> Variable map : forall (A : Type(*3*)) (B : Type(*4*)), (A -> B) -> List
> A -> List B.
>
> Variable ts : List Type(*5*).
>
> Check map List ts.
> (* Universe inconsistency! *)
>
> ---------------------------------------------
>
> In your definition of cross you use the statement "map List ts", which
> instantiates the arguments of map as follows:
>
> f : a -> b is instantiated with List : Type1 -> Type2, so a = Type1 and
> b = Type2. This means that
>
> Type1 : Type3 -- constraint Type1 < Type3
> Type2 : Type4 -- constraint Type2 < Type4
>
> Your problem lies in the instantiation of the next argument to map: "l :
> List a"; we have just established that a = Type1, so l : List Type1..
> *but* the first argument to List must have Type1 and we get Type1 :
> Type1 which introduces the constraint Type1 < Type1... obviously an
> inconsistency.

This explanation is correct, but (1) there is a turnaround and (2)
Luke's definition raises more problems.

Regarding (1):
Check map (fun X:Type => List X) ts.
does typecheck, because fully applied inductive types are
sort-polymorphic (so in this example, map is instanciated for a level of
List higher than the (fresh) level of X), while partially applied
inductive types are monomorphic (then Wendy's explanation apply).

> I always find universe inconsistencies slightly mind-boggling.. so if my
> explanations doesn't make a lot of sense I apologize! If you have any
> questions let me know..

Agreed. We still look for a way to display reasonable error messages in
case of universe inconsistency.

One more tip: avoid the multiplication of Type levels by using
definitions to fix the levels you need (Definition Type_a := Type.
Definition Type_b := Type. Definition Type_x : Type_a (*x<a*) := Type.),
and then do not use Type anymore (this implies not to rely on type
inference, but to explicitely give the type of binders and implicit
arguments of Nil and Cons).

> On 30 Nov 2008, at 19:51, Luke Palmer wrote:
>> Set Implicit Arguments.
>>
>> (* Nothing special here, just a list type *)
>> Inductive List a : Type :=
>> | Nil : List a
>> | Cons : a -> List a -> List a.
>>
>> Fixpoint map a b (f : a->b) (list : List a) : List b :=
>> match list with
>> | Nil => Nil _
>> | Cons x xs => Cons (f x) (map f xs)
>> end.
>>
>> Fixpoint append a (list ys : List a) : List a :=
>> match list with
>> | Nil => ys
>> | Cons x xs => Cons x (append xs ys)
>> end.
>>
>> Fixpoint concat a (list : List (List a)) : List a :=
>> match list with
>> | Nil => Nil _
>> | Cons xs xss => append xs (concat xss)
>> end.
>>
>> Definition uncurry : forall a b c, (a -> b -> c) -> (a*b -> c)
>> := fun _ _ _ f t => let (x,y) := t in f x y.
>>
>>
>> (* A heterogeneous list *)
>> Inductive Tuple : List Type -> Type :=
>> | TNil : Tuple (Nil _)
>> | TCons : forall t ts (x:t) (xs:Tuple ts), Tuple (Cons t ts).

I think there is a problem here. Note that the first two arguments of
TCons are t:Type and ts:List Type.
For consistency reasons, inductive types (in Type) have to be
predicative, hence its level must be above the level of each argument of
constructor. So the level of Tuple is strictly greater than the level of
the types appearing in the list of types. Quite counter-intuitive if you
think your tuples live in a sort below the sort of List.

I mean:
Inductive Tuple : List Type_a -> Type_b :=
| TNil : Tuple (Nil _)
| TCons : forall (t:Type_c) ts (x:t) (xs:Tuple ts), Tuple (Cons t ts).
implies (among others)
Type_a = Type_c < Type_b

You probably want the elements of Tuple to be in the max of the types in
the list (i.e. you want Type_b >= Type_a). So the types must not be
arguments of the constructors. This is possible since version 8.1 thanks
to non-uniform parameters:

Definition hd l := match l with Nil => Empty_set | Cons x _ => x end.
Definition tl l := match l with Nil => TNil | Cons _ l' => l' end.

Inductive Tuple (L:List Type) :=
| TNil : L=Nil -> Tuple L
| TCons : forall (x:hd L) (xs:Tuple (tl L)), Tuple L.
(* note the trick with Empty_set to rule out L=Nil in TCons *)

Here TCons has no type arguments, and we have the expected constraint:
Type_a <= Type_b. Now you're in better shape to go through your proof.
It might be useful to define auxiliary constructors and eliminators
(TNil', TCons' and Tuple_rect') to match the type of the original Tuple
definition.

I did not check if the definitions below go through, but you probably
need to eta-expand some functions (map, as shown by Wendy, and maybe
uncurry) in order to recover sort-polymorphism and avoid non-desired
constraints.

Hope this helps.
Bruno Barras.

PS: another way to proceed is to define Tuple as a recursive function
instead of an inductive type:
Fixpoint Tuple (L:List Type) :=
match L with
| Nil => Empty_set
| Cons t Nil => t
| Cons t L' => t * Tuple L'
end.

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Re: General outer product

2008-12-01T02:49:31Z

Hi Luke,

I had a similar problem a while back, and these universe
inconsistencies are indeed tricky to solve!

The best way to go about it is to use the command "Set Printing
Universes" at the start of your file, and then put "Print Universes."
anywhere in the file to show you the universe constraints at that
point. That should give you a feel for when certain constraints are
introduced and what might cause the problem. (Obviously you can't put
a Print Universes *after* the inconsistency, so it's not that straight-
forward unfortunately..). Something else that might help is to try and
find a minimal example that still introduces the inconsistency and
work with that - starting coqide with the option "-nois" will get rid
of a lot "outside" constraints and will let you focus on the ones your
interested in.

In your case I think the problem is in the way you've used your
definition of "map". Below I have given a minimal definition that
causes the same problem, marked each occurrence of "Type" with a
number to distinguish them and noted the constraints introduced at
various points (these are mostly to give you a feel for how these
constraints work, the only constraint involved in the inconsistency is
at the very end).

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

Inductive List (A : Type(*1*)) : Type(*2*) :=
| Nil : A -> List A
| Cons : A -> List A -> List A.
(* This introduces the constraint Type1 <= Type2 *)

Variable map : forall (A : Type(*3*)) (B : Type(*4*)), (A -> B) ->
List A -> List B.

Variable ts : List Type(*5*).

Check map List ts.
(* Universe inconsistency! *)

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

In your definition of cross you use the statement "map List ts", which
instantiates the arguments of map as follows:

f : a -> b is instantiated with List : Type1 -> Type2, so a = Type1
and b = Type2. This means that

Type1 : Type3 -- constraint Type1 < Type3
Type2 : Type4 -- constraint Type2 < Type4

Your problem lies in the instantiation of the next argument to map:
"l : List a"; we have just established that a = Type1, so l : List
Type1.. *but* the first argument to List must have Type1 and we get
Type1 : Type1 which introduces the constraint Type1 < Type1...
obviously an inconsistency.

I always find universe inconsistencies slightly mind-boggling.. so if
my explanations doesn't make a lot of sense I apologize! If you have
any questions let me know..

Good luck!

Wendy

On 30 Nov 2008, at 19:51, Luke Palmer wrote:

> Following a discussion on haskell-cafe, I decided I would try to write
> a function which could take the outer product of a heterogeneous list
> of lists. When I finally wrote it, I got a "universe inconsistency"
> error. I understand that maybe this is not possible as I have phrased
> it due to predicativity constraints or something, but I have no idea
> why. Could someone explain what is going on here?
>
> Thanks!
> Luke
>
> Set Implicit Arguments.
>
> (* Nothing special here, just a list type *)
> Inductive List a : Type :=
> | Nil : List a
> | Cons : a -> List a -> List a.
>
> Fixpoint map a b (f : a->b) (list : List a) : List b :=
> match list with
> | Nil => Nil _
> | Cons x xs => Cons (f x) (map f xs)
> end.
>
> Fixpoint append a (list ys : List a) : List a :=
> match list with
> | Nil => ys
> | Cons x xs => Cons x (append xs ys)
> end.
>
> Fixpoint concat a (list : List (List a)) : List a :=
> match list with
> | Nil => Nil _
> | Cons xs xss => append xs (concat xss)
> end.
>
> Definition uncurry : forall a b c, (a -> b -> c) -> (a*b -> c)
> := fun _ _ _ f t => let (x,y) := t in f x y.
>
>
> (* A heterogeneous list *)
> Inductive Tuple : List Type -> Type :=
> | TNil : Tuple (Nil _)
> | TCons : forall t ts (x:t) (xs:Tuple ts), Tuple (Cons t ts).
>
> Definition cross2 : forall a b, List a -> List b -> List (a * b) :=
> fun _ _ xs ys => concat (map (fun x => map (fun y => (x,y)) ys) xs).
>
> Definition cross : forall ts, Tuple (map List ts) -> List (Tuple ts).
> intros.
> induction ts.
> exact (Cons TNil (Nil _)).
> simpl in X.
> inversion X.
> apply IHts in xs.
> exact (map (uncurry (TCons (t:=_) (ts:=_))) (cross2 x xs)).
> Defined.
> (* Oh no, universe inconsistency! *)
>
> --------------------------------------------------------
> Bug reports: http://logical.futurs.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.futurs.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

From forum: Coq

General outer product

2008-11-30T11:51:59Z

Following a discussion on haskell-cafe, I decided I would try to write
a function which could take the outer product of a heterogeneous list
of lists. When I finally wrote it, I got a "universe inconsistency"
error. I understand that maybe this is not possible as I have phrased
it due to predicativity constraints or something, but I have no idea
why. Could someone explain what is going on here?

Thanks!
Luke

Set Implicit Arguments.

(* Nothing special here, just a list type *)
Inductive List a : Type :=
| Nil : List a
| Cons : a -> List a -> List a.

Fixpoint map a b (f : a->b) (list : List a) : List b :=
match list with
| Nil => Nil _
| Cons x xs => Cons (f x) (map f xs)
end.

Fixpoint append a (list ys : List a) : List a :=
match list with
| Nil => ys
| Cons x xs => Cons x (append xs ys)
end.

Fixpoint concat a (list : List (List a)) : List a :=
match list with
| Nil => Nil _
| Cons xs xss => append xs (concat xss)
end.

Definition uncurry : forall a b c, (a -> b -> c) -> (a*b -> c)
:= fun _ _ _ f t => let (x,y) := t in f x y.

(* A heterogeneous list *)
Inductive Tuple : List Type -> Type :=
| TNil : Tuple (Nil _)
| TCons : forall t ts (x:t) (xs:Tuple ts), Tuple (Cons t ts).

Definition cross2 : forall a b, List a -> List b -> List (a * b) :=
fun _ _ xs ys => concat (map (fun x => map (fun y => (x,y)) ys) xs).

Definition cross : forall ts, Tuple (map List ts) -> List (Tuple ts).
intros.
induction ts.
exact (Cons TNil (Nil _)).
simpl in X.
inversion X.
apply IHts in xs.
exact (map (uncurry (TCons (t:=_) (ts:=_))) (cross2 x xs)).
Defined.
(* Oh no, universe inconsistency! *)

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Re: Russell's paradox

2008-11-29T13:27:39Z

Hi Benjamin,

> - One does not need K nore dependent inversion for the matter.
> Just do "case eq" where eq is your equality proof.

Thank you. I tried "case eq" earlier when I had an "unsolvable 2nd
order unification problem" but then I forgot to try it again when I
avoided this by generalizing the problem.

> - You can simplify your development by noticing right away
> that all trees are "good".

Good point, but I think this is a different proof.

Cheers,
Thorsten

P.S. See you next Friday, I hope.

>
> Cheers,
>
>
> Benjamin
>
>
> (** Mathematics for Computer Scientists 2 (G52MC2)
> Thorsten Altenkirch
>
> L16 (Russell's paradox)
>
> The material in this file contains coq proofs
> which can be read and animated with coqide or xemacs+proofgeneral.
>
> **)
>
> Section russell.
>
> Set Implicit Arguments.
>
> Variable set : Set.
> Variable name : Set -> set.
> Variable El : set -> Set.
> Axiom reflect : forall A:Set,A = El (name A).
>
> Inductive Tree : Set :=
> span : forall a : set, (El a -> Tree) -> Tree.
>
> Definition elem (t : Tree) (u : Tree) : Prop
> := match u with
> | span A us => exists a : El A , t = us a
> end.
>
> Definition Bad (t : Tree) : Prop
> := elem t t.
>
> Lemma is_good : forall t, ~Bad t.
> induction t; intros [x ex].
> unfold not in H; apply (H x).
> rewrite <- ex.
> exists x; trivial.
> Qed.
>
> Definition tree := name Tree.
>
> Definition getTreeAux : forall A : Set, Tree = A -> A -> Tree.
> intros A e a; rewrite e; exact a.
> Defined.
>
> Definition getAuxTree : forall A : Set, Tree = A -> Tree -> A.
> intros A e a; rewrite <- e; exact a.
> Defined.
>
> Definition getTree : El tree -> Tree :=
> fun e => (getTreeAux (reflect _ ) e).
>
> Definition Russell := (span getTree).
>
> Lemma is_bad : (Bad Russell).
> exists (getAuxTree (reflect _) Russell).
> unfold getTree.
> case (reflect Tree).
> trivial.
> Qed.
>
> Definition paradox : False := (is_good _ is_bad).
>
>
>
>
> Le 29 nov. 08 15:03, Thorsten Altenkirch a crit :
>
>>> I suspect I need K (or I am just too stupid). Can anybody conform
>>> either? I.e. can I prove this using Coq.Logic.Eqdep or without?
>>
>> I am just too stupid. But so is Coq. I just need to use dependent
>> inversion.
>>
>> Actually I realized that I can prove it with the standard
>> eliminator for equality:
>>
>> eq_elim : forall (A:Set)(x:A)(P:forall y:A, (x=y)->Set)
>> (m:P x (refl_equal x))
>> (y:A)(p:x=y),P y p.
>>
>> This is not automatically derived by Coq (why not?) but it can be
>> proven using dependent inversion. It seems that you always get in
>> trouble if you try to use dependent types in Coq.
>>
>> I attach my completed Russell derivation.
>>
>> Cheers,
>> Thorsten
>>
>>
>> This message has been checked for viruses but the contents of an
>> attachment
>> may still contain software viruses, which could damage your
>> computer system:
>> you are advised to perform your own checks. Email communications
>> with the
>> University of Nottingham may be monitored as permitted by UK
>> legislation.
>>
>> <l16-crib.v>
>
> --------------------------------------------------------
> Bug reports: http://logical.futurs.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

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Re: Russell's paradox

2008-11-29T12:36:16Z

Hi,

Nice version of Russell's paradox.

Two remarks :

- One does not need K nore dependent inversion for the matter.
Just do "case eq" where eq is your equality proof.

- You can simplify your development by noticing right away
that all trees are "good".

Cheers,

Benjamin

(** Mathematics for Computer Scientists 2 (G52MC2)
Thorsten Altenkirch

L16 (Russell's paradox)

The material in this file contains coq proofs
which can be read and animated with coqide or xemacs+proofgeneral.

**)

Section russell.

Set Implicit Arguments.

Variable set : Set.
Variable name : Set -> set.
Variable El : set -> Set.
Axiom reflect : forall A:Set,A = El (name A).

Inductive Tree : Set :=
span : forall a : set, (El a -> Tree) -> Tree.

Definition elem (t : Tree) (u : Tree) : Prop
:= match u with
| span A us => exists a : El A , t = us a
end.

Definition Bad (t : Tree) : Prop
:= elem t t.

Lemma is_good : forall t, ~Bad t.
induction t; intros [x ex].
unfold not in H; apply (H x).
rewrite <- ex.
exists x; trivial.
Qed.

Definition tree := name Tree.

Definition getTreeAux : forall A : Set, Tree = A -> A -> Tree.
intros A e a; rewrite e; exact a.
Defined.

Definition getAuxTree : forall A : Set, Tree = A -> Tree -> A.
intros A e a; rewrite <- e; exact a.
Defined.

Definition getTree : El tree -> Tree :=
fun e => (getTreeAux (reflect _ ) e).

Definition Russell := (span getTree).

Lemma is_bad : (Bad Russell).
exists (getAuxTree (reflect _) Russell).
unfold getTree.
case (reflect Tree).
trivial.
Qed.

Definition paradox : False := (is_good _ is_bad).

Le 29 nov. 08 à 15:03, Thorsten Altenkirch a écrit :

>> I suspect I need K (or I am just too stupid). Can anybody conform
>> either? I.e. can I prove this using Coq.Logic.Eqdep or without?
>
> I am just too stupid. But so is Coq. I just need to use dependent
> inversion.
>
> Actually I realized that I can prove it with the standard eliminator
> for equality:
>
> eq_elim : forall (A:Set)(x:A)(P:forall y:A, (x=y)->Set)
> (m:P x (refl_equal x))
> (y:A)(p:x=y),P y p.
>
> This is not automatically derived by Coq (why not?) but it can be
> proven using dependent inversion. It seems that you always get in
> trouble if you try to use dependent types in Coq.
>
> I attach my completed Russell derivation.
>
> Cheers,
> Thorsten
>
>
> This message has been checked for viruses but the contents of an
> attachment
> may still contain software viruses, which could damage your computer
> system:
> you are advised to perform your own checks. Email communications
> with the
> University of Nottingham may be monitored as permitted by UK
> legislation.
>
> <l16-crib.v>

From forum: Coq

Re: Russell's paradox

2008-11-29T07:18:46Z

On Sat, Nov 29, 2008 at 02:36:05PM +0000, Robin Green wrote:

> On Sat, 29 Nov 2008 14:03:06 +0000
> Thorsten Altenkirch <txa@...> wrote:
>
> > > I suspect I need K (or I am just too stupid). Can anybody conform
> > > either? I.e. can I prove this using Coq.Logic.Eqdep or without?
> >
> > I am just too stupid. But so is Coq. I just need to use dependent
> > inversion.
> >
> > Actually I realized that I can prove it with the standard eliminator
> > for equality:
> >
> > eq_elim : forall (A:Set)(x:A)(P:forall y:A, (x=y)->Set)
> > (m:P x (refl_equal x))
> > (y:A)(p:x=y),P y p.
> >
> > This is not automatically derived by Coq (why not?) but it can be
> > proven using dependent inversion.
>
> Doesn't the generated proof rely on K or an equivalent, though?
>
> On that note, I think the coq documentation should be updated to warn
> when using certain tactics can introduce axioms.

Concerning the dependent version of the elimination principle for eq
(or more generally for inductive types in Prop), it's true that Coq
doesn't provide it by default. Probably because it has been considered
that the non-dependent version is enough for most usages and quite
simplier. But you can nonetheless obtain the full version
automatically:

Scheme eq_elim := Induction for eq Sort Type.

Check eq_elim.
eq_elim
: forall (A : Type) (x : A) (P : forall a : A, x = a -> Type),
P x (refl_equal x) -> forall (y : A) (e : x = y), P y e

Reciprocally, the "Scheme ... := Minimality for ..." command allows
one to obtain the non-dependent version of the elimination principle.
This might be interesting when Coq has decided that the full version
is best (that is, for inductive types in Set or Type).

On the topic of axioms, a "Print eq_elim" after the above command
shows clearly that no axiom is used in the proof. This can also be
confirmed by the new command "Print Assumption eq_elim" whose aim is
to recursively retreive the axiom(s) a particular object is using.
Concerning standard tactics, apart obviously from "admit", I can see
none that might introduce axioms. And anyway, in case of doubt,
you can do a "Print Assumption" of your lemma.

Best regards,

Pierre Letouzey

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Re: Russell's paradox

2008-11-29T06:36:05Z

On Sat, 29 Nov 2008 14:03:06 +0000
Thorsten Altenkirch <txa@...> wrote:

Doesn't the generated proof rely on K or an equivalent, though?

On that note, I think the coq documentation should be updated to warn
when using certain tactics can introduce axioms.

--
Robin

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Re: Russell's paradox

2008-11-29T06:03:06Z

> I suspect I need K (or I am just too stupid). Can anybody conform
> either? I.e. can I prove this using Coq.Logic.Eqdep or without?

I am just too stupid. But so is Coq. I just need to use dependent
inversion.

Actually I realized that I can prove it with the standard eliminator
for equality:

eq_elim : forall (A:Set)(x:A)(P:forall y:A, (x=y)->Set)
(m:P x (refl_equal x))
(y:A)(p:x=y),P y p.

This is not automatically derived by Coq (why not?) but it can be
proven using dependent inversion. It seems that you always get in
trouble if you try to use dependent types in Coq.

I attach my completed Russell derivation.

Cheers,
Thorsten

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

l16-crib.v (2K) Download Attachment

From forum: Coq

Re: Russell's paradox

2008-11-28T08:27:26Z

Thorsten Altenkirch wrote:
> I would like to encode Russell's paradox in Coq for my class, or more
> precisely Thierry's version of it (the paradox of trees). But how do I
> assume tat there is a set of all sets, or Set : Set?

You could always do a deep embedding of just the features of ZF needed
for your example.

It seems kind of ironic that it ends up being inconvenient not to be
able to apply inconsistent reasoning in Coq. ;)

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Russell's paradox

2008-11-28T08:12:58Z

Hi,

I would like to encode Russell's paradox in Coq for my class, or more
precisely Thierry's version of it (the paradox of trees). But how do I
assume tat there is a set of all sets, or Set : Set?

The easiest would be if there were a switch to switch off size
checking. Is there?

Ok, I could just assume that there is a set of all sets:

Variable set : Set.
Variable name : Set -> set.
Variable El : set -> Set.
Axiom reflect : forall A:Set,El (name A) = A.

but I got into trouble with this. While I can construct a function

fst : El (name { a:A | P a}) -> A.

I am having trouble with

snd : forall ap : El (name { a:A | P a}) ,P (fst ap)

Dually, there is no problem with

mk : forall a:A, (P a) -> El (name { a:A | P a})

but I also need

mkOk : forall (a:A) (p:P a) , fst (mk a p) = a

I suspect I need K (or I am just too stupid). Can anybody conform
either? I.e. can I prove this using Coq.Logic.Eqdep or without?

I attach my Russell file with the two additional assumptions I'd like
to eliminate.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Cheers,
Thorsten

l16-crib.v (1K) Download Attachment

From forum: Coq

Re: List OrderedType as OrderedType?

2008-11-27T04:56:16Z

As far as I know, subst only deals with Leibniz equalities (Logic.eq),
Im using it to remove the equalities introduced by the inversion
tactic. I've never encountered the issue you describe before (I'm
using the trunk version, but I dont know if it makes any difference).
In particular, the reason I use an alternate name "eq_" instead of
"eq" directly is not to avoid any name clash with the standard "eq",
but because of a (harmless, yet annoying) limitation that prevents one
from instantiating a Parameter in a module by an Inductive (hence the
use of "eq_" and the redefinition of "eq" afterwards).

SL

On Wed, Nov 26, 2008 at 9:07 PM, M. Scott Doerrie <mdoerri@...> wrote:

> Thanks. I'd started with a similar approach, but have stopped as I can use
> FSets for now. However, I noticed that you used a tactic that works for you
> but not me. I can't use the "subst" tactic, as it claims unification is
> impossible. However, I am reusing the "eq" name from the module instead of
> using "_eq" as you do. I changed the name to something other than "eq" and
> the tactic works. Why will "subst" fail to unify with a local "eq" but will
> unify with "_eq"? Is this a naming bug between local and FQ names in the
> tactic, or is it more fundamental?
>
> Scott Doerrie
>
> Stéphane Lescuyer wrote:
>>
>> On Wed, Nov 26, 2008 at 5:38 PM, Pierre Letouzey
>> <Pierre.Letouzey@...> wrote:
>>
>>>
>>> On Tue, Nov 25, 2008 at 02:56:21PM -0500, M. Scott Doerrie wrote:
>>>
>>>>
>>>> I've been searching the Coq standard library and have been unable to
>>>> find a functor that creates an OrderedType given an FSet or even a List
>>>> of OrderedTypes. This seems relatively straightforward given the
>>>> implementation of PairOrderedType, so I've probably missed it. I'd
>>>> rather not duplicate effort, so I thought I'd ask first.
>>>>
>>>> Scott Doerrie
>>>>
>>>>
>>>
>>> Concerning lists of OrderedType.t, FSetList.Make is building a
>>> FSetInterface.S whose base type is a sorted list attached with its
>>> sortedness proof. As before, this FSetInterface.S can be seen as an
>>> OrderedType. If you want to deal with arbitrary lists and not only the
>>> sorted ones, nothing exists yet in the standard library, but it should
>>> not be too difficult to build something (indeed, PairOrderedType can
>>> be a good source of inspiration). If you write this kind of functor,
>>> let me know, it might be interesting to include it in the standard
>>> library.
>>>
>>
>> I had actually written such a functor (see attached file) some time
>> ago, it builds an ordered type for lists with pointwise equality and
>> lexicographic order. [eq] and [lt] are defined as inductives rather
>> than functions because I find inversion really convenient.
>>
>> Hope this helps,
>>
>> Stéphane L.
>>
>>
>>
>
> --------------------------------------------------------
> Bug reports: http://logical.futurs.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'm the kind of guy that until it happens, I won't worry about it. -
R.H. RoY05, MVP06

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Re: List OrderedType as OrderedType?

2008-11-26T12:07:35Z

Thanks. I'd started with a similar approach, but have stopped as I can
use FSets for now. However, I noticed that you used a tactic that works
for you but not me. I can't use the "subst" tactic, as it claims
unification is impossible. However, I am reusing the "eq" name from the
module instead of using "_eq" as you do. I changed the name to
something other than "eq" and the tactic works. Why will "subst" fail
to unify with a local "eq" but will unify with "_eq"? Is this a naming
bug between local and FQ names in the tactic, or is it more fundamental?

Scott Doerrie

Stéphane Lescuyer wrote:

> On Wed, Nov 26, 2008 at 5:38 PM, Pierre Letouzey
> <Pierre.Letouzey@...> wrote:
>
>> On Tue, Nov 25, 2008 at 02:56:21PM -0500, M. Scott Doerrie wrote:
>>
>>> I've been searching the Coq standard library and have been unable to
>>> find a functor that creates an OrderedType given an FSet or even a List
>>> of OrderedTypes. This seems relatively straightforward given the
>>> implementation of PairOrderedType, so I've probably missed it. I'd
>>> rather not duplicate effort, so I thought I'd ask first.
>>>
>>> Scott Doerrie
>>>
>>>
>> Concerning lists of OrderedType.t, FSetList.Make is building a
>> FSetInterface.S whose base type is a sorted list attached with its
>> sortedness proof. As before, this FSetInterface.S can be seen as an
>> OrderedType. If you want to deal with arbitrary lists and not only the
>> sorted ones, nothing exists yet in the standard library, but it should
>> not be too difficult to build something (indeed, PairOrderedType can
>> be a good source of inspiration). If you write this kind of functor,
>> let me know, it might be interesting to include it in the standard
>> library.
>>
>
> I had actually written such a functor (see attached file) some time
> ago, it builds an ordered type for lists with pointwise equality and
> lexicographic order. [eq] and [lt] are defined as inductives rather
> than functions because I find inversion really convenient.
>
> Hope this helps,
>
> Stéphane L.
>
>
>

From forum: Coq

Re: List OrderedType as OrderedType?

2008-11-26T12:00:38Z

Thank you. That's what I was looking for.

Scott Doerrie

Pierre Letouzey wrote:

> On Tue, Nov 25, 2008 at 02:56:21PM -0500, M. Scott Doerrie wrote:
>
>> I've been searching the Coq standard library and have been unable to
>> find a functor that creates an OrderedType given an FSet or even a List
>> of OrderedTypes. This seems relatively straightforward given the
>> implementation of PairOrderedType, so I've probably missed it. I'd
>> rather not duplicate effort, so I thought I'd ask first.
>>
>> Scott Doerrie
>>
>>
>
> Well, if I remember correctly, the signature FSetInterface.S contains
> a compare function in particular, and others things required in a
> OrderedType, so any instance of this signature can be seen as an
> OrderedType by mere subtyping. This allows in particular to freely
> create sets of sets, or sets of sets of sets, and so on :
>
> Require Import FSets.
> Module NatSet := FSetAVL.Make Nat_as_OT.
> Module NatSetSet := FSetAVL.Make NatSet. (* here NatSet is seen as an OrderedType *)
>
> Concerning lists of OrderedType.t, FSetList.Make is building a
> FSetInterface.S whose base type is a sorted list attached with its
> sortedness proof. As before, this FSetInterface.S can be seen as an
> OrderedType. If you want to deal with arbitrary lists and not only the
> sorted ones, nothing exists yet in the standard library, but it should
> not be too difficult to build something (indeed, PairOrderedType can
> be a good source of inspiration). If you write this kind of functor,
> let me know, it might be interesting to include it in the standard
> library.
>
> Best regards,
> Pierre Letouzey
>
> --------------------------------------------------------
> Bug reports: http://logical.futurs.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
>

From forum: Coq

Re: List OrderedType as OrderedType?

2008-11-26T09:45:48Z

On Wed, Nov 26, 2008 at 5:38 PM, Pierre Letouzey
<Pierre.Letouzey@...> wrote:

> On Tue, Nov 25, 2008 at 02:56:21PM -0500, M. Scott Doerrie wrote:
>> I've been searching the Coq standard library and have been unable to
>> find a functor that creates an OrderedType given an FSet or even a List
>> of OrderedTypes. This seems relatively straightforward given the
>> implementation of PairOrderedType, so I've probably missed it. I'd
>> rather not duplicate effort, so I thought I'd ask first.
>>
>> Scott Doerrie
>>
> Concerning lists of OrderedType.t, FSetList.Make is building a
> FSetInterface.S whose base type is a sorted list attached with its
> sortedness proof. As before, this FSetInterface.S can be seen as an
> OrderedType. If you want to deal with arbitrary lists and not only the
> sorted ones, nothing exists yet in the standard library, but it should
> not be too difficult to build something (indeed, PairOrderedType can
> be a good source of inspiration). If you write this kind of functor,
> let me know, it might be interesting to include it in the standard
> library.

I had actually written such a functor (see attached file) some time
ago, it builds an ordered type for lists with pointwise equality and
lexicographic order. [eq] and [lt] are defined as inductives rather
than functions because I find inversion really convenient.

Hope this helps,

Stéphane L.

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

ListOrderedType.v (4K) Download Attachment

From forum: Coq

Re: List OrderedType as OrderedType?

2008-11-26T08:38:00Z

On Tue, Nov 25, 2008 at 02:56:21PM -0500, M. Scott Doerrie wrote:
> I've been searching the Coq standard library and have been unable to
> find a functor that creates an OrderedType given an FSet or even a List
> of OrderedTypes. This seems relatively straightforward given the
> implementation of PairOrderedType, so I've probably missed it. I'd
> rather not duplicate effort, so I thought I'd ask first.
>
> Scott Doerrie
>

Well, if I remember correctly, the signature FSetInterface.S contains
a compare function in particular, and others things required in a
OrderedType, so any instance of this signature can be seen as an
OrderedType by mere subtyping. This allows in particular to freely
create sets of sets, or sets of sets of sets, and so on :

Require Import FSets.
Module NatSet := FSetAVL.Make Nat_as_OT.
Module NatSetSet := FSetAVL.Make NatSet. (* here NatSet is seen as an OrderedType *)

Concerning lists of OrderedType.t, FSetList.Make is building a
FSetInterface.S whose base type is a sorted list attached with its
sortedness proof. As before, this FSetInterface.S can be seen as an
OrderedType. If you want to deal with arbitrary lists and not only the
sorted ones, nothing exists yet in the standard library, but it should
not be too difficult to build something (indeed, PairOrderedType can
be a good source of inspiration). If you write this kind of functor,
let me know, it might be interesting to include it in the standard
library.

Best regards,
Pierre Letouzey

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

CADE-22 final call for workshop and tutorial proposals

2008-11-26T08:15:15Z

CADE 2009
The 22nd International Conference on Automated Deduction
Montreal, Canada, August 2 - 7, 2009

http://complogic.cs.mcgill.ca/cade22/

Call for Workshop and Tutorial Proposals
----------------------------------------------------

CADE 2009 is the 22nd International Conference on Automated Deduction,
the premier conference on all aspects of automated deduction. Topics
covered range from theoretical foundations to high-performance
implementations in a wide variety of logics and logical theories, with
applications in areas like verification and artificial intelligence.

Workshop and tutorial proposals for CADE 2009 are solicited. Both
well-established workshops and newer or brand new ones are encouraged.
Similarly, proposals for workshops with a tight focus on a core
automated reasoning specialization, as well as those with a broader,
more applied focus, are very welcome.

1. Workshop Proposals

Please provide the following information:

+ Workshop title.
+ Names and affiliations of organizers.
+ Brief description of workshop goals and/or topics.
+ Proposed workshop duration
(from half a day to two days is possible).
+ If the workshop has met previously, please include the conference
affiliation for the previous meeting. If the workshop is new,
please indicate so.

The CADE organizers plan to make available a small amount towards
partial reimbursement for travel expenses of invited speakers.
Also, CADE will take care of printing and distributing informal
proceedings for workshops that would like this service.

2. Tutorial Proposals

Tutorials are expected to be half-day events. Tutorial proposals
should provide the following information:

+ Tutorial title.
+ Names and affiliations of organizers.
+ Brief description of the tutorial's goals and topics to be
covered.
+ Whether or not a version of the tutorial has been given
previously.

CADE will take care of printing and distributing notes for
tutorials that would like this service.

All proposals should be sent via email in plain text to the Workshop
and Tutorial Chair (astump@...), for consideration by the
CADE 2009 organizers:

Brigitte Pientka (McGill University), General Chair
Renate Schmidt (University of Manchester), Program Chair
Carsten Schuermann (IT University of Copenhagen), Publicity Chair
Aaron Stump (The University of Iowa), Workshop and Tutorial Chair

Important dates:
Deadline for proposal submissions: December 7, 2008
Acceptance/rejection notification: January 7, 2009
Workshop dates: August 2-3, 2009
-------------------------------------------------------------------

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Internship proposals

2008-11-25T18:11:49Z

Dear all, I propose to master students various subjects for extending
CoLoR and Rainbow that are described in
http://www.loria.fr/~blanqui/subject-color.html. Please, feel free to
forward these proposals to your students. Best regards, Frederic Blanqui.

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

List OrderedType as OrderedType?

2008-11-25T11:56:21Z

I've been searching the Coq standard library and have been unable to
find a functor that creates an OrderedType given an FSet or even a List
of OrderedTypes. This seems relatively straightforward given the
implementation of PairOrderedType, so I've probably missed it. I'd
rather not duplicate effort, so I thought I'd ask first.

Scott Doerrie

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Coq & Java applet

2008-11-25T01:34:37Z

Hi,

For those who may be interested on building java applets on top
of extracted Coq code, I've just discovered the ocamljava project:

http://ocamljava.x9c.fr/

This works pretty well (performance is not outstanding though).
Here is an example with my Sudoku solver

http://www-sop.inria.fr/marelle/Laurent.Thery/Sudoku/Sudoku.html

--
Laurent

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Re: Re: Agda beats Coq

2008-11-24T16:13:01Z

> You can't actually achieve this for infinite values like the above, so to
> usefully prove their equality, you'd have to add an extensionality axiom like
> you suggest. But in principle, bisimilarity means that you could prove two
> values intensionally equal through evaluation (the equality just isn't
> decidable).

You are right indeed, mea culpa for that. Bisimilarity allows
coinductive reasoning which are more powerful than reasoning with
intentional equality (which only allows to look at a finite prefix,
although of arbitrary length).

Therefore you will only have properties such as the following (still
contestable, in my opinion):

CoInductive stream (A:Type) : Type :=
| cons : A -> stream A -> stream A
.

Definition hd (A:Type) (s:stream A) :=
match s with
| cons a _ => a
end
.
Implicit Arguments hd [ A ].

Definition tl (A:Type) (s:stream A) :=
match s with
| cons _ t => t
end
.
Implicit Arguments tl [ A ].

CoInductive bisim (A:Type) (s1 s2:stream A) :Prop :=
| mk_bisim : hd s1 = hd s2 -> bisim _ (tl s1) (tl s2) -> bisim _ s1 s2
.

Fixpoint tln (A:Type) (s:stream A) (n:nat) {struct n} : stream A :=
match n with
| 0 => s
| S n' => tln _ (tl s) n'
end
.

Goal forall A n (s1 s2:stream A), tln _ s1 n = tln _ s2 n -> bisim _ s1 s2 -> s1 = s2.
intro A. induction n.
trivial.

intros [ h1 s1 ] [ h2 s2 ] t [ h b ].
simpl in *. rewrite h.
rewrite (IHn s1 s2); trivial.
Qed.

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq

Re: Re: Agda beats Coq

2008-11-24T14:37:53Z

On Monday 24 November 2008 5:19:37 pm Aaron Bohannon wrote:

> I reviewed the previous coq-list thread on coinduction and I
> understand why people are not completely happy with the current
> situation. Among the proposals for remedying the situation was the
> suggestion that we add an axiom asserting that bisimilarity implies
> intentional equality for each datatype. I take this to mean that some
> people believe this to be sound, although I am apparently not the only
> to stop and question it. Of course, this is a moot point for
> datatypes where you could actually build a proof in Coq of such a
> proposition. Does the proof rely on some other axioms? Do you mind
> sharing your proof or a reference to one?

I believe, though I am not sure, that he is referring to a fact that if you
can prove bisimilarity of two values, like:

i ~ cosuc i

j = anaConat inr 5

Then you can also imagine performing a(n infinite) series of reductions of said
values to demonstrate that they are, in fact, intensionally equal as Coq/Agda
defines it. Namely, both have a 'normal form' of:

cosuc (cosuc (cosuc (cosuc ...)))

You can't actually achieve this for infinite values like the above, so to
usefully prove their equality, you'd have to add an extensionality axiom like
you suggest. But in principle, bisimilarity means that you could prove two
values intensionally equal through evaluation (the equality just isn't
decidable).

-- Dan

--------------------------------------------------------
Bug reports: http://logical.futurs.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

From forum: Coq