Workshop “Dependability and Security in e-Government” (DeSeGov 2006)

From pierre.casteran at !NS! labri.fr Mon Jan 9 06:34:28 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Mon, 09 Jan 2006 07:34:28 +0100 Subject: [Coq-Club]JFLA 2006 : Call to participation (in French) Message-ID: <43C203F4.1090409@labri.fr> (Sorry for multiple copies) Je retransmets le second appel à participation aux Journées Francophones des lalngages applicatifs (message original de Thérèse Hardin, préseidente des JFLA 2006. Pierre ------------------------------------------------------------------------------------------------------------------------------- Bonjour, Voici l'appel à participation aux JFLA 2006: http://jfla.inria.fr/ 2006/index.html Innovations 2006 : "COQ au Pauillac et aux Omégas" avec Pierre Casteran, "FOCALiser sous les auspices de Zenon" avec D. Delahaye et C. Morisset, des cours-présentations destinés à ceux qui n'ont jamais manipulé ces langages ainsi qu'aux utilisateurs chevronnés. Nous aurons également deux conférences invitées, l'une par Mark van den Brand (CWI Amsterdam) sur "Les applications de la réécriture avec ASF +SDF", l'autre par Choukri Ben-Yellès (IUT Valence) sur "Enseigner Ocaml en IUT : pourquoi, comment?". Une session de démonstrations d'outils a également été prévue. Pouvez- vous envoyer vos propositions de démonstration à jfla2006@loria.fr. Merci d'avance. La communauté des JFLA souhaite s'ouvrir à toutes les approches de spécification et de programmation rejoignant son souci de développement de logiciels plus sûrs. C'est pourquoi nous aurons également une présentation de l'activité de la communauté AFADL. En espérant partager avec vous toute la richesse scientifique des JFLA'06 ainsi que toutes les spécialités de la ville de Pauillac (elles "méritent le détour"), dans l'ambiance traditionnellement conviviale de ces Journées. Très cordialement Thérèse Hardin, Présidente du Comité de programme From thery at !NS! ns.di.univaq.it Mon Jan 9 16:35:00 2006 From: thery at !NS! ns.di.univaq.it (Thery Laurent) Date: Mon, 9 Jan 2006 17:35:00 +0100 (CET) Subject: [Coq-Club]Elliptic Curves in Coq In-Reply-To: References: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-750006563-1136824500=:12848 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE > Has anyone done any of the theory of elliptic curves in Coq? > I've just been starting a formalisation to apply it to number theory but I= =20 haven't gone very far (I'm stuck in the proof that the group operation is= =20 associative). Otherwise Marie Virat () did some stuff= =20 with elliptic curve in Coq. Also Joe Hurd ()=20 did something but in the HOL prover. -- Laurent Th=E9ry --8323328-750006563-1136824500=:12848-- From nwhitehe at !NS! cs.ucsc.edu Wed Jan 11 22:35:58 2006 From: nwhitehe at !NS! cs.ucsc.edu (Nathan Whitehead) Date: Wed, 11 Jan 2006 14:35:58 -0800 Subject: [Coq-Club]Prolog in Coq Message-ID: <7db362a90601111435mb01e7c4wcced3c9648ea526c@mail.gmail.com> ------=_Part_18427_30681308.1137018958952 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Has anyone done Prolog in Coq, and extracted a correct Prolog interpreter? (Or any kind of simplified Prolog). -- Nathan Whitehead ------=_Part_18427_30681308.1137018958952 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Has anyone done Prolog in Coq, and extracted a correct Prolog interpreter?&= nbsp; (Or any kind of simplified Prolog).
--
Nathan Whitehead

------=_Part_18427_30681308.1137018958952-- From tarmo at !NS! cs.ioc.ee Sat Jan 7 11:39:26 2006 From: tarmo at !NS! cs.ioc.ee (Tarmo Uustalu) Date: Sat, 07 Jan 2006 13:39:26 +0200 Subject: [Coq-Club]MPC 2006 2nd Call for Papers Message-ID: <20060107113919.8DF44BF08F@sool.cc.ioc.ee> NEWS: - Invited speakers: = Robin Cockett, University of Calgary Olivier Danvy, Aarhus Universitet Oege de Moor, University of Oxford = - The paper submission system is open. - Two satellite workshops: Constructive Methods for Parallel Programming, CMPP Mathematically Structured Functional Programming, MSFP SECOND CALL FOR PAPERS 8th International Conference on = Mathematics of Program Construction MPC '06 Kuressaare, Estonia, 3-5 July 2006 http://cs.ioc.ee/mpc-amast06/mpc/ colocated with AMAST '06 Background The biennial MPC conferences aim to promote the development of mathematical principles and techniques that are demonstrably useful and usable in the process of constructing computer programs. Topics of interest range from algorithmics to support for program construction in programming languages and systems. The previous conferences were held in Twente, The Netherlands (1989), Oxford, UK (1992), Kloster Irsee, Germany (1995), Marstrand, Sweden (1998), Ponte de Lima, Portugal (2000), Dagstuhl, Germany (2002) and Stirling, UK (2004, colocated with AMAST '04). The 2006 conference will be held at Kuressaare, Estonia, colocated with AMAST '06. Invited speakers Robin Cockett, University of Calgary Olivier Danvy, Aarhus Universitet Oege de Moor, University of Oxford Important dates * Submission of abstracts: 27 January 2006 * Submission of full papers: 3 February 2006 * Notification of authors: 17 March 2006 * Camera-ready version: 14 April 2006 Topics Papers are solicited on mathematical methods and tools put to use in program construction. Topics of interest range from algorithmics to support for program construction in programming languages and systems. Some typical areas are type systems, program analysis and transformation, programming language semantics, program logics. Theoretical contributions are welcome provided their relevance for program construction is clear. Reports on applications are welcome provided their mathematical basis is evident. Submission and publication Submission is in two stages. Abstracts (plain text) must be submitted by 27 January 2006. Full papers (pdf) adhering to the llncs style must be submitted by 3 February 2006. There is no official page limit, but authors should strive for brevity. The web-based submission system is open. Papers must report previously unpublished work and not be submitted concurrently to another conference with refereed proceedings. PC members may submit. Accepted papers must be presented at the conference by one of the authors. The proceedings of MPC '06 will be published in the Lecture Notes in Computer Science series of Springer-Verlag. After the conference, the authors of the best papers will be invited to submit revised versions to a special issue of the Science of Computer Programming journal of Elsevier. = Programme committee Tarmo Uustalu, Institute of Cybernetics, Tallinn (chair) Roland Backhouse, University of Nottingham Eerke Boiten, University of Kent Venanzio Capretta, University of Ottawa Sharon Curtis, Oxford Brookes University Jules Desharnais, Universit=E9 de Laval Jeremy Gibbons, University of Oxford Lindsay Groves, Victoria University of Wellington Ian Hayes, University of Queensland William Harrison, University of Missouri Johan Jeuring, Universiteit Utrecht Dexter Kozen, Cornell University Christian Lengauer, Universit=E4t Passau Lambert Meertens, Kestrel Institute Bernhard M=F6ller, Universit=E4t Augsburg Shin-Cheng Mu, University of Tokyo Jos=E9 Oliveira, Universidade do Minho Alberto Pardo, Universidad de la Rep=FAblica Ross Paterson, City University London Ingrid Rewitzky, University of of Stellenbosch Varmo Vene, University of Tartu Satellite workshops Two workshops will be held in conjunction with MPC 2006 as satellites on 2 July 2006: 5th International Workshop on Constructive Methods for = Parallel Programming, CMPP 2006 Workshop on Mathematically Structured Functional Programming, = MSFP 2006 Venue Kuressaare (pop. 16000) is the main town on Saaremaa, the second-largest island of the Baltic Sea. Kuressaare is a charming seaside resort on the shores of the Gulf of Riga highly popular with Estonians as well as visitors to Estonia. The scientific sessions of MPC/AMAST 2006 will take place at Saaremaa Spa Hotel Meri, one among the several new spa hotels in the town. The social events will involve a number of sites, including the 14th-century episcopal castle. Accommodation will be at Saaremaa Spa Hotels Meri and R=FC=FCtli. To get to Kuressaare and away, one must pass through Tallinn (pop. 402000), Estonia's capital city. Tallinn is famous for its picturesque medieval Old Town, inscribed on UNESCO's World Heritage List. Local organizers MPC/AMAST 2006 is organized by Institute of Cybernetics, a research institute of Tallinn University of Technology. The local organizers are Tarmo Uustalu (chair), Monika Perkmann, Juhan Ernits, Ando Saabas, Olha Shkaravska, Kristi Uustalu. Contact email address: mpc06(at)cs.ioc.ee. From adamc at !NS! argus.EECS.Berkeley.EDU Mon Jan 9 12:46:37 2006 From: adamc at !NS! argus.EECS.Berkeley.EDU (Adam Chlipala) Date: Mon, 9 Jan 2006 04:46:37 -0800 (PST) Subject: [Coq-Club]Inductive definitions in the Calculus of Constructionsa Message-ID: I know that the Calculus of Inductive Constructions was created because the Calculus of Constructions was insufficient to represent some inductive types. Can anyone on this list give a short characterization of which types require this extension, and/or perhaps the simplest example of such a type? I'm interested in this in the context of trying to minimize the trusted code base needed to use results proved with Coq. If compiled developments can be translated to the Calculus of Constructions, then I imagine it's possible to use a significantly simpler checker. From varmo at !NS! cs.ut.ee Mon Jan 9 22:36:39 2006 From: varmo at !NS! cs.ut.ee (Varmo Vene) Date: Tue, 10 Jan 2006 00:36:39 +0200 Subject: [Coq-Club]AMAST 2006 2nd Call for Papers Message-ID: <20060109223639.GF9161@remus.at.mt.ut.ee> SECOND CALL FOR PAPERS 11th International Conference on Algebraic Methodology and Software Technology, AMAST '06 colocated with MPC '06 Kuressaare, Estonia, 5-8 July 2006 http://cs.ioc.ee/mpc-amast06/amast/ Background The major goal of the AMAST conferences is to promote research that may lead to the setting of software technology on a firm, mathematical basis. This goal is advanced by a large international cooperation with contributions from both academia and industry. The virtues of a software technology developed on a mathematical basis have been envisioned as being capable of providing software that is (a) correct, and the correctness can be proved mathematically, (b) safe, so that it can be used in the implementation of critical systems, (c) portable, i.e., independent of computing platforms and language generations, and (d) evolutionary, i.e., it is self-adaptable and evolves with the problem domain. The previous conferences were held in Iowa City, Iowa, USA (1989, 1991 and 2000), Twente, The Netherlands (1993), Montreal, Canada (1995), Munich, Germany (1996), Sydney, Australia (1997), Manaus, Amazonia, Brazil (1998), Reunion Island, France (2002) and Stirling, UK (2004, colocated with MPC' 04). The 2006 conference will be held at Kuressaare, Estonia, colocated with MPC '06. The conference series has become widely known for disseminating academic and industrial achievements within the broad AMAST areas of interest. Through these meetings AMAST has attracted an international following among researchers and practitioners interested in software technology, programming methodology and their algebraic and logical foundations. Important dates * Submission of abstracts: 27 January 2006 * Submission of full papers: 3 February 2006 * Notification of authors: 17 March 2006 * Camera-ready version: 14 April 2006 Topics Topics of interest include, but are not limited to, the following: * Software technology: systems software technology, application software technology, concurrent and reactive systems, formal methods in industrial software development, formal techniques for software requirements/design, evolutionary software/adaptive systems. * Programming methodology: logic programming, functional programming, object paradigms, constraint programming and concurrency, program verification and transformation, programming calculi, specification languages and tools, formal specification and development case studies. * Algebraic and logical foundations: logic, category theory, relation algebra, computational algebra, algebraic foundations for languages and systems, coinduction, theorem proving and logical frameworks for reasoning, logics of programs, algebra and coalgebra. * Systems and tools (for system demonstrations or ordinary papers): software development environments, support for correct software development, system support for reuse, tools for prototyping, component based software development tools, validation and verification, computer algebra systems, theorem proving systems. Submission and publication Two kinds of submissions are solicited for this conference: technical papers and system demonstrations. Papers may report academic or industrial progress, and papers which deal with both are especially well-regarded. Submission is in two stages. Abstracts (plain text) must be submitted by 27 January 2006. Full papers (pdf) adhering to the llncs style and not longer than 15 pages (6 pages for system demonstrations) must be submitted by 3 February 2006. The web-based submission system is open. Papers must report previously unpublished work and not be submitted concurrently to another conference with refereed proceedings. Accepted papers must be presented at the conference by one of the authors. All papers will be refereed by the programme committee, and will be judged based on their significance, technical merit, and relevance to the conference. The proceedings of AMAST '06 will be published in the Lecture Notes in Computer Science series of Springer-Verlag. Programme Committee Michael Johnson, Macquarie University (co-chair) Varmo Vene, University of Tartu (co-chair) Luís Barbosa, Universidade do Minho Gilles Barthe, INRIA Sophia-Antipolis Michel Bidoit, École Normale Supérieure de Cachan Gregor v. Bochmann, University of Ottawa Manfred Broy, Technische Universität München Cristian Calude, University of Auckland Christine Choppy, Université Paris Nord Arthur Fleck, University of Iowa Marcelo Frias, Universidad de Buenos Aires Nicolas Halbwachs, Université Grenoble I / CNRS Anne Haxthausen, Technical University of Denmark Antonia Lopes, Universidade de Lisboa Michael Mislove, Tulane University Peter Mosses, University of Wales Swansea Monica Nesi, Università degli Studi di L'Aquila Rocco De Nicola, Università degli Studi di Firenze Anton Nijholt, Universiteit Twente Dusko Pavlovic, Kestrel Institute Jaco van de Pol, CWI Charles Rattray, University of Stirling Teodor Rus, University of Iowa Giuseppe Scollo, Università degli Studi di Verona Carolyn Talcott, SRI International Andrzej Tarlecki, Warsaw University Ken Turner, University of Stirling Irek Ulidowski, University of Leicester Martin Wirsing, Ludwig-Maximilians-Universität München AMAST steering committee Egidio Astesiano, Universita degli Studi di Genova Robert Berwick, MIT Zohar Manna, Stanford University Michael Mislove, Tulane University Anton Nijholt, University of Twente Maurice Nivat, Universite Paris 7 Charles Rattray, University of Stirling Teodor Rus, University of Iowa Giuseppe Scollo, Universita degli Studi di Verona Michael Sintzoff, Universite Catholique de Louvain Jeannette Wing, Carnegie Mellon University Martin Wirsing, Ludwig-Maximilians-Universitaet Muenchen Michael Johnson, Macquarie University (chair) Venue Kuressaare (pop. 16000) is the main town on Saaremaa, the second-largest island of the Baltic Sea. Kuressaare is a charming seaside resort on the shores of the Gulf of Riga highly popular with Estonians as well as visitors to Estonia. The scientific sessions of MPC/AMAST 2006 will take place at Saaremaa Spa Hotel Meri, one among the several new spa hotels in the town. The social events will involve a number of sites, including the 14th-century episcopal castle. Accommodation will be at Saaremaa Spa Hotels Meri and Ruutli. To get to Kuressaare and away, one must pass through Tallinn (pop. 402000), Estonia's capital city. Tallinn is famous for its picturesque medieval Old Town, inscribed on UNESCO's World Heritage List. Local organizers MPC/AMAST 2006 is organized by Institute of Cybernetics, a research institute of Tallinn Univ. of Technology. The local organizers are Tarmo Uustalu (chair), Monika Perkmann, Juhan Ernits, Ando Saabas, Olha Shkaravska, Kristi Uustalu. Contact email addresses: mike(at)ics.mq.edu.au, varmo(at)cs.ut.ee. From tho at !NS! ifs.tuwien.ac.at Tue Jan 10 13:53:50 2006 From: tho at !NS! ifs.tuwien.ac.at (Nguyen Manh Tho) Date: Tue, 10 Jan 2006 14:53:50 +0100 Subject: [Coq-Club]CFP: Workshop Dependability and Security in e-Government(DeSeGov 2006) - Submission Deadline 20-01-2006 Message-ID: <014001c615ed$49452ae0$35a8a8c0@manhtho> This is a multi-part message in MIME format. ------=_NextPart_000_0141_01C615F5.AB0992E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Workshop "Dependability and Security in e-Government" (DeSeGov 2006) www.ares-conf-org/?q=DeSeGov Vienna, April 20th -22nd 2006 in conjunction with The First International Conference on Availability, Reliability and Security ( ARES 2006 ) Call for Papers Many governments have now significant e-government applications that offer more and more the day-to-day services to the citizen. ICT infrastructure has become as important as government offices and its officials: crucial for the functioning of the state. Modern government is today dependent on its functioning ICT: the systems must be available, reliable, safe, confidential, integer and secure. The aim of this workshop is to foster a forum for discussing and presenting recent research results on dependability and security in e-Government applications. Scientific rigor and discussions of state of the art of dependability and security in e-Government are strongly encouraged. Besides, innovative research work in progress and studies of dependability aspects of practical e-Government projects and systems implementation are also welcome. Topics of interest include, although not limited to, the following: . Trust and security: provisions and instruments . Online availability of public services . Service survivability and maintainability . Interoperability of services . Security in e-democracy (including e-participation and e-voting) . E-justice (administration and workflow security for legal processes) . Secure federating information access (from different government and third party agencies) . Security and reliability in media integration . Secure e-government and Identity Management . Security and reliability of Smart Card System . Availability and reliability of mobile services . Data protection and data privacy (e.g. e-health and e-education) . Intrusion detection and prevention . Anti-spam legislation and solution . Public-private- partnerships management . Role-based management and usage restriction Important Dates Submission Deadline: January, 20th 2006 Author Notification: February, 1st 2006 Author Registration: February, 7th 2006 Proceedings Version: February, 7th 2006 Submission Guidelines The proceedings of this workshop will be published by IEEE. Authors are invited to submit their papers in the IEEE Computer Society Proceedings Manuscripts format (two columns, single-spaced, including figures and references, using 10 fonts, and number each page). The IEEE Computer Society Proceedings Author Guidelines are available at the following web page: URL: http://computer.org/cspress/instruct.htm or http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm Submission are classified into 3 categories (1) full paper (8 pages), (2) short paper (5 pages), and (3) poster (2 pages) representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Contact author must provide the following information: paper title, authors' names, affiliations, postal address, phone, fax, and e-mail address of the author(s), about 200-250 word abstract, and about five keywords and register at our ARES website: http://www.ares-conf.org/?q=submission. Prepare your paper in PDF or MS Word file and submit it to our site at http://www.ares-conf.org/?q=submission Submission of a paper implies that should the paper be accepted, at least one of the authors will register and present the paper in the conference. Accepted papers will be given guidelines in preparing and submitting the final manuscript(s) together with the notification of acceptance. Publication All accepted papers (full and short papers) will be published by IEEE Computer Society. Workshop Chairpersons A Min Tjoa, Vienna University of Technology, Austria Erich Schweighofer, University of Vienna, Austria Programme Committee * Peggy Agouris, University of Maine, USA * Yigal Arens, USC/Columbia University Digital Government Research Center, USA * Jon Bing, University of Oslo, Norway * Fernando Galindo, University of Zaragoza, Spain * Dieter Klumpp, Alcatel SEL Foundation, Germany * Robert Krimmer, Vienna University of Economics and Business Administration, Austria * Scott F. Midkiff, Virginia Polytechnic Institute and State University,USA * Enrico Nardelli, University of Rome TorVergata, Italy * Tho Manh Nguyen, Vienna University of Technology, Austria * Erich Schweighofer, University of Vienna, Austria * Efthimios Tambouris, CERTH/ITI, Greece * A Min Tjoa, Vienna University of Technology, Austria * Greg B. White, The University of Texas at San Antonio, USA ** Maria A. Wimmer, University of Koblenz, Germany ------=_NextPart_000_0141_01C615F5.AB0992E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Workshop “Dependability and Security in e-Government” (DeSeGov 2006)

Workshop “Dependability and Security in e-Government” (DeSeGov 2006)

www.ares-conf-org/?q=3D= DeSeGov

Vienna, April 20th -22nd = 2006

in conjunction with The First International Conference on Availability, Reliability and Security = (= ARES = 2006 )

Call for = Papers

= Many governments have now significant = e-government applications that offer more and more the day-to-day services to the = citizen. ICT infrastructure has become as important as government offices and its officials: crucial for the functioning of the state. Modern government = is today dependent on its functioning ICT: the systems must be available, = reliable, safe, confidential, integer and secure.

= The aim of this workshop is to foster a forum = for discussing and presenting recent research results on dependability and = security in e-Government applications. Scientific rigor and discussions of state = of the art of dependability and security in e-Government are strongly = encouraged. Besides, innovative research work in progress and studies of = dependability aspects of practical e-Government projects and systems implementation = are also welcome.

= Topics of interest include, although not = limited to, the following:

= • Trust and security: provisions and = instruments
• Online availability of public services
• Service survivability and maintainability
• Interoperability of services
• Security in e-democracy (including e-participation and = e-voting)
• E-justice (administration and workflow security for legal = processes)
• Secure federating information access (from different government = and third party agencies)
• Security and reliability in media integration
• Secure e-government and Identity Management
• Security and reliability of Smart Card System
• Availability and reliability of mobile services
• Data protection and data privacy (e.g. e-health and = e-education)
• Intrusion detection and prevention
• Anti-spam legislation and solution
• Public-private- partnerships management
• Role-based management and usage = restriction

Important Dates =

= Submission Deadline: = January, 20th = 2006
Author Notification: = February, 1st = 2006
Author Registration: = February, 7th = 2006
Proceedings Version: = February, 7th = 2006

Submission Guidelines =

= The proceedings of this workshop will be = published by IEEE. Authors are invited to submit their papers in the IEEE Computer = Society Proceedings Manuscripts format (two columns, single-spaced, including = figures and references, using 10 fonts, and number each page). The IEEE Computer Society Proceedings Author Guidelines are available at the following web = page:

= URL: http://computer.org/cs= press/instruct.htm
or http://www.tinmith.net= /tabletop2006/IEEE/Format/instruct.htm

= Submission are classified into 3 categories (1) = full paper (8 pages), (2) short paper (5 pages), and (3) poster (2 pages) representing original, previously unpublished work. Submitted papers = will be carefully evaluated based on originality, significance, technical = soundness, and clarity of exposition.

= Contact author must provide the following = information: paper title, authors' names, affiliations, postal address, phone, fax, = and e-mail address of the author(s), about 200-250 word abstract, and about = five keywords and register at our ARES website: http://www.ares-conf.o= rg/?q=3Dsubmission. Prepare your paper = in PDF or MS Word file and submit it to our site at http://www.ares-conf.o= rg/?q=3Dsubmission

= Submission of a paper implies that should the = paper be accepted, at least one of the authors will register and present the = paper in the conference. Accepted papers will be given guidelines in preparing = and submitting the final manuscript(s) together with the notification of acceptance.

Publication =

= All accepted papers (full and short papers) = will be published by IEEE Computer Society.

Workshop = Chairpersons

= A Min Tjoa, = Vienna<= /st1:place> = University of Technology, = Austria=
Erich Schweighofer, University of Vienna, = Austria=

Programme = Committee

· Peggy Agouris, University of Maine, = USA

· Yigal Arens, USC/Columbia = University Digital Government Research Center, USA

· Jon Bing, University of Oslo, = Norway

· Fernando Galindo, University of = Zaragoza, Spain

· Dieter Klumpp, Alcatel SEL = Foundation, Germany

· Robert Krimmer, Vienna University = of Economics and Business Administration, Austria =

· Scott F. Midkiff, Virginia = Polytechnic Institute and State = University,USA=

· Enrico Nardelli, University of Rome TorVergata, Italy

· Tho Manh Nguyen, Vienna University = of Technology, Austria

· Erich Schweighofer, University of = Vienna, Austria

· Efthimios Tambouris, CERTH/ITI, = Greece

· A Min Tjoa, Vienna University of = Technology, Austria

· Greg B. White, The = University of Tex= as at San Antonio, USA= =

· = Maria A. Wimmer, University of Koblenz, = Germany

------=_NextPart_000_0141_01C615F5.AB0992E0-- From mencl at !NS! nenya.ms.mff.cuni.cz Thu Jan 12 16:38:53 2006 From: mencl at !NS! nenya.ms.mff.cuni.cz (Vladimir Mencl) Date: Thu, 12 Jan 2006 17:38:53 +0100 (CET) Subject: [Coq-Club]CfP: FACS'06 - Formal Aspects of Component Software Message-ID: <20060112163853.85054D9EFF@nenya.ms.mff.cuni.cz> [Our apologies should you receive multiple copies of this CfP.] ================================================================== Third International Workshop on Formal Aspects of Component Software (FACS'06), First Call for Papers Prague, Czech Republic September 20 -- 22, 2006 FACS'06 is the third in a series of workshops, founded by the International Institute for Software Technology of the United Nations University. The first FACS workshop was held in Pisa, Italy, in September 2003, collocated with FM'03. Subsequently, FACS'05 was held as a standalone event at the United Nations University in Macau, October 24-25, 2005. Workshop Scope and Topics ========================= Component-based software emerged as a promising paradigm to deal with the ever increasing need for mastering systems' complexity, their evolution and reuse, and driving software engineering into sound production and engineering standards. Soon, however, it became a popular technology long before consensual definitions and principles, let alone formal foundations, have been put forward. Issues like mathematical models for components, their interaction and composition, or rigorous approaches to verification, deployment, testing and certification remain open research questions and challenging opportunities for formal methods. Moreover, new challenges are raised by applications of this paradigm to safety-critical, mobile, and embedded systems. The objective of FACS'06 is to bring together researchers in the areas of component software and formal methods to promote a deep understanding of this paradigm and its applications. The workshop will also be interested in defining the common aspects of components and component-based development. It is expected that formal paper presentations will be followed by lively debate in a stimulating atmosphere. Possible topics include, but are not limited to: * formal models for software components and component interaction * design and verification methods for component software * component composition and deployment: models, calculi, languages * component testing * specification of extra-functional properties in component software * certification of components and software architectures * component software vs object orientation * components for real-time, safety-critical, secure and/or embedded systems * experience reports and case studies in component software * partial behavior models for software components * update and reconfiguration of component architectures * formal methods and modeling languages * trust models for components FACS'06 is the third in a series of workshops, founded by the International Institute for Software Technology of the United Nations University (UNU-IIST). The first FACS workshop was held in Pisa, Italy, in September 2003, collocated with FM'03. Next, FACS'05 was organized as a standalone event in October 2004 at UNU-IIST. This has been considered by the workshop participants as a very successful meeting with collaborative atmosphere and friendly discussion. Considering the persisting interest of the participants in the topics, FACS'06 was scheduled again as a separate event, this time to be hosted by the Charles University in Prague, Czech Republic, in September 2006. Program Committee ================= * Farhad Arbab (CWI, The Netherlands) * Luis Barbosa (Universidade do Minho, Portugal) * Frank S. de Boer, (PC Chair, CWI, The Netherlands) * Marcello Bonsangue (LIACS-Leiden University, The Netherlands) * Christiano Braga (Universidade Federal Fluminense, Brazil) * Manfred Broy (Technical University of Munich, Germany) * Carlos Canal (Universidad de Malaga, Spain) * Paolo Ciancarini (Universita di Bologna, Italy) * Thierry Coupaye (France Telecom R&D, France) * Joao Faria (Universidade do Porto, Portugal) * Jose Fiadeiro (University of Leicester, United Kingdom) * Susanne Graf (VERIMAG, France) * Martin Grosse-Rhode (Fraunhofer-ISST, Germany) * Rolf Hennicker (Ludwig-Maximilians-Universitaet Muenchen, Germany) * He Jifeng (East China Normal University, China) * Einar Broch Johnsen (Universitetet i Oslo, Norway) * Bengt Jonsson (Uppsala University, Sweden) * Mathai Joseph (Tata Consultancy Services Limited, India) * Atsushi Igarashi (Kyoto University, Japan) * Kung-Kiu Lau (The University of Manchester, United Kingdom) * Zhiming Liu (UNU-IIST, Macao) * Markus Lumpe (Iowa State University, USA) * Eric Madelaine (INRIA, Centre Sophia Antipolis, France) * Vladimir Mencl (PC Chair, UNU-IIST, Macao and Charles Univ., Czech Rep.) * Sun Meng (National University of Singapore, Singapore) * Frantisek Plasil (Charles University, Czech Republic) * Anders Ravn (Aalborg University, Denmark) * Ralf Reussner (University of Oldenburg, Germany) * Bernhard Schaetz (Technical University of Munich, Germany) * Joseph Sifakis (VERIMAG, France) * Jean-Bernard Stefani (INRIA Rhones-Alpes, France) * Carolyn Talcott (SRI International, USA) Important Dates =============== Submission deadline: June 11, 2006 Acceptance notification: July 23, 2006 Camera ready version due: Aug 20, 2006 Workshop: September 20-22, 2006 Submission & Proceedings ======================== Submissions to the workshop will be judged on the basis of originality, relevance, technical soundness and presentation quality. Papers should be written in English and not exceed 15 pages in ENTCS format. The workshop proceedings will be published in Electronic Notes in Theoretical Computer Science, Elsevier, as post-proceedings; in addition, informal workshop proceedings will be handed out to participants during the workshop. Submission of papers will be in electronic form via an online system; detailed instructions will be posted on the workshop website. The final version of the paper must be prepared in LaTeX, adhering to the ENTCS format instructions (http://www.entcs.org/final.html). Venue ===== Prague is a charming city with a long medieval history. The workshop will be held in School of Computer Science of the Charles University, which is located right in the Prague's most famous historical district of the Lesser Town ("Mala Strana") of Prague. The building itself has been recently carefully renovated, reconstructing the architectural style of a Jesuit College. The timing of the workshop may allow us to enjoy the nice sunny period, when the weather is not hot anymore, but the early fall sunshine makes sightseeing walks very enjoyable, emphasizing fine features of the Prague's many historic buildings. Contact Information =================== Program Committee Chairs ------------------------ Frank S. de Boer (CWI, The Netherlands) http://homepages.cwi.nl/~frb/ F.S.de.Boercwi.nl Vladimir Mencl (UNU-IIST, Macao SAR China and Charles University in Prague, Czech Republic) http://nenya.ms.mff.cuni.cz/~mencl/ menclnenya.ms.mff.cuni.cz Local Arrangements ------------------ Milena Zeithamlova (Action M Agency) milena@action-m.com http://www.action-m.com Past workshops -------------- * FACS'03, Pisa, Italy, September 8-9, 2003, http://www.iist.unu.edu/facs03/ * FACS'05, Macao, October 24-25, 2005, http://www.iist.unu.edu/facs05/ Sponsoring Organizations ------------------------ * United Nations University, International Institute for Software Technology (UNU-IIST), Macao SAR China * Charles University in Prague, Faculty of Mathematics and Physics, Department of Software Engineering, Czech Republic * Centrum voor Wiskunde en Informatica (CWI), The Netherlands Workshop website ---------------- http://www.iist.unu.edu/facs06/ ================================================================== From Benjamin.werner at !NS! inria.fr Sun Jan 15 08:57:02 2006 From: Benjamin.werner at !NS! inria.fr (Benjamin Werner) Date: Sun, 15 Jan 2006 09:57:02 +0100 Subject: [Coq-Club]Inductive definitions in the Calculus of Constructionsa In-Reply-To: References: Message-ID: <0B21732D-ECE0-4461-B7FB-7209A07F7869@inria.fr> Hi, Le 9 janv. 06 =E0 13:46, Adam Chlipala a =E9crit : > I know that the Calculus of Inductive Constructions was created =20 > because the Calculus of Constructions was insufficient to represent =20= > some inductive types. Can anyone on this list give a short =20 > characterization of which types require this extension, and/or =20 > perhaps the simplest example of such a type? It is not so much the question of "which types" but rather what you =20 can do with them. Without inductive types, i.e. in raw CC, you : * cannot prove 0 \neq 1 * cannot prove the induction scheme (or dependent matching for the =20 matter) * do not have constant-time reduction for the matching, and matching =20 only works for closed terms. You can get back some of the results in CC through mere axioms. But =20 not the reduction behavior. Cheers, Benjamin > I'm interested in this in the context of trying to minimize the =20 > trusted code base needed to use results proved with Coq. If =20 > compiled developments can be translated to the Calculus of =20 > Constructions, then I imagine it's possible to use a significantly =20 > simpler checker. > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 Silvio.Ranise at !NS! loria.fr Mon Jan 16 11:18:32 2006 From: Silvio.Ranise at !NS! loria.fr (Silvio.Ranise@loria.fr) Date: Mon, 16 Jan 2006 12:18:32 +0100 Subject: [Coq-Club]CFP Calculemus'06, July 7-8, 2006 Genova (Italy) co-located with ISSAC 2006 Message-ID: <1137410312.43cb8108a13dc@www.loria.fr> =========================================================================== Calculemus'06 Symposium http://calculemus2006.loria.fr 13th Symposium on the Integration of Symbolic Computation and Mechanized Reasoning 2006 Co-located with ISSAC 2006 July 7-8, 2006 Università degli Studi di Genova Genova, Italy CALL FOR PAPERS =========================================================================== Background ----------- The scientific and technological goal of the Calculemus network is to design a new generation of mathematical software systems and computer-aided verification tools based on the integration of Deduction and Computer Algebra Systems. Both Deduction Systems (DSs) and Computer Algebra Systems (CASs) are receiving growing attention from industry and academia. On the one hand, CASs have been commercially very successful in recent years. On the other hand, the use of formal methods in hardware and software development has made DSs indispensable not least because of the complexity and sheer size of the reasoning tasks involved. Such systems are now making the transition from academic applications into regular industrial practice. In spite of these successes there is still need for improvement as many application domains still fall outside the scope of existing DSs and CASs. For instance, the scope of CASs could be significantly enhanced by adding deductive reasoning power. In fact this lack of expressivity together with the unsolved problem of correctness prohibit large classes of applications. DSs, which - on the other hand - provide such an expressivity, as well as the guarantee of correctness, still lack computational power as they are not suited to directly carry out algebraic or numerical calculations. This severely restricts their scope of application in mathematics and - more importantly - in engineering applications. The main goal of the Calculemus symposiums serie is to stimulate significant research advancements in combining the reasoning capabilities of DSs and the computational power of CASs as well as to foster possible cross-fertilizations. The field of DSs has diversified into the areas of automated theorem proving and interactive proof-development, which have their own traditions, conferences and technical methods. The field of CAs has specialised on devising highly efficient methods for symbolic calculations. The mission of the Calculemus symposiums serie is to bringing together such research communities so to create new generation of expressive, automatic, and easy-to-use systems capable of performing a wide range of mathematical tasks. Goals & Topics --------------- Calculemus 2006, the 13th symposium in the series, will be held July 7-8, 2006 at the Università degli Studi di Genova, Italy, in conjunction with the International Symposium on Symbolic and Algebraic Computation (ISSAC) 2006. The main theme of Calculemus 2006 will be the interactions between automated deduction and computer algebra with particular emphasis on the applications to verification, mathematical assistants, and web services. Calculemus 2006 welcomes research papers on all aspects of integrating symbolic computation and formal deduction including: * Combining computer algebra and computer deduction systems * Adding deductive capabilities to computer algebra systems * Adding computational capabilities to computer deduction systems * Combining methods of symbolic computation and formal deduction * Design and implementation issues in integrated systems * Design and implementation of computer algebra and deduction services for the web * Formal method problems requiring mixed computing and proving * Applications of formal methods to the construction of integrated systems * Design and implementation of mathematical assistants requiring both computer algebra and deduction * Case studies and applications Audience --------- The intended audience of the symposium is mainly researchers and practicioners in the fields of computer algebra and automated deduction. More in general, anyone interested in the design of mathematical software systems and computer-aided verification tools based on the integration of the deduction and computation. Call for papers ---------------- Papers addressing the topics listed above and more in general involving techniques in both computer algebra and automated deduction are solicited. Submitted papers should not exceed 12 pages and should be written in LaTeX with the following settings: 11pt, one column, a4paper and standard margins. Submissions should be done electronically via the following web-page: http://www.easychair.org/Calculemus06/submit Submissions will be peer-reviewed. The authors of accepted submissions are expected to give a 25' presentation at the symposium. The proceedings of Calculemus'06 will be distributed at the workshop and later published possibly as a special volume of the Electronic Notes in Computer Science (ENTCS). IMPORTANT! In order to ease the (possible) publication in the ENTCS volume of the workshop proceedings, please, use the following LaTeX header in your submission: \documentclass[a4paper,11pt]{article} \textwidth 14.63cm \textheight 22cm \oddsidemargin 0.65cm \evensidemargin 0.65cm \topmargin 0.55cm \headheight 0.0pt \headsep 0.0pt Important Dates (tentative...) ------------------------------- * Submission of title and abstract: April 8, 2006 * Submission of papers: April 15, 2006 * Notification of acceptance: May 15, 2006 * Final version of papers: June 4, 2006 * Symposium: July 7-8, 2006 Program Committee ------------------ * Anna Bigatti (Università degli Studi di Genova, Italy) [Co-chair] * Christoph Benzmeuller (Saarland University, Saarbrücken, Germany) * Olga Caprotti (University of Helsinki, Finland) * Jacques Carette (McMaster University, Canada) * Hoon Hong (North Carolina State University, USA) * William M. Farmer, McMaster University, Canada * Steve Linton (University of St. Andrews, UK) * Madan Musuvathi (Microsoft Research, USA) * Silvio Ranise (INRIA-Lorraine, France, and Università degli Studi di Milano, Italy) [Co-chair] * Christoph Ringeissen (INRIA-Lorraine, France) * Renaud Rioboo (University of Paris 6, France) * Pino Rosolini (Università degli Studi di Genova, Italy) * Roberto Sebastiani (Università di Trento, Italy) * Volker Sorge, University of Birmingham, UK * Carlo Traverso (Università degli Studi di Pisa, Italy) * Stephen Watt, (University of Western Ontario, Canada) Registration ------------- Details will be avaiable soon. From bohannon at !NS! cis.upenn.edu Fri Jan 13 22:44:08 2006 From: bohannon at !NS! cis.upenn.edu (Aaron Bohannon) Date: Fri, 13 Jan 2006 17:44:08 -0500 Subject: [Coq-Club]theory of inductive datatypes Message-ID: <80878dd7a061cd244dda2ad872b99d29@cis.upenn.edu> I know that one of the great things about Coq is that inductive datatypes are built into the language. However, in trying to understand the theory of inductive datatypes better, I would like to know how one might axiomatize the natural numbers in such a way that the axiomatized theory is equivalently powerful to the inductive type nat. I have included my first attempt below, written as a module signature. I essentially just added two axioms about recursion to the usual Peano axioms. It appears to be sound because I can implement such a module based upon the type nat. (See further below.) However, can someone tell me if my axioms are powerful enough to do everything with the natural numbers that I can do with Coq's built-in type? Also, are there other reasonable ways to axiomatize inductive types? Are there some good papers or references on this topic that someone can point me to? Thanks, Aaron Module Type NAT. Parameter N : Set. Parameter zero : N. Parameter succ : N -> N. Section Properties. Variables m n : N. Axiom discriminate_zero_succ : zero <> succ n. Axiom injective_succ : succ m = succ n -> m = n. Axiom N_rect : forall P : N -> Type, P zero -> (forall n : N, P n -> P (succ n)) -> forall n : N, P n. Variable F : N -> Set. Variable f_zero : F zero. Variable f_succ : forall n : N, F n -> F (succ n). Let f := N_rect F f_zero f_succ. Axiom N_rec_zero : f zero = f_zero. Axiom N_rec_succ : f (succ n) = f_succ n (f n). End Properties. End NAT. Module Nat : NAT. Definition N := nat. Definition zero := O. Definition succ := S. Definition discriminate_zero_succ := O_S. Definition injective_succ := eq_add_S. Definition N_rect := nat_rect. Section Recursion. Variable n : N. Variable P : N -> Set. Variable f_zero : P zero. Variable f_succ : forall n : N, P n -> P (succ n). Let f := N_rect P f_zero f_succ. Lemma N_rec_zero : f zero = f_zero. Proof refl_equal (f_zero). Lemma N_rec_succ : f (succ n) = f_succ n (f n). Proof refl_equal (f_succ n (f n)). End Recursion. End Nat. -- Aaron Bohannon http://www.cis.upenn.edu/~bohannon/ From adamc at !NS! cs.berkeley.edu Tue Jan 17 01:03:46 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Mon, 16 Jan 2006 17:03:46 -0800 Subject: [Coq-Club]Inductive definitions in the Calculus of Constructionsa In-Reply-To: <0B21732D-ECE0-4461-B7FB-7209A07F7869@inria.fr> References: <0B21732D-ECE0-4461-B7FB-7209A07F7869@inria.fr> Message-ID: <43CC4272.1000400@cs.berkeley.edu> This message is partially a reply to Aaron's post about axiomatizing nat, and partially a reply to Benjamin's post quoted below. Benjamin Werner wrote: > It is not so much the question of "which types" but rather what you > can do with them. Without inductive types, i.e. in raw CC, you : > > * cannot prove 0 \neq 1 > > * cannot prove the induction scheme (or dependent matching for the > matter) > > * do not have constant-time reduction for the matching, and matching > only works for closed terms. > > You can get back some of the results in CC through mere axioms. But > not the reduction behavior. I think I've below defined True, False, eq, and nat without using inductive definitions or axioms. I'm able to prove 0 \neq 1, and the induction scheme follows trivially from my definition of nat. Have I used inductive types without realizing it, or have I misunderstood what you meant by being able to prove 0 \neq 1? ------- Definition True := forall (T : Type), T -> T. Definition truei : True := fun (T : Type) (x : T) => x. Definition False := forall (T : Type), T. Definition eq (T : Type) (x y : T) := forall (P : T -> Type), P x -> P y. Definition refl_equal (T : Type) (x : T) : eq T x x := fun (P : T -> Type) (pf : P x) => pf. Definition nat := forall (P : Type), P -> (P -> P) -> P. Definition O : nat := fun (P : Type) (init : P) _ => init. Definition S n : nat := fun (P : Type) (init : P) (step : P -> P) => step (n P init step). Theorem zero_neq_one : eq nat O (S O) -> False. intro. unfold eq in X. assert ((fun (n : nat) => n Type True (fun _ => False)) (S O)). apply X. unfold O. apply truei. trivial. Qed. From adamc at !NS! cs.berkeley.edu Tue Jan 17 01:32:32 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Mon, 16 Jan 2006 17:32:32 -0800 Subject: [Coq-Club]Inductive definitions in the Calculus of Constructions In-Reply-To: <43CC4272.1000400@cs.berkeley.edu> References: <0B21732D-ECE0-4461-B7FB-7209A07F7869@inria.fr> <43CC4272.1000400@cs.berkeley.edu> Message-ID: <43CC4930.3020906@cs.berkeley.edu> Adam Chlipala wrote: > Benjamin Werner wrote: > >> It is not so much the question of "which types" but rather what you >> can do with them. Without inductive types, i.e. in raw CC, you : > > > I think I've below defined True, False, eq, and nat without using > inductive definitions or axioms. I'm able to prove 0 \neq 1, and the > induction scheme follows trivially from my definition of nat. Oops. I see that only the non-dependently-typed recursion principle follows trivially, which I think is enough for "programming" but not "proving" with nats. It still looks to me like I have a faithful encoding of nat in some sense, and I'm able to prove 0 \neq 1 about it. From pierre.casteran at !NS! labri.fr Tue Jan 17 06:46:36 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Tue, 17 Jan 2006 07:46:36 +0100 Subject: [Coq-Club]Inductive definitions in the Calculus of Constructions In-Reply-To: <43CC4930.3020906@cs.berkeley.edu> References: <0B21732D-ECE0-4461-B7FB-7209A07F7869@inria.fr> <43CC4272.1000400@cs.berkeley.edu> <43CC4930.3020906@cs.berkeley.edu> Message-ID: <43CC92CC.2010701@labri.fr> Adam Chlipala wrote: > Adam Chlipala wrote: > >> Benjamin Werner wrote: >> >>> It is not so much the question of "which types" but rather what you >>> can do with them. Without inductive types, i.e. in raw CC, you : >> >> >> >> I think I've below defined True, False, eq, and nat without using >> inductive definitions or axioms. I'm able to prove 0 \neq 1, and the >> induction scheme follows trivially from my definition of nat. > > > Oops. I see that only the non-dependently-typed recursion principle > follows trivially, which I think is enough for "programming" but not > "proving" with nats. It still looks to me like I have a faithful > encoding of nat in some sense, and I'm able to prove 0 \neq 1 about it. Hi, Notice that your definitions make False, True, 0 <> 1 being inhabitants of Type (with some index >0), and not plain propositions (i.e. of type Prop( at its turn of type Type(0)). Check (True:Prop). Toplevel input, characters 837-841 > Check (True:Prop). > ^^^^ Error: The term "True" has type "Type" while it is expected to have type "Prop" Pierre > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 bohannon at !NS! cis.upenn.edu Tue Jan 17 03:39:21 2006 From: bohannon at !NS! cis.upenn.edu (Aaron Bohannon) Date: Mon, 16 Jan 2006 22:39:21 -0500 Subject: [Coq-Club]theory of inductive datatypes In-Reply-To: <80878dd7a061cd244dda2ad872b99d29@cis.upenn.edu> References: <80878dd7a061cd244dda2ad872b99d29@cis.upenn.edu> Message-ID: Adam's posts reminded me that, of course, such an axiomatization cannot do everything the built-in type nat can. In particular, we cannot supply them as arguments to dependent types in a generally useful way because type equality is intensional in Coq. Also, I don't know why I thought recursion should only be allowed at sort Set. It works fine at Type. Other than this, are there any other improvement for my axiomatization or any more comments about additional techniques? Aaron On Jan 13, 2006, at 5:44 PM, Aaron Bohannon wrote: > I know that one of the great things about Coq is that inductive > datatypes are built into the language. However, in trying to > understand the theory of inductive datatypes better, I would like to > know how one might axiomatize the natural numbers in such a way that > the axiomatized theory is equivalently powerful to the inductive type > nat. > > I have included my first attempt below, written as a module signature. > I essentially just added two axioms about recursion to the usual > Peano axioms. It appears to be sound because I can implement such a > module based upon the type nat. (See further below.) However, can > someone tell me if my axioms are powerful enough to do everything with > the natural numbers that I can do with Coq's built-in type? > > Also, are there other reasonable ways to axiomatize inductive types? > Are there some good papers or references on this topic that someone > can point me to? > > Thanks, > Aaron > > > Module Type NAT. > Parameter N : Set. > Parameter zero : N. > Parameter succ : N -> N. > > Section Properties. > Variables m n : N. > > Axiom discriminate_zero_succ : zero <> succ n. > Axiom injective_succ : succ m = succ n -> m = n. > > Axiom N_rect : > forall P : N -> Type, > P zero -> > (forall n : N, P n -> P (succ n)) -> > forall n : N, P n. > > Variable F : N -> Set. > Variable f_zero : F zero. > Variable f_succ : forall n : N, F n -> F (succ n). > Let f := N_rect F f_zero f_succ. > > Axiom N_rec_zero : f zero = f_zero. > Axiom N_rec_succ : f (succ n) = f_succ n (f n). > > End Properties. > End NAT. > > Module Nat : NAT. > Definition N := nat. > Definition zero := O. > Definition succ := S. > Definition discriminate_zero_succ := O_S. > Definition injective_succ := eq_add_S. > Definition N_rect := nat_rect. > Section Recursion. > Variable n : N. > Variable P : N -> Set. > Variable f_zero : P zero. > Variable f_succ : forall n : N, P n -> P (succ n). > Let f := N_rect P f_zero f_succ. > > Lemma N_rec_zero : f zero = f_zero. > Proof refl_equal (f_zero). > > Lemma N_rec_succ : f (succ n) = f_succ n (f n). > Proof refl_equal (f_succ n (f n)). > > End Recursion. > End Nat. > > > -- > Aaron Bohannon > http://www.cis.upenn.edu/~bohannon/ > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 > -- Aaron Bohannon http://www.cis.upenn.edu/~bohannon/ From gumm at !NS! mathematik.uni-marburg.de Tue Jan 17 08:51:24 2006 From: gumm at !NS! mathematik.uni-marburg.de (gumm@mathematik.uni-marburg.de) Date: Tue, 17 Jan 2006 09:51:24 +0100 Subject: [Coq-Club]PhD-Position (Mitarbeiterstelle) in Coalgebra, Algebra, Formal Methods In-Reply-To: <42C3F961.4030401@tzi.de> References: <42C3F961.4030401@tzi.de> Message-ID: <43CCB00C.8070709@mathematik.uni-marburg.de> The Department of Mathematics and Computer Science at the University of Marburg, Germany, offers a full time PhD-Position - Wissenschaftl. Mitarbeiter/in (BAT IIa) - in the area Universal Coalgebra / Universal Algebra, Verification, Formal Methods. Prerequisites: Excellent degree (Diplom or Master) in Computer Science or Mathematics. Strong background in one or more of the above areas. German language fluency. Tasks: Service (organization, preparation, counselling) in teaching and research at the undergraduate and graduate level. PhD-Research The contract is initially for 1 year, with the possibility for extensions to a total of at most 5 years If you are interested, please get in touch with Prof. Dr. H.Peter Gumm gumm@mathematik.uni-marburg.de The official advertisement can be found at http://www.mathematik.uni-marburg.de/~gumm/Stelle/Stelle.pdf From adamc at !NS! cs.berkeley.edu Tue Jan 17 14:10:41 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Tue, 17 Jan 2006 06:10:41 -0800 Subject: [Coq-Club]Inductive definitions in the Calculus of Constructions In-Reply-To: <43CC92CC.2010701@labri.fr> References: <0B21732D-ECE0-4461-B7FB-7209A07F7869@inria.fr> <43CC4272.1000400@cs.berkeley.edu> <43CC4930.3020906@cs.berkeley.edu> <43CC92CC.2010701@labri.fr> Message-ID: <43CCFAE1.1080507@cs.berkeley.edu> Pierre Casteran wrote: > Hi, > Notice that your definitions make False, True, 0 <> 1 being > inhabitants of Type (with some index >0), and > not plain propositions (i.e. of type Prop( at its turn of type Type(0)). > Check (True:Prop). > Toplevel input, characters 837-841 > > Check (True:Prop). > > ^^^^ > Error: The term "True" has type "Type" while it is expected to have type > "Prop" Is this really a problem? In my long journey towards understanding the metatheory of Coq, I've come to explain to myself the distinction among Set/Prop/Type as only being necessary to support extraction. Do you really need more than the different levels of Type if you're only interested in checking proofs in the simplest possible calculus? From Frederic.Blanqui at !NS! loria.fr Tue Jan 17 16:28:57 2006 From: Frederic.Blanqui at !NS! loria.fr (Frederic Blanqui) Date: Tue, 17 Jan 2006 17:28:57 +0100 (CET) Subject: [Coq-Club]Inductive definitions in the Calculus of Constructions In-Reply-To: <43CCFAE1.1080507@cs.berkeley.edu> References: <0B21732D-ECE0-4461-B7FB-7209A07F7869@inria.fr> <43CC4272.1000400@cs.berkeley.edu> <43CC4930.3020906@cs.berkeley.edu> <43CC92CC.2010701@labri.fr> <43CCFAE1.1080507@cs.berkeley.edu> Message-ID: On Tue, 17 Jan 2006, Adam Chlipala wrote: > Is this really a problem? In my long journey towards understanding the > metatheory of Coq, I've come to explain to myself the distinction among > Set/Prop/Type as only being necessary to support extraction. Do you really > need more than the different levels of Type if you're only interested in > checking proofs in the simplest possible calculus? the Type hierarchy is predicative while Prop is impredicative. this means that (forall P : Prop, P => P) is of type Prop, while (forall P : Type_i, P => P) is of type Type_i+1. i explicitly added the indexes which are not printed by coq. From gustun at !NS! fing.edu.uy Tue Jan 17 19:32:58 2006 From: gustun at !NS! fing.edu.uy (Gustavo Betarte - INCO) Date: Tue, 17 Jan 2006 17:32:58 -0200 Subject: [Coq-Club]Workshop on Formal Methods and Security Message-ID: <20060117173258.prgx7b8tlw4ckwog@www.fing.edu.uy> [- Apologies for multiple messages; - Pls note that the deadline for submission is March 31 ] Call for Papers Workshop on Formal Techniques for Specification and Analysis of Security (FTSAS 2006) http://www.fing.edu.uy/ftsas06 World Computer Congress - Security Stream August 20-25, Santiago de Chile Information technology is set to experience in the coming decades a massive and unprecedented increase in system complexity, leading to systems that integrate a vast spectrum of diverse technologies and heterogeneous intelligent devices by the billions in connected networks. The increasing complexity and distributed nature of systems will require the development of methodologies, languages, tools, and standards that facilitate interoperability and integration, and generalize deployment scenarios such as remote maintenance of devices. At the same time, the need for secure code will become more prominent, because the distinction between applications and systems will gradually disappear and most code will have consequences as regards security, and the task of writing secure code will become tremendously more difficult, because of the lack of effective support to integrate security considerations in system development. IT security is an area which involves important technical challenges because of the very high expectations of the market regarding the security properties information systems are expected to meet. The deployment of security mechanisms, though, is often done in an ad-hoc manner and lacking a precise security specification. Formal techniques provide a means to pinpoint precisely and analyze formally security requirements that arise in complex systems. Security is by its nature a global concern, the definition and the application of rigorous methodologies and the design and use of appropriate innovative tools should cover all the steps of the design, development and validation of IT products. The objective of the workshop is to bring together security experts and formal methods practitioners, who are interested in the application of formal methods in the design and validation of information systems. Topic of interest include: o specification and verification of security policies o language-based security for information flow and resource control o security based on verifiable evidence, Proof Carrying Code o system-wide security, security for concurrent and distributed systems o formal specification and verification of cryptographic protocols o cryptographic algorithms and provable security o trust management o digital rights management o case studies Paper Submission Authors are invited to submit an extended abstract explaining recent research results, work in progress or system descriptions. Papers shall not exceed 10 pages, inclusive of bibliography and appendices. They should be formatted for A4 or US letter paper with reasonable margins and fonts. The first page should include the title, the names and addresses of the authors, an abstract and a list of keywords. Accepted formats are limited to portable postscript and PDF. Please do not send files formatted for word processing packages (e.g., Microsoft Word or WordPerfect files). The workshop has no formal proceedings. Nevertheless, informal proceedings will be made available in electronic format and they will be distributed to all participants of the workshop. The authors of the best papers might be invited to submit an extended revision for inclusion in formal proceedings. Important dates =09o Paper Submission due: March 31, 2006 =09o Notification: April 21, 2006 =09o Final papers due: May 30, 2006 Program Committe =09o Tom=E1s Barros Universidad Diego Portales, Chile =09o Gilles Barthe INRIA Sophia-Antipolis, France =09o Gustavo Betarte Universidad de la Rep=FAblica, Uruguay =09o Ricardo Corin University of Twente, Netherlands =09o Pedro D'Argenio Universidad Nacional de Cordoba, Argentine =09o Benjamin Gr=E9goire INRIA Sophia-Antipolis, France =09o German Puebla Universidad Polit=E9cnica de Madrid, Spain =09o Gerardo Schneider University of Oslo, Norway ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From herbelin at !NS! pauillac.inria.fr Thu Jan 19 12:09:24 2006 From: herbelin at !NS! pauillac.inria.fr (Hugo Herbelin) Date: Thu, 19 Jan 2006 13:09:24 +0100 (MET) Subject: [Coq-Club] Unrecognized utf-8 In-Reply-To: from Stefan Monnier at "Dec 20, 105 03:26:28 pm" Message-ID: <200601191209.NAA22364@pauillac.inria.fr> Hi, Here is a quick reply to your Dec 20 mail. > The following uses of Unicode (using utf-8 encoding) don't work: > > Definition test : nat -> nat := fun Î˜ => Î˜. > Definition test : nat -> nat := fun Î” => Î”. > Definition test : nat -> nat := fun Î“ => Î“. > Definition test : nat -> nat := fun Ï„ => Ï„. > Definition test : nat -> nat := fun Ï† => Ï†. > Definition test : nat -> nat := fun â—‹ => â—‹. > Definition test : nat -> nat := fun â–¹ => â–¹. > Definition test : nat -> nat := fun â–· => â–·. > Definition test : nat -> nat := fun xâ‚ => xâ‚. > Definition test : nat -> nat := fun xâ‚‚ => xâ‚‚. > Definition test : nat -> nat := fun xâ‚ƒ => xâ‚ƒ. Only a few Unicode ranges are indeed supported in Coq. The reason is that Coq makes a distinction between letters (or more generally components of identifiers) and symbols and that this requires a detailed analysis of what is in each Unicode range (e.g. in the range for Latin-1 - not yet supported in Coq -, two symbols are hidden - Ã— and Ã· - in the middle of a full range of letters). In V8.0 (new syntax), only the ranges for Greek letter, letter-like symbols (e.g. â„¤) and various mathematical symbols are supported. Especially, your first four examples actually work. The next three examples cannot work because the Unicode elements that you use are not letters, hence not acceptable as valid identifiers (and in practice these elements are not supported at all in V8.0, even as symbols). The last three examples could be supported and they will in the next release of Coq. > Funnily, > > Definition test : nat -> nat := fun âŒ© => âŒ©. > > doesn't work, but > > Notation "'âŒ©' x = w , e ':' t 'âŒª'" := (Epack w (fun x => t) e). > > works. The Unicode elements âŒ© and âŒª are indeed supported in V8.0. For the reason that there are considered as symbols in Coq, the first case correctly fails and the second works. As a side remark, precisely because they are symbols, you don't need to surround them by quotes in the notation. Hugo Herbelin From pierre.casteran at !NS! labri.fr Fri Jan 20 07:55:48 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Fri, 20 Jan 2006 08:55:48 +0100 Subject: [Coq-Club]theory of inductive datatypes In-Reply-To: References: <80878dd7a061cd244dda2ad872b99d29@cis.upenn.edu> Message-ID: <43D09784.6080003@labri.fr> This is a multi-part message in MIME format. --------------070007010608090208020305 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Aaron Bohannon wrote: > Adam's posts reminded me that, of course, such an axiomatization > cannot do everything the built-in type nat can. In particular, we > cannot supply them as arguments to dependent types in a generally > useful way because type equality is intensional in Coq. > > Also, I don't know why I thought recursion should only be allowed at > sort Set. It works fine at Type. > > Other than this, are there any other improvement for my axiomatization > or any more comments about additional techniques? > > Aaron Hi Aaron, It seems you don't need these axioms > Axiom discriminate_zero_succ : zero <> succ n. > Axiom injective_succ : succ m = succ n -> m = n. since you can derive them from N_rect. N_rect (and the axioms N_rec_zero and N_rec_succ) are enough to build a predicate is_Zero (for proving 0 <> succ n) and the predecessor function (for proving that succ is injective). Please find attached this version of your development (without modules, but it should be easy to write some functors). Pierre > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 --------------070007010608090208020305 Content-Type: text/plain; name="AAron.v" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="AAron.v" Parameter N : Set. Parameter zero : N. Parameter succ : N -> N. Section Properties. Axiom N_rect : forall P : N -> Type, P zero -> (forall n : N, P n -> P (succ n)) -> forall n : N, P n. Section N_rect_axioms. Variables m n : N. Variable F : N -> Type. Variable f_zero : F zero. Variable f_succ : forall n : N, F n -> F (succ n). Let f := N_rect F f_zero f_succ. Axiom N_rec_zero : f zero = f_zero. Axiom N_rec_succ : f (succ n) = f_succ n (f n). End N_rect_axioms. Definition is_Zero := N_rect (fun _ => Prop) True (fun _ H => False). Remark R1 : is_Zero zero. unfold is_Zero. rewrite N_rec_zero. trivial. Qed. Remark R2 : forall n, ~is_Zero (succ n). unfold is_Zero. red;intros. rewrite N_rec_succ in H. auto. Qed. Lemma discriminate_zero_succ : forall n, zero <> succ n. Proof. intros n H. apply (R2 n). case H. apply R1. Qed. Definition pred := N_rect (fun _ => N) zero (fun p q => p). Lemma pred_of_zero : pred zero = zero. Proof. unfold pred. rewrite N_rec_zero;trivial. Qed. Lemma pred_of_succ : forall n, pred (succ n) = n. Proof. intros. unfold pred;rewrite N_rec_succ. trivial. Qed. Lemma N_inj : forall n p, succ n = succ p -> n = p. Proof. intros. assert (pred (succ n) = pred (succ p)). rewrite H;trivial. do 2 rewrite pred_of_succ in H0. trivial. Qed. End Properties. --------------070007010608090208020305-- From wlp06 at !NS! kr.tuwien.ac.at Wed Jan 18 14:31:56 2006 From: wlp06 at !NS! kr.tuwien.ac.at (wlp06@kr.tuwien.ac.at) Date: Wed, 18 Jan 2006 15:31:56 +0100 (CET) Subject: [Coq-Club]Call for Participation: 20th Workshop on Logic Programming - WLP 2006 Message-ID: Call for Participation ----------------------------------------------------------------------------- WLP 2006 20th Workshop on Logic Programming February 22 - 24, 2006 Vienna University of Technology, Austria ***Early Registration Deadline: February 3, 2006*** http://www.kr.tuwien.ac.at/wlp06 ------------------------------------------------------------------------------ THE WORKSHOP ============ The series of workshops on (constraint) logic programming serve as the annual meeting of the Society of Logic Programming (GLP, Gesellschaft fr Logische Programmierung e.V.) and bring together researchers interested in logic programming, constraint programming, and related areas like databases and artificial intelligence. Previous workshops have been held in Germany, Austria and Switzerland. The workshops provide a forum for exchanging ideas on declarative logic programming, nonmonotonic reasoning and knowledge representation, and facilitate interactions between research in theoretical foundations and in the design and implementation of logic-based programming systems. The technical program of the workshop will include invited talks, presentations of refereed papers, and system demonstrations. WORKSHOP PROGRAM ================ The technical program of WLP 2006 comprises two invited talks, two tutorials, 18 research papers, and two system descriptions. The list of all accepted papers can be found at http://www.kr.tuwien.ac.at/wlp06/accepted.html INVITED TALKS ============= Reinhard Pichler (Vienna University of Technology, Austria) Torsten Schaub (University of Potsdam, Germany) TUTORIALS ========= Two tutorials will be held during the workshop by: Ulrich Geske (Fraunhofer-Gesellschaft, Germany) Armin Wolf (Fraunhofer-Gesellschaft, Germany) REGISTRATION AND ACCOMMODATION ============================== Information on how to register to the workshop and about organizing your trip to Vienna (accommodation, travel information, etc.) can be found at the workshop homepage: http://www.kr.tuwien.ac.at/wlp06 IMPORTANT DATES =============== Early Registration Deadline February 3, 2006 Workshop February 22-24, 2006 LOCAL ORGANIZATION ================== Michael Fink Hans Tompits (Chair) Stefan Woltran CONTACT ======= Hans Tompits Knowledge-Based Systems Group E184/3 Institute of Information Systems Vienna University of Technology Favoritenstrasse 9-11 A-1040 Vienna Austria Email: wlp06@kr.tuwien.ac.at WORKSHOP HOMEPAGE ================= http://www.kr.tuwien.ac.at/wlp06 From bruno.barras at !NS! inria.fr Wed Jan 18 19:04:18 2006 From: bruno.barras at !NS! inria.fr (Bruno Barras) Date: Wed, 18 Jan 2006 20:04:18 +0100 Subject: [Coq-Club]Release of Coq 8.0 pl3 Message-ID: <43CE9132.9080604@inria.fr> This is a multi-part message in MIME format. --------------000103020403070505040902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello all, this is our pleasure to anounce the availability of the 3rd patch-level release of Coq 8.0. As its name shows, it is compatible with Coq 8.0, and fixes many bugs (see the attached file CHANGES). The download page is as usual: http://coq.inria.fr/distrib-eng.html This release is of special interest for users of the Windows port since it is now distributed as an auto-install program, and serious bugs in CoqIde were fixed. In the name of the Coq development team, Bruno Barras. --------------000103020403070505040902 Content-Type: text/plain; name="CHANGES" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="CHANGES" Changes from V8.0pl2 to V8.0pl3 =============================== Tactics - The search depth argument of auto can be parameterised in the Ltac language - Added entry constr_may_eval for tactic extensions (new syntax) Compilation - Coq sources made compatible with ocaml 3.09.0 and lablgtk 2.6.0. Standard library - A couple of lemmas of ZArith were renamed. This concerns names containing O (the letter), which is replaced by 0 (the number). Bug fixes - Fixes a serious bug in CoqIde. The windows port should be able to load large libraries (such as Reals) without producing the "bad file descriptor" error. - Scope of Ltac variables: global Ltac macros no longer hide goal hypotheses - Many fixes concerning extraction: * fewer useless eta-expansions * for Ocaml: extraction of records should be ok now. Problem with type t = M.t in modules fixed. * in Haskell: improved use of unsafeCoerce, fixed Extract Constant, function types are now printed. * important revision of the Scheme extraction: see http://www.pps.jussieu.fr/~letouzey/scheme - Fixes a bug in the interpretation of record projections ("bad number of parameters" error) - Fixed a bug in the omega tactic - Fixed a bug in the fold tactic regarding hypotheses ordering - Pretty-print of universes fixed - Added an empty level 99 in patterns syntax entry - "Notation" bug fixes ("only parsing" bug, printing of numerals arguments of coercions, default spacing for recursive notations with no terminal separator, "Tactic Notation" printer). Changes from V8.0pl1 to V8.0pl2 =============================== Notations - Option "format" now aware of recursive notations Bug fixes - Tactic "fail n" for n<>0 now works (notice that each "match term with" block decreases the failure level, in accordance with the intuition but not in conformity with the reference manual) - Option -dump-glob now strips module segment as expected by coqdoc (which is still not aware of modules) - See coq-bugs web page for a full list of fixed bugs (look for fixes committed before Jan 2005 to cvs version V8-0-bugfix) Changes from V8.0 to V8.0pl1 ============================ Unicode support - Miscellaneous Mathematical Symbols-A and B, and Supplemental Arrows-A now supported Bug fixes - GPL-incompatible QPL files for CoqIde are now GPL - Pretty-printing of coercions to Funclass fixed and improved - Erroneous interpretation of the quantified hypothesis in intro until fixed - See coq-bugs web page for a full list of fixed bugs (look for fixes in V8-0-bugfix before July 17) Changes from V8.0beta to V8.0 ============================= Vernacular commands - New option "Set Printing All" to deactivate all high-level forms of printing (implicit arguments, coercions, destructing let, if-then-else, notations, projections) - "Functional Scheme" and "Functional Induction" extended to polymorphic types and dependent types - Notation now allows recursive patterns, hence recovering parts of the fonctionalities of pre-V8 Grammar/Syntax commands - Command "Print." discontinued. - Redundant syntax "Implicit Arguments On/Off" discontinued New syntax - Semantics change of the if-then-else construction in new syntax: "if c then t1 else t2" now stands for "match c with c1 _ ... _ => t1 | c2 _ ... _ => t2 end" with no dependency of t1 and t2 in the arguments of the constructors; this may cause incompatibilities for files translated using coq 8.0beta Interpretation scopes - Delimiting key %bool for bool_scope added - Import no more needed to activate argument scopes from a module Tactics and the tactic Language - Semantics of "assert" is now consistent with the reference manual - New tactics stepl and stepr for chaining transitivity steps - Tactic "replace ... with ... in" added - Intro patterns now supported in Ltac (parsed with prefix "ipattern:") Executables and tools - Added option -top to change the name of the toplevel module "Top" - Coqdoc updated to new syntax and now part of Coq sources - XML exportation tool now exports the structure of vernacular files (cf chapter 13 in the reference manual) User contributions - User contributions have been updated to the new syntax Bug fixes - Many bugs have been fixed (cf coq-bugs web page) Changes from V8.0beta old syntax to V8.0beta ============================================ New concrete syntax - A completely new syntax for terms - A more uniform syntax for tactics and the tactic language - A few syntactic changes for vernacular commands - A smart automatic translator translating V8.0 files in old syntax to files valid for V8.0 Syntax extensions - "Grammar" for terms disappears - "Grammar" for tactics becomes "Tactic Notation" - "Syntax" disappears - Introduction of a notion of interpretation scope allowing to use the same notations in various contexts without using specific delimiters (e.g the same expression "4<=3+x" is interpreted either in "nat", "positive", "N" (previously "entier"), "Z", "R", depending on which interpretation scope is currently open) [see documentation for details] - Notation now mandatorily requires a precedence and associativity (default was to set precedence to 1 and associativity to none) Revision of the standard library - Many lemmas and definitions names have been made more uniform mostly in Arith, NArith, ZArith and Reals (e.g : "times" -> "Pmult", "times_sym" -> "Pmult_comm", "Zle_Zmult_pos_right" -> "Zmult_le_compat_r", "SUPERIEUR" -> "Gt", "ZERO" -> "Z0") - Order and names of arguments of basic lemmas on nat, Z, positive and R have been made uniform. - Notions of Coq initial state are declared with (strict) implicit arguments - eq merged with eqT: old eq disappear, new eq (written =) is old eqT and new eqT is syntactic sugar for new eq (notation == is an alias for = and is written as it, exceptional source of incompatibilities) - Similarly, ex, ex2, all, identity are merged with exT, exT2, allT, identityT - Arithmetical notations for nat, positive, N, Z, R, without needing any backquote or double-backquotes delimiters. - In Lists: new concrete notations; argument of nil is now implicit - All changes in the library are taken in charge by the translator Semantical changes during translation - Recursive keyword set by default (and no longer needed) in Tactic Definition - Set Implicit Arguments is strict by default in new syntax - reductions in hypotheses of the form "... in H" now apply to the type also if H is a local definition - etc Gallina - New syntax of the form "Inductive bool : Set := true, false : bool." for enumerated types - Experimental syntax of the form p.(fst) for record projections (activable with option "Set Printing Projections" which is recognized by the translator) Known problems of the automatic translation - iso-latin-1 characters are no longer supported: move your files to 7-bits ASCII or unicode before translation (swith to unicode is automatically done if a file is loaded and saved again by coqide) - Renaming in ZArith: incompatibilities in Coq user contribs due to merging names INZ, from Reals, and inject_nat. - Renaming and new lemmas in ZArith: may clash with names used by users - Restructuration of ZArith: replace requirement of specific modules in ZArith by "Require Import ZArith_base" or "Require Import ZArith" - Some implicit arguments must be made explicit before translation: typically for "length nil", the implicit argument of length must be made explicit - Grammar rules, Infix notations and V7.4 Notations must be updated wrt the new scheme for syntactic extensions (see translator documentation) - Unsafe for annotation Cases when constructors coercions are used or when annotations are eta-reduced predicates Changes from V7.4 to V8.0beta old syntax ======================================== Logic - Set now predicative by default - New option -impredicative-set to set Set impredicative - The standard library doesn't need impredicativity of Set and is compatible with the classical axioms which contradict Set impredicativity Syntax for arithmetic - Notation "=" and "<>" in Z and R are no longer implicitly in Z or R (with possible introduction of a coercion), use ...=... or ...<>... instead - Locate applied to a simple string (e.g. "+") searches for all notations containing this string Vernacular commands - "Declare ML Module" now allows to import .cma files. This avoids to use a bunch of "Declare ML Module" statements when using several ML files. - "Set Printing Width n" added, allows to change the size of width printing (TODO : doc). - "Implicit Variables Type x,y:t" (new syntax: "Implicit Types x y:t") assigns default types for binding variables. - Declarations of Hints and Notation now accept a "Local" flag not to be exported outside the current file even if not in section - "Print Scopes" prints all notations - New command "About name" for light printing of type, implicit arguments, etc. - New command "Admitted" to declare incompletely proven statement as axioms - New keyword "Conjecture" to declare an axiom intended to be provable - SearchAbout can now search for lemmas referring to more than one constant and on substrings of the name of the lemma - "Print Implicit" displays the implicit arguments of a constant - Locate now searches for all names having a given suffix - New command "Functional Scheme" for building an induction principle from a function defined by case analysis and fix. Commands - new coqtop/coqc option -dont-load-proofs not to load opaque proofs in memory Implicit arguments - Inductive in sections declared with implicits now "discharged" with implicits (like constants and variables) - Implicit Arguments flags are now synchronous with reset - New switch "Unset/Set Printing Implicits" (new syntax: "Unset/Set Printing Implicit") to globally control printing of implicits Grammar extensions - UTF-8 encoded unicode blocks 0380-03FF (greek letters) and 2100-214F (letter-like, including aleph and double N,Z,Q,R) are supported identifiers; UTF-8 unicode blocs 2200-22FF (mathematical operators), 2A00-2AFF (supplemental mathematical operators) 2300-23FF (miscellaneous technical, including sqrt symbol), 2600-26FF (miscellaneous symbols) 2190-21FF (arrows A) and 2900-297F (arrows B) are supported symbols Library - New file about the factorial function in Arith - An additional elimination Acc_iter for Acc, simplier than Acc_rect. This new elimination principle is used for definition well_founded_induction. - New library NArith on binary natural numbers - R is now of type Set - Restructuration in ZArith library - "true_sub" used in Zplus now a definition, not a local one (source of incompatibilities in proof referring to true_sub, may need extra Unfold) - Some lemmas about minus moved from fast_integer to Arith/Minus.v (le_minus, lt_mult_left) (theoretical source of incompatibilities) - Several lemmas moved from auxiliary.v and zarith_aux.v to fast_integer.v (theoretical source of incompatibilities) - Variables names of iff_trans changed (source of incompatibilities) - ZArith lemmas named OMEGA something or fast_ something, and lemma new_var are now out of ZArith (except OMEGA2) - Redundant ZArith lemmas have been renamed: for the following pairs, use the second name (Zle_Zmult_right2, Zle_mult_simpl), (OMEGA2, Zle_0_plus), (Zplus_assoc_l, Zplus_assoc), (Zmult_one, Zmult_1_n), (Zmult_assoc_l, Zmult_assoc), (Zmult_minus_distr, Zmult_Zminus_distr_l) (add_un_double_moins_un_xO, is_double_moins_un), (Rlt_monotony_rev,Rlt_monotony_contra) (source of incompatibilities) - Few minor changes (no more implicit arguments in Zmult_Zminus_distr_l and Zmult_Zminus_distr_r, lemmas moved from Zcomplements to other files) (rare source of incompatibilities) - New lemmas provided by users added Tactic language - Fail tactic now accepts a failure message - Idtac tactic now accepts a message - New primitive tactic "FreshId" (new syntax: "fresh") to generate new names - Debugger prints levels of calls Tactics - Replace can now replace proofs also - Fail levels are now decremented at "Match Context" blocks only and if the right-hand-side of "Match term With" are tactics, these tactics are never evaluated immediately and do not induce backtracking (in contrast with "Match Context") - Quantified names now avoid global names of the current module (like Intro names did) [source of rare incompatibilities: 2 changes in the set of user contribs] - NewDestruct/NewInduction accepts intro patterns as introduction names - NewDestruct/NewInduction now work for non-inductive type using option "using" - A NewInduction naming bug for inductive types with functional arguments (e.g. the accessibility predicate) has been fixed (source of incompatibilities) - Symmetry now applies to hypotheses too - Inversion now accept option "as [ ... ]" to name the hypotheses - Contradiction now looks also for contradictory hypotheses stating ~A and A (source of incompatibility) - "Contradiction c" try to find an hypothesis in context which contradicts the type of c - Ring applies to new library NArith (require file NArithRing) - Field now works on types in Set - Auto with reals now try to replace le by ge (Rge_le is no longer an immediate hint), resulting in shorter proofs - Instantiate now works in hyps (syntax : Instantiate in ...) - Some new tactics : EConstructor, ELeft, Eright, ESplit, EExists - New tactic "functional induction" to perform case analysis and induction following the definition of a function. - Clear now fails when trying to remove a local definition used by a constant appearing in the current goal Extraction (See details in contrib/extraction/CHANGES) - The old commands: (Recursive) Extraction Module M. are now: (Recursive) Extraction Library M. To use these commands, M should come from a library M.v - The other syntax Extraction & Recursive Extraction now accept module names as arguments. Bugs - see coq-bugs server for the complete list of fixed bugs Miscellaneous - Implicit parameters of inductive types definition now taken into account for infering other implicit arguments Incompatibilities - Persistence of true_sub (4 incompatibilities in Coq user contributions) - Variable names of some constants changed for a better uniformity (2 changes in Coq user contributions) - Naming of quantified names in goal now avoid global names (2 occurrences) - NewInduction naming for inductive types with functional arguments (no incompatibility in Coq user contributions) - Contradiction now solve more goals (source of 2 incompatibilities) - Merge of eq and eqT may exceptionally result in subgoals now solved automatically - Redundant pairs of ZArith lemmas may have different names: it may cause "Apply/Rewrite with" to fail if using the first name of a pair of redundant lemmas (this is solved by renaming the variables bound by "with"; 3 incompatibilities in Coq user contribs) - ML programs referring to constants from fast_integer.v must use "Coqlib.gen_constant_modules Coqlib.zarith_base_modules" instead Changes from V7.3.1 to V7.4 =========================== Symbolic notations - Introduction of a notion of scope gathering notations in a consistent set; a notation sets has been developped for nat, Z and R (undocumented) - New command "Notation" for declaring notations simultaneously for parsing and printing (see chap 10 of the reference manual) - Declarations with only implicit arguments now handled (e.g. the argument of nil can be set implicit; use !nil to refer to nil without arguments) - "Print Scope sc" and "Locate ntn" allows to know to what expression a notation is bound - New defensive strategy for printing or not implicit arguments to ensure re-type-checkability of the printed term - In Grammar command, the only predefined non-terminal entries are ident, global, constr and pattern (e.g. nvar, numarg disappears); the only allowed grammar types are constr and pattern; ast and ast list are no longer supported; some incompatibilities in Grammar: when a syntax is a initial segment of an other one, Grammar does not work, use Notation Library - Lemmas in Set from Compare_dec.v (le_lt_dec, ...) and Wf_nat.v (lt_wf_rec, ...) are now transparent. This may be source of incompatibilities. - Syntactic Definitions Fst, Snd, Ex, All, Ex2, AllT, ExT, ExT2, ProjS1, ProjS2, Error, Value and Except are turned to notations. They now must be applied (incompatibilities only in unrealistic cases). - More efficient versions of Zmult and times (30% faster) - Reals: the library is now divided in 6 parts (Rbase, Rfunctions, SeqSeries, Rtrigo, Ranalysis, Integration). New tactics: Sup and RCompute. See Reals.v for details. Modules - Beta version, see doc chap 2.5 for commands and chap 5 for theory Language - Inductive definitions now accept ">" in constructor types to declare the corresponding constructor as a coercion. - Idem for assumptions declarations and constants when the type is mentionned. - The "Coercion" and "Canonical Structure" keywords now accept the same syntax as "Definition", i.e. "hyps :=c (:t)?" or "hyps :t". - Theorem-like declaration now accepts the syntax "Theorem thm [x:t;...] : u". - Remark's and Fact's now definitively behave as Theorem and Lemma: when sections are closed, the full name of a Remark or a Fact has no longer a section part (source of incompatibilities) - Opaque Local's (i.e. built by tactics and ended by Qed), do not survive section closing any longer; as a side-effect, Opaque Local's now appear in the local context of proofs; their body is hidden though (source of incompatibilities); use one of Remark/Fact/Lemma/Theorem instead to simulate the old behaviour of Local (the section part of the name is not kept though) ML tactic and vernacular commands - "Grammar tactic" and "Grammar vernac" of type "ast" are no longer supported (only "Grammar tactic simple_tactic" of type "tactic" remains available). - Concrete syntax for ML written vernacular commands and tactics is now declared at ML level using camlp4 macros TACTIC EXTEND et VERNAC COMMAND EXTEND. - "Check n c" now "n:Check c", "Eval n ..." now "n:Eval ..." - "Proof with T" (* no documentation *) - SearchAbout id - prints all theorems which contain id in their type Tactic definitions - Static globalisation of identifiers and global references (source of incompatibilities, especially, Recursive keyword is required for mutually recursive definitions). - New evaluation semantics: no more partial evaluation at definition time; evaluation of all Tactic/Meta Definition, even producing terms, expect a proof context to be evaluated (especially "()" is no longer needed). - Debugger now shows the nesting level and the reasons of failure Tactics - Equality tactics (Rewrite, Reflexivity, Symmetry, Transitivity) now understand JM equality - Simpl and Change now apply to subterms also - "Simpl f" reduces subterms whose head constant is f - Double Induction now referring to hypotheses like "Intros until" - "Inversion" now applies also on quantified hypotheses (naming as for Intros until) - NewDestruct now accepts terms with missing hypotheses - NewDestruct and NewInduction now accept user-provided elimination scheme - NewDestruct and NewInduction now accept user-provided introduction names - Omega could solve goals such as ~`x=y` but failed when the hypothesis was unfolded to `x < y` -> False. This is fixed. In addition, it can also recognize 'False' in the hypothesis and use it to solve the goal. - Coercions now handled in "with" bindings - "Subst x" replaces all ocurrences of x by t in the goal and hypotheses when an hypothesis x=t or x:=t or t=x exists - Fresh names for Assert and Pose now based on collision-avoiding Intro naming strategy (exceptional source of incompatibilities) - LinearIntuition (* no documentation *) - Unfold expects a correct evaluable argument - Clear expects existing hypotheses Extraction (See details in contrib/extraction/CHANGES and README): - An experimental Scheme extraction is provided. - Concerning Ocaml, extracted code is now ensured to always type-check, thanks to automatic inserting of Obj.magic. - Experimental extraction of Coq new modules to Ocaml modules. Proof rendering in natural language - Export of theories to XML for publishing and rendering purposes now includes proof-trees (see http://www.cs.unibo.it/helm) Miscellaneous - Printing Coercion now used through the standard keywords Set/Add, Test, Print - "Print Term id" is an alias for "Print id" - New switch "Unset/Set Printing Symbols" to control printing of symbolic notations - Two new variants of implicit arguments are available - "Unset/Set Contextual Implicits" tells to consider implicit also the arguments inferable from the context (e.g. for nil or refl_eq) - "Unset/Set Strict Implicits" tells to consider implicit only the arguments that are inferable in any case (i.e. arguments that occurs as argument of rigid constants in the type of the remaining arguments; e.g. the witness of an existential is not strict since it can vanish when applied to a predicate which does not use its argument) Incompatibilities - "Grammar tactic ... : ast" and "Grammar vernac ... : ast" are no longer supported, use TACTIC EXTEND and VERNAC COMMAND EXTEND on the ML-side instead - Transparency of le_lt_dec and co (leads to some simplification in proofs; in some cases, incompatibilites is solved by declaring locally opaque the relevant constant) - Opaque Local do not now survive section closing (rename them into Remark/Lemma/... to get them still surviving the sections; this renaming allows also to solve incompatibilites related to now forbidden calls to the tactic Clear) - Remark and Fact have no longer (very) long names (use Local instead in case of name conflict) Bugs - Improved localisation of errors in Syntactic Definitions - Induction principle creation failure in presence of let-in fixed (#238) - Inversion bugs fixed (#212 and #220) - Omega bug related to Set fixed (#180) - Type-checking inefficiency of nested destructuring let-in fixed (#216) - Improved handling of let-in during holes resolution phase (#239) Efficiency - Implementation of a memory sharing strategy reducing memory requirements by an average ratio of 3. Changes from V7.3 to V7.3.1 =========================== Bug fixes - Corrupted Field tactic and Match Context tactic construction fixed - Checking of names already existing in Assert added (PR#182) - Invalid argument bug in Exact tactic solved (PR#183) - Colliding bound names bug fixed (PR#202) - Wrong non-recursivity test for Record fixed (PR#189) - Out of memory/seg fault bug related to parametric inductive fixed (PR#195) - Setoid_replace/Setoid_rewrite bug wrt "==" fixed Misc - Ocaml version >= 3.06 is needed to compile Coq from sources - Simplification of fresh names creation strategy for Assert, Pose and LetTac (PR#192) Changes from V7.2 to V7.3 ========================= Language - Slightly improved compilation of pattern-matching (slight source of incompatibilities) - Record's now accept anonymous fields "_" which does not build projections - Changes in the allowed elimination sorts for certain class of inductive definitions : an inductive definition without constructors of Sort Prop can be eliminated on sorts Set and Type A "singleton" inductive definition (one constructor with arguments in the sort Prop like conjunction of two propositions or equality) can be eliminated directly on sort Type (In V7.2, only the sorts Prop and Set were allowed) Tactics - New tactic "Rename x into y" for renaming hypotheses - New tactics "Pose x:=u" and "Pose u" to add definitions to local context - Pattern now working on partially applied subterms - Ring no longer applies irreversible congruence laws of mult but better applies congruence laws of plus (slight source of incompatibilities). - Field now accepts terms to be simplified as arguments (as for Ring). This extension has been also implemented using the toplevel tactic language. - Intuition does no longer unfold constants except "<->" and "~". It can be parameterized by a tactic. It also can introduce dependent product if needed (source of incompatibilities) - "Match Context" now matching more recent hypotheses first and failing only on user errors and Fail tactic (possible source of incompatibilities) - Tactic Definition's without arguments now allowed in Coq states - Better simplification and discrimination made by Inversion (source of incompatibilities) Bugs - "Intros H" now working like "Intro H" trying first to reduce if not a product - Forward dependencies in Cases now taken into account - Known bugs related to Inversion and let-in's fixed - Bug unexpected Delta with let-in now fixed Extraction (details in contrib/extraction/CHANGES or documentation) - Signatures of extracted terms are now mostly expunged from dummy arguments. - Haskell extraction is now operational (tested & debugged). Standard library - Some additions in [ZArith]: three files (Zcomplements.v, Zpower.v and Zlogarithms.v) moved from contrib/omega in order to be more visible, one Zsgn function, more induction principles (Wf_Z.v and tail of Zcomplements.v), one more general Euclid theorem - Peano_dec.v and Compare_dec.v now part of Arith.v Tools - new option -dump-glob to coqtop to dump globalizations (to be used by the new documentation tool coqdoc; see http://www.lri.fr/~filliatr/coqdoc) User Contributions - CongruenceClosure (congruence closure decision procedure) [Pierre Corbineau, ENS Cachan] - MapleMode (an interface to embed Maple simplification procedures over rational fractions in Coq) [David Delahaye, Micaela Mayero, Chalmers University] - Presburger: A formalization of Presburger's algorithm [Laurent Thery, INRIA Sophia Antipolis] - Chinese has been rewritten using Z from ZArith as datatype ZChinese is the new version, Chinese the obsolete one [Pierre Letouzey, LRI Orsay] Incompatibilities - Ring: exceptional incompatibilities (1 above 650 in submitted user contribs, leading to a simplification) - Intuition: does not unfold any definition except "<->" and "~" - Cases: removal of some extra Cases in configurations of the form "Cases ... of C _ => ... | _ D => ..." (effects on 2 definitions of submitted user contributions necessitating the removal of now superfluous proof steps in 3 different proofs) - Match Context, in case of incompatibilities because of a now non trapped error (e.g. Not_found or Failure), use instead tactic Fail to force Match Context trying the next clause - Inversion: better simplification and discrimination may occasionally lead to less subgoals and/or hypotheses and different naming of hypotheses - Unification done by Apply/Elim has been changed and may exceptionally lead to incompatible instantiations - Peano_dec.v and Compare_dec.v parts of Arith.v make Auto more powerful if these files were not already required (1 occurrence of this in submitted user contribs) Changes from V7.1 to V7.2 ========================= Language - Automatic insertion of patterns for local definitions in the type of the constructors of an inductive types (for compatibility with V6.3 let-in style) - Coercions allowed in Cases patterns - New declaration "Canonical Structure id = t : I" to help resolution of equations of the form (proj ?)=a; if proj(e)=a then a is canonically equipped with the remaining fields in e, i.e. ? is instantiated by e Tactics - New tactic "ClearBody H" to clear the body of definitions in local context - New tactic "Assert H := c" for forward reasoning - Slight improvement in naming strategy for NewInduction/NewDestruct - Intuition/Tauto do not perform useless unfolding and work up to conversion Extraction (details in contrib/extraction/CHANGES or documentation) - Syntax changes: there are no more options inside the extraction commands. New commands for customization and options have been introduced instead. - More optimizations on extracted code. - Extraction tests are now embedded in 14 user contributions. Standard library - In [Relations], Rstar.v and Newman.v now axiom-free. - In [Sets], Integers.v now based on nat - In [Arith], more lemmas in Min.v, new file Max.v, tail-recursive plus and mult added to Plus.v and Mult.v respectively - New directory [Sorting] with a proof of heapsort (dragged from 6.3.1 lib) - In [Reals], more lemmas in Rbase.v, new lemmas on square, square root and trigonometric functions (R_sqr.v - Rtrigo.v); a complementary approach and new theorems about continuity and derivability in Ranalysis.v; some properties in plane geometry such as translation, rotation or similarity in Rgeom.v; finite sums and Chasles property in Rsigma.v Bugs - Confusion between implicit args of locals and globals of same base name fixed - Various incompatibilities wrt inference of "?" in V6.3.1 fixed - Implicits in infix section variables bug fixed - Known coercions bugs fixed - Apply "universe anomaly" bug fixed - NatRing now working - "Discriminate 1", "Injection 1", "Simplify_eq 1" now working - NewInduction bugs with let-in and recursively dependent hypotheses fixed - Syntax [x:=t:T]u now allowed as mentioned in documentation - Bug with recursive inductive types involving let-in fixed - Known pattern-matching bugs fixed - Known Cases elimination predicate bugs fixed - Improved errors messages for pattern-matching and projections - Better error messages for ill-typed Cases expressions Incompatibilities - New naming strategy for NewInduction/NewDestruct may affect 7.1 compatibility - Extra parentheses may exceptionally be needed in tactic definitions. - Coq extensions written in Ocaml need to be updated (see dev/changements.txt for a description of the main changes in the interface files of V7.2) - New behaviour of Intuition/Tauto may exceptionally lead to incompatibilities ---------------------------------------------------------------------------- Changes from V6.3.1 and V7.0 to V7.1 ==================================== Notes: - items followed by (**) are important sources of incompatibilities - items followed by (*) may exceptionally be sources of incompatibilities - items followed by (+) have been introduced in version 7.0 Main novelties ============== References are to Coq V7.1 reference manual - New primitive let-in construct (see sections 1.2.8 and ) - Long names (see sections 2.6 and 2.7) - New high-level tactic language (see chapter 10) - Improved search facilities (see section 5.2) - New extraction algorithm managing the Type level (see chapter 17) - New rewriting tactic for arbitrary equalities (see chapter 19) - New tactic Field to decide equalities on commutative fields (see 7.11) - New tactic Fourier to solve linear inequalities on reals numbers (see 7.11) - New tactics for induction/case analysis in "natural" style (see 7.7) - Deep restructuration of the code (safer, simpler and more efficient) - Export of theories to XML for publishing and rendering purposes (see http://www.cs.unibo.it/helm) Details of changes ================== Language: new "let-in" construction ----------------------------------- - New construction for local definitions (let-in) with syntax [x:=u]t (*)(+) - Local definitions allowed in Record (a.k.a. record à la Randy Pollack) Language: long names -------------------- - Each construction has a unique absolute names built from a base name, the name of the module in which they are defined (Top if in coqtop), and possibly an arbitrary long sequence of directory (e.g. "Coq.Lists.PolyList.flat_map" where "Coq" means that "flat_map" is part of Coq standard library, "Lists" means it is defined in the Lists library and "PolyList" means it is in the file Polylist) (+) - Constructions can be referred by their base name, or, in case of conflict, by a "qualified" name, where the base name is prefixed by the module name (and possibly by a directory name, and so on). A fully qualified name is an absolute name which always refer to the construction it denotes (to preserve the visibility of all constructions, no conflict is allowed for an absolute name) (+) - Long names are available for modules with the possibility of using the directory name as a component of the module full name (with option -R to coqtop and coqc, or command Add LoadPath) (+) - Improved conflict resolution strategy (the Unix PATH model), allowing more constructions to be referred just by their base name Language: miscellaneous ----------------------- - The names of variables for Record projections _and_ for induction principles (e.g. sum_ind) is now based on the first letter of their type (main source of incompatibility) (**)(+) - Most typing errors have now a precise location in the source (+) - Slightly different mechanism to solve "?" (*)(+) - More arguments may be considered implicit at section closing (*)(+) - Bug with identifiers ended by a number greater than 2^30 fixed (+) - New visibility discipline for Remark, Fact and Local: Remark's and Fact's now survive at the end of section, but are only accessible using a qualified names as soon as their strength expires; Local's disappear and are moved into local definitions for each construction persistent at section closing Language: Cases --------------- - Cases no longer considers aliases inferable from dependencies in types (*)(+) - A redundant clause in Cases is now an error (*) Reduction --------- - New reduction flags "Zeta" and "Evar" in Eval Compute, for inlining of local definitions and instantiation of existential variables - Delta reduction flag does not perform Zeta and Evar reduction any more (*) - Constants declared as opaque (using Qed) can no longer become transparent (a constant intended to be alternatively opaque and transparent must be declared as transparent (using Defined)); a risk exists (until next Coq version) that Simpl and Hnf reduces opaque constants (*) New tactics ----------- - New set of tactics to deal with types equipped with specific equalities (a.k.a. Setoids, e.g. nat equipped with eq_nat) [by C. Renard] - New tactic Assert, similar to Cut but expected to be more user-friendly - New tactic NewDestruct and NewInduction intended to replace Elim and Induction, Case and Destruct in a more user-friendly way (see restrictions in the reference manual) - New tactic ROmega: an experimental alternative (based on reflexion) to Omega [by P. Crégut] - New tactic language Ltac (see reference manual) (+) - New versions of Tauto and Intuition, fully rewritten in the new Ltac language; they run faster and produce more compact proofs; Tauto is fully compatible but, in exchange of a better uniformity, Intuition is slightly weaker (then use Tauto instead) (**)(+) - New tactic Field to decide equalities on commutative fields (as a special case, it works on real numbers) (+) - New tactic Fourier to solve linear inequalities on reals numbers [by L. Pottier] (+) - New tactics dedicated to real numbers: DiscrR, SplitRmult, SplitAbsolu (+) Changes in existing tactics --------------------------- - Reduction tactics in local definitions apply only to the body - New syntax of the form "Compute in Type of H." to require a reduction on the types of local definitions - Inversion, Injection, Discriminate, ... apply also on the quantified premises of a goal (using the "Intros until" syntax) - Decompose has been fixed but hypotheses may get different names (*)(+) - Tauto now manages uniformly hypotheses and conclusions of the form "t=t" which all are considered equivalent to "True". Especially, Tauto now solves goals of the form "H : ~ t = t |- A". - The "Let" tactic has been renamed "LetTac" and is now based on the primitive "let-in" (+) - Elim can no longer be used with an elimination schema different from the one defined at definition time of the inductive type. To overload an elimination schema, use "Elim using " (*)(+) - Simpl no longer unfolds the recursive calls of a mutually defined fixpoint (*)(+) - Intro now fails if the hypothesis name already exists (*)(+) - "Require Prolog" is no longer needed (i.e. it is available by default) (*)(+) - Unfold now fails on a non unfoldable identifier (*)(+) - Unfold also applies on definitions of the local context - AutoRewrite now deals only with the main goal and it is the purpose of Hint Rewrite to deal with generated subgoals (+) - Redundant or incompatible instantiations in Apply ... with ... are now correctly managed (+) Efficiency ---------- - Excessive memory uses specific to V7.0 fixed - Sizes of .vo files vary a lot compared to V6.3 (from -30% to +300% depending on the developments) - An improved reduction strategy for lazy evaluation - A more economical mechanism to ensure logical consistency at the Type level; warning: this is experimental and may produce "universes" anomalies (please report) Concrete syntax of constructions -------------------------------- - Only identifiers starting with "_" or a letter, and followed by letters, digits, "_" or "'" are allowed (e.g. "$" and "@" are no longer allowed) (*) - A multiple binder like (a:A)(a,b:(P a))(Q a) is no longer parsed as (a:A)(a0:(P a))(b:(P a))(Q a0) but as (a:A)(a0:(P a))(b:(P a0))(Q a0) (*)(+) - A dedicated syntax has been introduced for Reals (e.g ``3+1/x``) (+) - Pretty-printing of Infix notations fixed. (+) Parsing and grammar extension ----------------------------- - More constraints when writing ast - "{...}" and the macros $LIST, $VAR, etc. now expect a metavariable (an identifier starting with $) (*) - identifiers should starts with a letter or "_" and be followed by letters, digits, "_" or "'" (other characters are still supported but it is not advised to use them) (*)(+) - Entry "command" in "Grammar" and quotations (<<...>> stuff) is renamed "constr" as in "Syntax" (+) - New syntax "[" sentence_1 ... sentence_n"]." to group sentences (useful for Time and to write grammar rules abbreviating several commands) (+) - The default parser for actions in the grammar rules (and for patterns in the pretty-printing rules) is now the one associated to the grammar (i.e. vernac, tactic or constr); no need then for quotations as in <:vernac:<...>>; to return an "ast", the grammar must be explicitly typed with tag ": ast" or ": ast list", or if a syntax rule, by using <<...>> in the patterns (expression inside these angle brackets are parsed as "ast"); for grammars other than vernac, tactic or constr, you may explicitly type the action with tags ": constr", ": tactic", or ":vernac" (**)(+) - Interpretation of names in Grammar rule is now based on long names, which allows to avoid problems (or sometimes tricks;) related to overloaded names (+) New commands ------------ - New commands "Print XML All", "Show XML Proof", ... to show or export theories to XML to be used with Helm's publishing and rendering tools (see http://www.cs.unibo.it/helm) (by Claudio Sacerdoti Coen) (+) - New commands to manually set implicit arguments (+) - "Implicits ident." to activate the implicit arguments mode just for ident - "Implicits ident [num1 num2 ...]." to explicitly give which arguments have to be considered as implicit - New SearchPattern/SearchRewrite (by Yves Bertot) (+) - New commands "Debug on"/"Debug off" to activate/deactivate the tactic language debugger (+) - New commands to map physical paths to logical paths (+) - Add LoadPath physical_dir as logical_dir - Add Rec LoadPath physical_dir as logical_dir Changes in existing commands ---------------------------- - Generalization of the usage of qualified identifiers in tactics and commands about globals, e.g. Decompose, Eval Delta; Hints Unfold, Transparent, Require - Require synchronous with Reset; Require's scope stops at Section ending (*) - For a module indirectly loaded by a "Require" but not exported, the command "Import module" turns the constructions defined in the module accessible by their short name, and activates the Grammar, Syntax, Hint, ... declared in the module (+) - The scope of the "Search" command can be restricted to some modules (+) - Final dot in command (full stop/period) must be followed by a blank (newline, tabulation or whitespace) (+) - Slight restriction of the syntax for Cbv Delta: if present, option [-myconst] must immediately follow the Delta keyword (*)(+) - SearchIsos currently not supported - Add ML Path is now implied by Add LoadPath (+) - New names for the following commands (+) AddPath -> Add LoadPath Print LoadPath -> Print LoadPath DelPath -> Remove LoadPath AddRecPath -> Add Rec LoadPath Print Path -> Print Coercion Paths Implicit Arguments On -> Set Implicit Arguments Implicit Arguments Off -> Unset Implicit Arguments Begin Silent -> Set Silent End Silent -> Unset Silent. Tools ----- - coqtop (+) - Two executables: coqtop.byte and coqtop.opt (if supported by the platform) - coqtop is a link to the more efficient executable (coqtop.opt if present) - option -full is obsolete (+) - do_Makefile renamed into coq_makefile (+) - New option -R to coqtop and coqc to map a physical directory to a logical one (+) - coqc no longer needs to create a temporary file - No more warning if no initialization file .coqrc exists Extraction ---------- - New algorithm for extraction able to deal with "Type" (+) (by J.-C. Filliâtre and P. Letouzey) Standard library ---------------- - New library on maps on integers (IntMap, contributed by Jean Goubault) - New lemmas about integer numbers [ZArith] - New lemmas and a "natural" syntax for reals [Reals] (+) - Exc/Error/Value renamed into Option/Some/None (*) New user contributions ---------------------- - Constructive complex analysis and the Fundamental Theorem of Algebra [FTA] (Herman Geuvers, Freek Wiedijk, Jan Zwanenburg, Randy Pollack, Henk Barendregt, Nijmegen) - A new axiomatization of ZFC set theory [Functions_in_ZFC] (C. Simpson, Sophia-Antipolis) - Basic notions of graph theory [GRAPHS-BASICS] (Jean Duprat, Lyon) - A library for floating-point numbers [Float] (Laurent Théry, Sylvie Boldo, Sophia-Antipolis) - Formalisation of CTL and TCTL temporal logic [CtlTctl] (Carlos Daniel Luna,Montevideo) - Specification and verification of the Railroad Crossing Problem in CTL and TCTL [RailroadCrossing] (Carlos Daniel Luna,Montevideo) - P-automaton and the ABR algorithm [PAutomata] (Christine Paulin, Emmanuel Freund, Orsay) - Semantics of a subset of the C language [MiniC] (Eduardo Giménez, Emmanuel Ledinot, Suresnes) - Correctness proofs of the following imperative algorithms: Bresenham line drawing algorithm [Bresenham], Marché's minimal edition distance algorithm [Diff] (Jean-Christophe Filliâtre, Orsay) - Correctness proofs of Buchberger's algorithm [Buchberger] and RSA cryptographic algorithm [Rsa] (Laurent Théry, Sophia-Antipolis) - Correctness proof of Stalmarck tautology checker algorithm [Stalmarck] (Laurent Théry, Pierre Letouzey, Sophia-Antipolis) --------------000103020403070505040902-- From piotr at !NS! cs.ualberta.ca Wed Jan 18 23:22:54 2006 From: piotr at !NS! cs.ualberta.ca (Piotr Rudnicki) Date: Wed, 18 Jan 2006 16:22:54 -0700 Subject: [Coq-Club]Graph algorithms Message-ID: <20060118232254.GA11948@sedalia.cs.ualberta.ca> Hello, Almost two years ago I asked a question about graph algorithms that had been verified formally. The replies that I have gotten are summarized below. In the meantime, Gilbert Lee finished his MSc thesis in which he proved in Mizar Dijkstra's SSSP, Prim's MST and Floyd-Fulkerson's flow. All done at the level of graph operations. His thesis is at http://www.cs.ualberta.ca/~piotr/Mizar/ and the Mizar articles are at www.mizar.org. Another student of mine, Broderic Arneson, is now formalizing algorithms on chordal graphs following Golumbic's "Algorithmic Graph Theory and Perfect Graphs". If you know of any effort in formalizing similar material (or something new in graph theory in general) please let me know. Sincerely, -- Piotr Rudnicki CompSci, University of Alberta, Edmonton, Canada http://web.cs.ualberta.ca/~piotr -------------------------- Mitsuharu Yamamoto, Koichi Takahashi, Masami Hagiya, Shin-ya Nishizaki and Tetsuo Tamai: Formalization of Graph Search Algorithms and Its Applications, Theorem Proving in Higher Order Logics, 11th International Conference, TPHOLs'98, Canberra, Australia, September/October 1998, Proceedings (Jim Grundy, Malcolm Newey, eds.) Lecture Notes in Computer Science, Springer-Verlag, Vol.1479, 1998, pp.479-496. -------------------------- With Jean-Raymond Abrial and Dominique M?ry we have developed and proved mechanically Prim's MST algorithm. You can find our paper on this web page. http://springerlink.metapress.com/app/home/contribution.asp?wasp=g3twnwwhwj0854qmhqvl&referrer=parent&backto=issue,27,31;journal,361,1541;linkingpublicationresults,1:105633,1 -------------------------- In ACL2 ;A mechanically checked proof of Dijkstra's shortest-path alogrithm ;Qiang Zhang (qzhang@cs.utexas.edu) ;J Strother Moore (moore@cs.utexas.edu) -------------------------- Ranan Fraer did something a while ago with the B method: http://citeseer.ist.psu.edu/fraer97derivation.html -------------------------- In Mizar :: Dijkstra's Shortest Path Algorithm :: by Jing-Chao Chen :: :: Received March 17, 2003 :: Copyright (c) 2003 Association of Mizar Users -------------------------- From jevgenijs at !NS! dva.lv Thu Jan 19 15:46:32 2006 From: jevgenijs at !NS! dva.lv (Jevgenijs Sallinens) Date: Thu, 19 Jan 2006 07:46:32 -0800 Subject: [Coq-Club]theory of inductive datatypes In-Reply-To: References: <80878dd7a061cd244dda2ad872b99d29@cis.upenn.edu> Message-ID: <1137685592.43cfb4581679a@webmail.dva.lv> Quoting Aaron Bohannon : > > Other than this, are there any other improvement for my axiomatization > or any more comments about additional techniques? > I think it is more interesting to include (decidable) equality as one of axiomatization elements, so to consider nat as a setoid, not a type. One of application then could be for lists (with two lists considered equal if their lengthes are equal, we can provide structure of abstract natural numbers). Or we can use axiomatized theory for binary representation of natural numbers. I already formalized quit large piece of the theory (without multiplication) assuming equality as an operator nat -> nat -> bool, but have no time to finalize it to be published or to submit it to Coq contributions. Old and ugly version with modules usage could be downloaded from http://www.mathcoq.dva.lv/downloads/NewNat.zip. Now I prefer to use records (structures) to represent theories, since being first class citizens ( in our case, abstract structures of natural numbers could depend on external parameters). If somebody interested in enhancing this approach or its applications, I will be glad to provide more details. Regards, Jevgenijs Sallinens. ------------------------------------------------- This mail sent through IMP: http://webmail.dva.lv/ From bohannon at !NS! cis.upenn.edu Thu Jan 19 20:11:22 2006 From: bohannon at !NS! cis.upenn.edu (Aaron Bohannon) Date: Thu, 19 Jan 2006 15:11:22 -0500 Subject: [Coq-Club]theory of inductive datatypes In-Reply-To: <1137685592.43cfb4581679a@webmail.dva.lv> References: <80878dd7a061cd244dda2ad872b99d29@cis.upenn.edu> <1137685592.43cfb4581679a@webmail.dva.lv> Message-ID: On Jan 19, 2006, at 10:46 AM, Jevgenijs Sallinens wrote: > I think it is more interesting to include (decidable) equality as one > of > axiomatization elements, Thank you for your suggestion. However, the decidability of equality is derivable given the signature I provided--as are discrimination and injectivity of constructors. Below, I have included a tidied version of the signature NAT, followed by a signature NAT_THEORY with some properties that are derivable. I have written a functor taking a module of type NAT and producing a module of type NAT_THEORY, which contains all of the proofs. > so to consider nat as a setoid, not a type. Hmm...I'm not quite sure what you mean here. Please feel free to clarify. > One of application then could be for lists (with two lists considered > equal if their lengthes are equal, we can provide structure of > abstract natural > numbers). Are you suggesting that using a setoid is a work-around for Coq's intensional equality? > Or we can use axiomatized theory for binary representation of > natural numbers. Here I am trying to abstract away from all representation details. > Now I prefer to use records > (structures) to represent theories, since being first class citizens ( > in our > case, abstract structures of natural numbers could depend on external > parameters). I realize there is a design decision here, but since I am only doing a toy experiment for the time being, modules and functors serve my purposes perfectly well right now. Thank you for you comments. -Aaron Module Type NAT. Parameter N : Set. Parameter zero : N. Parameter succ : N -> N. (* Induction principle. *) Axiom N_rect : forall P : N -> Type, P zero -> (forall n : N, P n -> P (succ n)) -> forall n : N, P n. (* Recursion on zero. *) Axiom N_rect_zero : forall P : N -> Type, forall f_zero : P zero, forall f_succ : (forall n : N, P n -> P (succ n)), N_rect P f_zero f_succ zero = f_zero. (* Recursion on succ. *) Axiom N_rect_succ : forall n : N, forall P : N -> Type, forall f_zero : P zero, forall f_succ : (forall n : N, P n -> P (succ n)), N_rect P f_zero f_succ (succ n) = f_succ n (N_rect P f_zero f_succ n). End NAT. Module Type NAT_THEORY. Declare Module Nat : NAT. Import Nat. Section Properties. Variables m n : N. Parameter is_zero : N -> bool. Axiom is_zero_zero : is_zero zero = true. Axiom is_zero_succ : is_zero (succ n) = false. Parameter pred : N -> N. Axiom pred_zero : pred zero = zero. Axiom pred_succ : pred (succ n) = n. Axiom discriminate : zero <> succ n. Axiom injectivity : succ m = succ n -> m = n. Axiom succ_neq_self : n <> succ n. Axiom decide_equality : {m = n} + {m <> n}. End Properties. End NAT_THEORY. -- Aaron Bohannon http://www.cis.upenn.edu/~bohannon/ From nouvid-coq at !NS! yahoo.fr Mon Jan 23 08:09:39 2006 From: nouvid-coq at !NS! yahoo.fr (Fabrice Lemercier) Date: Mon, 23 Jan 2006 09:09:39 +0100 (CET) Subject: [Coq-Club]Lifting dependent types to option types Message-ID: <20060123080939.74186.qmail@web25906.mail.ukl.yahoo.com> Hello, One can lift a function of type A->B to the type (option A)->(option B) by: Definition lift (A B:Set)(f:A->B)(a:option A) : option B := match a with Some a' => Some (f a') | None => None end. I would like to generalize it to dependent types. First I need to figure out what would be its type. I assume parameters Parameters (A:Set)(B:A->Set)(f:forall a, B a)(a:option A). And then I try Check (match a with None => None | Some a' => Some (f a') end). But Coq replies: User error: Inference of annotation not yet implemented in this case So, what's the type? Thanks, Fabrice. ___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com From roconnor at !NS! theorem.ca Mon Jan 23 08:26:17 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Mon, 23 Jan 2006 03:26:17 -0500 (EST) Subject: [Coq-Club]Lifting dependent types to option types In-Reply-To: <20060123080939.74186.qmail@web25906.mail.ukl.yahoo.com> References: <20060123080939.74186.qmail@web25906.mail.ukl.yahoo.com> Message-ID: On Mon, 23 Jan 2006, Fabrice Lemercier wrote: > Parameters (A:Set)(B:A->Set)(f:forall a, B > a)(a:option A). > > And then I try > > Check (match a with None => None | Some a' => Some > (f a') end). This doesn't work because the type of Some (f a') is option (B a'), so the type of the entire match expression ought to be option (B a'), but this is impossible because the a' would escape its scope of the second case of the match clause. -- Russell O'Connor ``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.'' From nouvid-coq at !NS! yahoo.fr Mon Jan 23 08:33:45 2006 From: nouvid-coq at !NS! yahoo.fr (Fabrice Lemercier) Date: Mon, 23 Jan 2006 09:33:45 +0100 (CET) Subject: [Coq-Club]Lifting dependent types to option types In-Reply-To: Message-ID: <20060123083345.86249.qmail@web25907.mail.ukl.yahoo.com> Does it mean that I cannot generalize my lifting function to dependent types? --- roconnor@theorem.ca a écrit : > This doesn't work because the type of Some (f a') is > option (B a'), so the > type of the entire match expression ought to be > option (B a'), but this is > impossible because the a' would escape its scope of > the second case of > the match clause. ___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com From jean-francois.monin at !NS! imag.fr Mon Jan 23 10:12:17 2006 From: jean-francois.monin at !NS! imag.fr (jean-francois.monin@imag.fr) Date: Mon, 23 Jan 2006 11:12:17 +0100 Subject: [Coq-Club]Lifting dependent types to option types In-Reply-To: <20060123083345.86249.qmail@web25907.mail.ukl.yahoo.com> References: <20060123083345.86249.qmail@web25907.mail.ukl.yahoo.com> Message-ID: <17364.44033.862861.518523@bucher.imag.fr> You can. Parameters (A:Set)(B:A->Set)(f:forall a, B a)(a:option A). Inductive empty :=3D Set :. Definition lift=5FT : Set :=3D match a with None =3D> empty | Some a' =3D> option (B a') end. Definition lift : lift=5FT. unfold lift=5FT; case a. intros a'; exact (Some (f a')). exact None. Defined. Fabrice Lemercier a ecrit : > Does it mean that I cannot generalize my lifting > function to dependent types=3F >=20 > --- roconnor@theorem.ca a =E9crit : --=20 Jean-Fran=E7ois Monin Univ. Joseph Fourier, GRENOBLE VERIMAG - Centre Equation http://www-verimag.imag.fr/~monin/ 2 avenue de Vignate tel (+33 | 0) 4 56 52 03 72 F-38610 GIERES fax (+33 | 0) 4 56 52 03 44=20 From roconnor at !NS! theorem.ca Mon Jan 23 09:34:50 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Mon, 23 Jan 2006 04:34:50 -0500 (EST) Subject: [Coq-Club]Lifting dependent types to option types In-Reply-To: <17364.44033.862861.518523@bucher.imag.fr> References: <20060123083345.86249.qmail@web25907.mail.ukl.yahoo.com> <17364.44033.862861.518523@bucher.imag.fr> Message-ID: On Mon, 23 Jan 2006 jean-francois.monin@imag.fr wrote: > You can. I think you mean to say: Section Foo. Variable (A:Set)(B:A->Set)(f:forall a, B a)(a:option A). Definition lift_T : Set := match a with None => unit | Some a' => option (B a') end. Definition lift : lift_T. unfold lift_T; case a. intros a'; exact (Some (f a')). constructor. Defined. End Foo. Check lift. lift : forall (A : Set) (B : A -> Set), (forall a : A, B a) -> forall a : option A, lift_T A B a -- Russell O'Connor ``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.'' From roconnor at !NS! theorem.ca Mon Jan 23 09:43:32 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Mon, 23 Jan 2006 04:43:32 -0500 (EST) Subject: [Coq-Club]Lifting dependent types to option types In-Reply-To: <20060123083345.86249.qmail@web25907.mail.ukl.yahoo.com> References: <20060123083345.86249.qmail@web25907.mail.ukl.yahoo.com> Message-ID: On Mon, 23 Jan 2006, Fabrice Lemercier wrote: > Does it mean that I cannot generalize my lifting > function to dependent types? I suggest returning option {a0 : A & B a0}: Section Foo. Variable (A:Set)(B:A->Set)(f:forall a, B a)(a:option A). Definition lift : option {a:A & (B a)} := match a with None => None | Some a' => Some (existS (fun x => B x) a' (f a')) end. End Foo. Check lift. lift : forall (A : Set) (B : A -> Set), (forall a : A, B a) -> option A -> option {a0 : A & B a0} -- Russell O'Connor ``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.'' From jean-francois.monin at !NS! imag.fr Mon Jan 23 10:57:01 2006 From: jean-francois.monin at !NS! imag.fr (jean-francois.monin@imag.fr) Date: Mon, 23 Jan 2006 11:57:01 +0100 Subject: [Coq-Club]Lifting dependent types to option types In-Reply-To: References: <20060123083345.86249.qmail@web25907.mail.ukl.yahoo.com> <17364.44033.862861.518523@bucher.imag.fr> Message-ID: <17364.46717.414920.495052@bucher.imag.fr> Matter of taste, since option empty is isomorphic to unit. One may prefer to return option something in all cases. JF roconnor@theorem.ca a ecrit : > On Mon, 23 Jan 2006 jean-francois.monin@imag.fr wrote: > > > You can. > > I think you mean to say: > > Section Foo. > > Variable (A:Set)(B:A->Set)(f:forall a, B > a)(a:option A). > > Definition lift_T : Set := > match a with None => unit | Some a' => option (B a') end. > > Definition lift : lift_T. > unfold lift_T; case a. > intros a'; exact (Some (f a')). > constructor. > Defined. > > End Foo. > > Check lift. > > lift > : forall (A : Set) (B : A -> Set), > (forall a : A, B a) -> forall a : option A, lift_T A B a > > > -- > Russell O'Connor > ``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://coq.inria.fr/bin/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 jean-francois.monin at !NS! imag.fr Mon Jan 23 13:06:44 2006 From: jean-francois.monin at !NS! imag.fr (jean-francois.monin@imag.fr) Date: Mon, 23 Jan 2006 14:06:44 +0100 Subject: [Coq-Club]Lifting dependent types to option types In-Reply-To: References: <20060123083345.86249.qmail@web25907.mail.ukl.yahoo.com> <17364.44033.862861.518523@bucher.imag.fr> <17364.46717.414920.495052@bucher.imag.fr> Message-ID: <17364.54500.998027.474372@bucher.imag.fr> You're right, I meant: Definition lift_T : Set := match a with None => option empty | Some a' => option (B a') end. Thanks, JF roconnor@theorem.ca a ecrit : > On Mon, 23 Jan 2006 jean-francois.monin@imag.fr wrote: > > > Matter of taste, since option empty is isomorphic to unit. > > One may prefer to return option something in all cases. > > Ah. You omitted `option' and just wrote `empty' in your mail, so the code > didn't work for me. > > -- > Russell O'Connor > ``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.'' > > From jevgenijs at !NS! dva.lv Fri Jan 20 16:02:51 2006 From: jevgenijs at !NS! dva.lv (Jevgenijs Sallinens) Date: Fri, 20 Jan 2006 08:02:51 -0800 Subject: [Coq-Club]theory of inductive datatypes In-Reply-To: References: <80878dd7a061cd244dda2ad872b99d29@cis.upenn.edu> <1137685592.43cfb4581679a@webmail.dva.lv> Message-ID: <1137772971.43d109abc16f1@webmail.dva.lv> Quoting Aaron Bohannon : > On Jan 19, 2006, at 10:46 AM, Jevgenijs Sallinens wrote: > > > I think it is more interesting to include (decidable) equality as one > > of > > axiomatization elements, > > Thank you for your suggestion. However, the decidability of equality > is derivable given the signature I provided--as are discrimination and > injectivity of constructors. > I mean something like following (just ideas, no details). Then you are able to apply this theory to implementations of NAT with abstract equality (different from Leibniz equality, which is computational equality,related with specific structure used for representation of natural numbers). Such an equality together with its properties is called setoid. Unfortunately Coq doesn't provide simple reasoning with setoids, so some user written tacics required to help with complicated cases. Best Regards, Jevgenijs. Module Type NAT. Parameter N : Set. Parameter equal:N -> N -> Prop. Axiom equal_refl ..... Axiom equal_sym ..... Axiom equal_trans ..... Axiom decide_equality .... Parameter zero : N. Parameter succ : N -> N. Axiom succ_inv: forall n1 n2, equal n1 n2 -> equal (succ n1) (succ n2). (* Induction principle. *) Axiom N_induction : forall P : N -> Prop, (forall n1 n2, equal n1 n2 -> P n1 -> P n2) -> P zero -> (forall n : N, P n -> P (succ n)) -> forall n : N, P n. and so on ......................... End NAT. ------------------------------------------------- This mail sent through IMP: http://webmail.dva.lv/ From floc at !NS! informatik.hu-berlin.de Mon Jan 23 19:13:54 2006 From: floc at !NS! informatik.hu-berlin.de (Kreutzer + Schweikardt) Date: Mon, 23 Jan 2006 20:13:54 +0100 (CET) Subject: [Coq-Club]FLoC'06 - Call for Papers Message-ID: <20060123191354.B8363DC3A@banach.informatik.hu-berlin.de> FLoC'06 - Call for Papers The 2006 Federated Logic Conference Seattle, Washington, USA August 10 -- August 22, 2006 http://research.microsoft.com/floc06/ In 1996, as part of its Special Year on Logic and Algorithms, DIMACS hosted the first Federated Logic Conference (FLoC). It was modeled after the successful Federated Computer Research Conference (FCRC), and synergetically brought together conferences that apply logic to computer science. The second Federated Logic Conference (FLoC'99) was held in Trento, Italy, in 1999, and the third (FLoC'02) was held in Copenhagen, Denmark, in 2002. The Fourth Federated Logic Conference (FLoC'06) will be held in Seattle, Washington, in August 2006, at the Seattle Sheraton (http://www.sheraton.com/seattle). The following conferences will participate in FLoC'06: Int'l Conference on Computer-Aided Verification (CAV) Int'l Conference on Rewriting Techniques and Applications (RTA) IEEE Symposium on Logic in Computer Science (LICS) Int'l Conference on Logic Programming (ICLP) Int'l Conference on Theory and Applications of Satisfiability Testing (SAT) Int'l Joint Conference on Automated Reasoning (IJCAR) In addition, FLoC'06 will host 42 workshops. Pre-conference workshops will be held on August 10-11. LICS, RTA, and SAT will be held in parallel on August 12-15, to be followed by mid-conference workshops and excursions on August 15-16. CAV, ICLP, and IJCAR will be held in parallel on August 16-21, to be followed by post-conference workshops on August 21-22. Plenary events involving all the conferences are planned. Calls for papers for the conferences and workshops are available at the conference website: http://research.microsoft.com/floc06/. We invite you to submit papers to FLoC'06 conferences and workshops. FLoC'06 Steering Committee Moshe Y. Vardi (General Chair) Jakob Rehof (Conference Chair) Edmund Clarke (CAV) Reiner Hahnle (IJCAR) Manuel Hermenegildo (ICLP) Phokion Kolaitis (LICS) Henry Kautz (SAT) Aart Middeldorp (RTA) Andrei Voronkov (IJCAR) From mulhern at !NS! gmail.com Sun Jan 29 16:14:49 2006 From: mulhern at !NS! gmail.com (mulhern) Date: Sun, 29 Jan 2006 10:14:49 -0600 Subject: [Coq-Club]Observation about auto and family Message-ID: <54f15b6e0601290814y5a155ae7w8fcb4e01d2600d3e@mail.gmail.com> Hi! I'm working with a lot of proofs that have an inductive structure. I generally have many of the proofs for the subgoals produced by the induction tactic already on hand. I'm using the Coq database facility and auto or eauto as the case may be to persuade Coq to use the appropriate proofs for the subgoals. And all this works, which is good. But, it takes an unnecessarily long time. My proofs of the subgoals already exist in the exact form left after the induction step. Thus, "exact " will always work when applied to subgoal1 and so forth. Unfortunately, auto doesn't check this out before introducing all the hypotheses in the subgoals. Because of this, I'm forced in some cases to use eauto in order to handle the meta-variables that are introduced by matching only the head of the subgoal against only the head of my subproof. This seems to take a fairly long time and also introduces many more or less unnecessary application of Sumbool.sumbool_not. For various engineering reasons I prefer using databases and auto or eauto, rather than specifying the subproofs explicitly after the induction step in my main proof as "try solve [ proof1 | proof2 | ... | proofn]" or something like that. Is there any way to prevent auto from throwing in these intro steps? Or is there any other tactic that will do what I need? Has any one else run into a similar problem? -mulhern From Laurent.Thery at !NS! sophia.inria.fr Sat Jan 28 14:20:30 2006 From: Laurent.Thery at !NS! sophia.inria.fr (Laurent Thery) Date: Sat, 28 Jan 2006 15:20:30 +0100 Subject: [Coq-Club]Soduko contrib Message-ID: <200601281420.k0SEKUvv005368@rem.inria.fr> Hi, just for fun I´ve implemented and proved the correctness of a naive Davis-Putnam procedure to solve Sodukos. A soduko is represented as a mono-dimensional list of natural numbers. Zeros represent empty cells. For example, for 3x3 sodukos: ------------------------------------- | | | 8 | 1 | 6 | | 9 | | | ------------------------------------- | | | 4 | | 5 | | 2 | | | ------------------------------------- | 9 | 7 | | | | 8 | | 4 | 5 | ------------------------------------- | | | 5 | | | | | | 6 | ------------------------------------- | 8 | 9 | | | | | | 3 | 7 | ------------------------------------- | 1 | | | | | | 4 | | | ------------------------------------- | 3 | 6 | | 5 | | | | 8 | 4 | ------------------------------------- | | | 2 | | 7 | | 5 | | | ------------------------------------- | | | 7 | | 4 | 9 | 3 | | | ------------------------------------- is represented as 0 :: 0 :: 8 :: 1 :: 6 :: 0 :: 9 :: 0 :: 0 :: 0 :: 0 :: 4 :: 0 :: 5 :: 0 :: 2 :: 0 :: 0 :: 9 :: 7 :: 0 :: 0 :: 0 :: 8 :: 0 :: 4 :: 5 :: 0 :: 0 :: 5 :: 0 :: 0 :: 0 :: 0 :: 0 :: 6 :: 8 :: 9 :: 0 :: 0 :: 0 :: 0 :: 0 :: 3 :: 7 :: 1 :: 0 :: 0 :: 0 :: 0 :: 0 :: 4 :: 0 :: 0 :: 3 :: 6 :: 0 :: 5 :: 0 :: 0 :: 0 :: 8 :: 4 :: 0 :: 0 :: 2 :: 0 :: 7 :: 0 :: 5 :: 0 :: 0 :: 0 :: 0 :: 7 :: 0 :: 4 :: 9 :: 3 :: 0 :: 0 :: nil. All functions are parametrized by the height and width of its subrectangles. For example for 3x3, soduko 3 3: list nat -> Prop check 3 3: forall l, {soduko 3 3 l} + {~ soduko 3 3 l} find_one 3 3: list nat -> option (list nat) find_all 3 3: list nat -> list (list nat) It can be downloaded at ftp://ftp-sop.inria.fr/lemme/Laurent.Thery/Soduko.zip Have fun, -- Laurent Théry From jasper at !NS! codeyard.net Mon Jan 30 09:10:05 2006 From: jasper at !NS! codeyard.net (Jasper Stein) Date: Mon, 30 Jan 2006 10:10:05 +0100 Subject: [Coq-Club]Observation about auto and family In-Reply-To: <54f15b6e0601290814y5a155ae7w8fcb4e01d2600d3e@mail.gmail.com> References: <54f15b6e0601290814y5a155ae7w8fcb4e01d2600d3e@mail.gmail.com> Message-ID: <200601301010.06231.jasper@codeyard.net> Op zondag 29 januari 2006 17:14, schreef mulhern: > But, it takes an unnecessarily long time. My proofs of the subgoals > already exist in the exact form left after the induction step. Thus, > "exact " will always work when applied to subgoal1 and so > forth. There is also the tactic "assumption" which will look in your local context. So instead of "auto" you might want to do "assumption; auto" to check for hypotheses first, and then applying auto in case it doesn't solve it immediately. Jasper Stein (Team CodeYard) -- (Vragen? Kijk op de website, of anders info@codeyard.net) From pierre.courtieu at !NS! gmail.com Mon Jan 30 09:44:33 2006 From: pierre.courtieu at !NS! gmail.com (Pierre Courtieu) Date: Mon, 30 Jan 2006 10:44:33 +0100 Subject: [Coq-Club]Observation about auto and family In-Reply-To: <200601301010.06231.jasper@codeyard.net> References: <54f15b6e0601290814y5a155ae7w8fcb4e01d2600d3e@mail.gmail.com> <200601301010.06231.jasper@codeyard.net> Message-ID: <20060130104433.3d32c95a@localhost.localdomain> On Mon, 30 Jan 2006 10:10:05 +0100 Jasper Stein wrote: > There is also the tactic "assumption" which will look in your local > context. So instead of "auto" you might want to do "assumption; auto" > to check for hypotheses first, and then applying auto in case it > doesn't solve it immediately. > > > Jasper Stein (Team CodeYard) Try also the "trivial" tactic, which is also very basic. You can also put a numerical argument to auto to fix the search depth of auto (default = 5). For example, auto 1. auto 2. This also works for eauto. Actually it is not exactly the search depth: the numerical argument refers to the cost attached to tactics composed. See documentation of auto and hints. Cheers, Pierre Courtieu From roconnor at !NS! theorem.ca Mon Jan 30 14:27:55 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Mon, 30 Jan 2006 09:27:55 -0500 (EST) Subject: [Coq-Club]Proposal for Finite Types in the Standard Library Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --38318084-1143253296-1138631197=:27344 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I've made a small library for finite types of n elements (Fin n):Set and I believe this is sufficiently general that it ought to be included in the standard library. I present two possible implementations of the same theory. The first implementation (Fin.v) defines a finite type as an inductive family: Inductive Fin : nat -> Set := | FinOld : forall n, Fin n -> Fin (S n) | FinNew : forall n, Fin (S n). Reasoning with this type is made easy by using the induction lemma FinSn_rect, which provides an elimination rule for the type Fin (S n). This elimination rule make programming with this inductive family a dream. Anytime x:Fin (S n) is in the content, the command ``destruct x using FinSn_rect'' break it into two cases without complaint. The lemma FinOldOrNew : forall n, forall y:Fin (S n), {z:Fin n | y=(FinOld z)}+{y=FinNew n} is provided for those few occasions when FinSn_rect isn't quite good enough for you. This library requires K_dec_set to be extended to work with predicates defined over Type instead of Prop. This extension ought be done inside Eqdep_dec, but I provide Eqdep_dec_Type for now. The alternative implementation (FinAlt.v) that I made defines Fin as a fixpoint: Fixpoint Fin (n:nat) : Set := match n with | O => Empty_set | (S m) => (unit+(Fin m))%type end. This implementation doesn't require FinSn_rect, but I include it for compatibility (the proof is trivial). The advantage of this is that objects of type Fin (S n) can be destructed by intros patterns which is nice. The disadvantage of the Fixpoint definition, pointed out to me by Pierre Corbineau, is that the type doesn't extract well. In Haskell Fin is extracted to the () type, which is probably the extraction mechanisms way of saying ``I give up''. unsafeCoercion is applied everywhere to force everything into the () type. This means the Fin type can't be reasonably used to interface with non-extracted code. For the above reason, I recommend that the inductive definition for Fin. -- Russell O'Connor ``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.'' --38318084-1143253296-1138631197=:27344 Content-Type: APPLICATION/x-gzip; name="Fin.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="Fin.tar.gz" H4sIAEEi3kMAA+1ZbW/bOBLOZ/0KfllEuiY+OU1TwKmDy2JTOLjg4m76rVsY ik27KmRaleRUyst/v2dIUaJk5aW7zXb3jhMglsjhcN5nSJ18mfF4MuPTyfsi 5r2rrWcAv+/7B/v7W77v9/svX5q/BPuv+/2tvv/y4PV+/9XBwQHw9/f911vM fw5m2rBOsyBhbCtZTVdCrJL78B6b/5vCr/zLOkw4O8njVZKxE+0OPcf5hc9D EWbhSrB/Vx7CBkPmzNeCHbMBkwPDIyfiGZuuljEmHcZo1s1ZwYpt4Bx7zOVf +njK2ZAV8m1Pv217tJwx/mUSihnGXFoc0DJM4EHh0IqCEZVQyM1BgzgC3nyV BFHEaDss2lFk2W//xMObI7ldrpgo2RRrg8mi5G9dcyfZWQbZ9BMr9yDSX8Ps E8Zv2SoBo1myijCbF8Qj/TamEib03NsgSrmUzNXCq7m1R0JjHPIoribwLnii yDrZu+piEL/MZDJI2UqOJTxbJ0I+MuYqYVZaBgkPCNKaf7I0EkikoX55/o2v zI3puctORCHh82gCTw/w3jaW0mjFsKaIiTWpdF6qk7mbbMzx08UcGNOcGcKD xw2rh+Kqw+ANc6vIyqWJXbgvgsQQJ/c8eIcOi3G5MGe7RzI6QWyEsfHGGjfW qNKl4EYJn2YtNBWOsV9RBTdjvHtsxGIwTWEYJ6vVPJ2sRTgNs0L7Y4tO7HXl k5RnOqco9imnXPCsZLod2jdSJXfsBT1RcN9V0U28dMruf4Pwk4SNiZCR7CbK dFINua8YafkLVCFnDEPfsojPM+l5lTfVOc5X5ApfZzmMDOmVkpYvBfM9Yx22 r73ZVRg5TNAQyodUhfRtxUASLj5lpm8T1E7vqj1b2xBbCCzSjZxurpYh4T4m xQZfIAOaVTxQoLKJWsybfgXa7/ewPYcsMBzVCYzAd2TNAMX3k8vws/KlM75c BnD7zxMp6SQOwgRVxdFOU3rSjoOdnuBGu0fVSl0vpD8dky8pjyzL2Rg+A6o8 D9Psgt5ITY3XbVpTyMrVc8YUHT1Hqj3tOfB4cITBz0bUkxrScIHl2GbG5+Uu jVJUZ7Zyq3yboVJ3+OI2eOjwxS8KmylfJ7SxJJCrqQp7Qkhgop2zPCib/aPn TNdZKYBrCu1JiTfHUbwL2CsNl3FEFG53iQg8aD2ViQCBjszmlRpiXKvoZ6Wf Kk+wkVO56LXhNo4OLSkU9izw/5osYgxty7HdbuRWptpc2UoeTT7+GLFKgGsP vQ7XOg7iOCrYzz2HR+GSXWJgna16TsK/JmHGERv0PI+g5yuk3J7zjs96zu/s /96G4jjKnqfv1/BI/3/Q39s3+v9XwN+jI4Ht//8E0P3/6TJYIPrqV3kcOEMk I9siA9JIRCWeHSeL9ZKLDOnMeRvi2IDQZXAjNCcDESBVysxL8atyklDp6Jad U2o5WcZZQRGNAfeCLWWH46J7yF64RGTpeT9lKL0Ock6zZ8Dsf/hXYxe55wUT Hp1JQoHUTSN4zbKNlefRrFrp5oMScYNGwogTlmP9pryazgfxsapANKQ6p6pf GQ+oddiRpM+pFoyrMjDjaZYg87F+T/FHgVtTuhAlqaoYiZ26Lo0HFbO7R7K/ MapboUTaoTJasll4qq6pEVKdaBS6nJDzVomCtcZUfEd99uHDx9uPh0zlng5u scd5QmQHNbc4Gpr8SGYxeHOt2EN9KYaav2vv7sVNMdS83W1yQhwUFQtUx5AS qbikrHiYsVPxuWETcFa3AVpVmpHcG9Y6I4Plw2KTGSr0o56zFvMVEEt8EMIY EsMiWXMx5WUudkYUE7/ydBVd8Q2WQmFy+wufhjN+QhWB+ucOlt2KZ4+6l2EB veVvjgpTY7qeCsPJ8rLuVkKQPvOPDbUesizBsUI2UYdsFqbTJFyGCBPuGZTc 05FUgKescAi5s7WMrUNmCl+SuWe2w1RvpYTnyQlZ1ZCdOWi/3imhd48gZUxu 5NaeewPXhRre4b80mXOTVy6mpmpcQupWVakXbEVmlNw39ddEqPUxMmLKa7lm PaN9tKlHdZgYHrljwwO9ZivOaqx3T8HSHGk003hpB38KT/NXCt7wkkP4aZJm q2TGE9N0zbR61jQb7BINIhrTqfjWyDan5EPRXd0NN2yhufuXCMtM7jfEyI1n qLFeQBcnZopzl0EMMqWUGMg9ryEc+b4MjJb800+BWHAYSRg5tCRXl5AhLK5I qjYtFBNgKFKy0lEH1+HqKv4hbPVg+vuyivZ5nTnJscuXJfxflehQLUdemeBv Tjg3i9L3S/wl1N6FvOjIsUuQaLi2mdnduennLafS+pc3dooBtLOq5ndRIf0F oKLbAVRsOpnIU0mMg0N/gkMQi+WMOr7Ks0hOnUBtwIBdsuNH+NU7qeRW83z4 +LLLzmXV8eVYW93M6XqsVQmCNOVoodyao2EjaXQuMjOwbPTbVC5/H5VvZdrI tKr2kE/NjdxBN19ljNzV1smfYJlcepKKPFM6JdLQQHuqdKYnUsqsvYkugNR+ 97kPEAKvNXBpnli/xeQPhf1Z9lC817H7QJwL9mbIll2lrJV+KmmW+mBtNp/N qK5UI/OAEuuM9yI+EZOLljk7ctgIBMxKQf3Pjz7TWHg6wKrPe/jfevz8/+pg r33+33t1YM//fwa0DvwPXQO0Bk+aX47b02MeiFX5JfHe+4NTlcLUIQn5ESm9 vHGl+4NbXWLMDrORLWWbpPDaJ9FqWjatCe1xKq54kuobAXXWlimzbDfZBTGu pPmrnsrzqk/NS96rTzeyZaQN8/LZvGyUI5TtF1xw7BRe8455ef3K3GwwLAfK G8ny1Jsx2GeP7VNZiNGWwYpA0ErND2s8tSxdX+IsIPy65Y+DLOOJoIteVWqa X4L0KGSCKyjvKc+wrTvQPegh4ojcnNEOckBu8sf3+BF3HUahLdg6DcXCcL2/ 1g1IbfBRfQZqfodRjjkeDNUnpTKwhypmhVcdPDcN8YOvT/LDx+3w5CuT/9kL k0NW8V3F/v/nXYl53snvjdvvfXvy+K1JgLybBNOsaaHvcH+S+6bEfofIXTcr 5k1J9fZMtyRPvB+xNyP2ZsTejPzNbka++52I7HZT6lNa4VznzbTrgsTejliw YMGCBQsWLFiwYMGCBQsWLFiwYMGCBQsWLFiwYMGCBQsWLFiwYOHHw38BSZKS RABQAAA= --38318084-1143253296-1138631197=:27344-- From mulhern at !NS! gmail.com Mon Jan 30 16:59:47 2006 From: mulhern at !NS! gmail.com (mulhern) Date: Mon, 30 Jan 2006 10:59:47 -0600 Subject: [Coq-Club]Observation about auto and family In-Reply-To: <20060130104433.3d32c95a@localhost.localdomain> References: <54f15b6e0601290814y5a155ae7w8fcb4e01d2600d3e@mail.gmail.com> <200601301010.06231.jasper@codeyard.net> <20060130104433.3d32c95a@localhost.localdomain> Message-ID: <54f15b6e0601300859p8a800c9r3a54c22bccbf9e59@mail.gmail.com> Hi! Thanks for the answers. I'm afraid I wasn't sufficiently explicit about my constraints. I don't want to mention my subproofs directly in the main proof at all; the inductive type on which I do my induction changes a lot, so I'ld have to update the main proof constantly in response to these changes. For this reason, explicitly adding the subproofs to the context of the main proof and then using assumption is no better for me than explicitly mentioning the subproofs in a tactic step. "trivial" doesn't help because it tries only hints where the cost is 0. Even if I set the cost of my hints to 0 trivial can't succeed (presumably because it also introduces hypotheses and once the hypotheses are in the context instead of the goal the cost of the proof goes up). I tried giving my hints a -1 cost, but that didn't parse very well ;) Using the Extern keyword so that I can explicitly set the cost of subproofs to 0 and capping the search depth of eauto seems to make the proof pretty fast. But it's also delicate. By setting num too low I get Coq to run a very long time and then to fail. What I really want is the "assumption with " tactic. But I might have to wait for that. -mulhern On 1/30/06, Pierre Courtieu wrote: > On Mon, 30 Jan 2006 10:10:05 +0100 Jasper Stein > wrote: > > > There is also the tactic "assumption" which will look in your local > > context. So instead of "auto" you might want to do "assumption; auto" > > to check for hypotheses first, and then applying auto in case it > > doesn't solve it immediately. > > > > > > Jasper Stein (Team CodeYard) > > Try also the "trivial" tactic, which is also very basic. > > You can also put a numerical argument to auto to fix the search depth > of auto (default = 5). > > For example, > > auto 1. > auto 2. > > > This also works for eauto. > > Actually it is not exactly the search depth: the numerical argument > refers to the cost attached to tactics composed. See documentation of > auto and hints. > > Cheers, > > Pierre Courtieu > From carlos at !NS! math.unice.fr Tue Jan 31 09:17:15 2006 From: carlos at !NS! math.unice.fr (Carlos.SIMPSON) Date: Tue, 31 Jan 2006 10:17:15 +0100 Subject: [Coq-Club]Proposal for Finite Types in the Standard Library In-Reply-To: References: Message-ID: <43DF2B1B.9000108@math.unice.fr> Dear Russell, Coq's inductive types have a new functionality which allows one to define a wider range of parametric inductive types than before. This should allow the definition of Fin n as a parametric inductive type with n as a parameter. (NB: This functionality was used by Marco Maggesi in his contribution defining the Lambda calculus using this new kind of inductive type--Carlos) . One encounters a little problem due to the fact that (pred 0) = 0. Here is a quick work-around to give a definition. We aren't sure if this could simplify the treatment of finite types, if there is a better work-around, etc.; however, in reply to your message, we feel that it would be good to ask whether it is possible to give a more streamlined treatment of finite types using this new kind of parametrized inductive type. Here is a proposition for some code, not sure it compiles though:-(? (In any case it would require a very recent edition of Coq). Definition is_zero (n:nat) : bool := match n with 0 => true | S m => false end. Definition non_zero (n:nat) : bool := match n with 0 => false | S m => true end. Inductive boolset : bool -> Set := boolset : boolset true. (* recall pred n = n-1, the only problem is pred 0 = 0. That is why we define FinConditional first. *) Inductive FinConditional (n : nat) : bool -> Set := | fin_prev : FinConditional (pred n) (non_zero n) -> Fin n true | fin_zero : boolset (is_zero n) -> FinConditional n true. Definition Fin n := FinConditional n true. Briefly, FinConditional n false is supposed to always be empty. Thus fin_prev doesn't introduce anything new if n=0. For n=0 the constructer is fin_zero (which in turn doesn't introduce anything if n>0). ---Marco Maggesi and Carlos Simpson From treinen at !NS! lsv.ens-cachan.fr Mon Jan 30 17:41:01 2006 From: treinen at !NS! lsv.ens-cachan.fr (Ralf Treinen) Date: Mon, 30 Jan 2006 18:41:01 +0100 Subject: [Coq-Club]3rd Call for Papers RTA'06 Message-ID: <200601301741.k0UHf1HB004285@dell67009.lsv.ens-cachan.fr> *********************************** * * * RTA'06 THIRD CALL FOR PAPERS * * * *********************************** http://rta06.csl.sri.com/ Seattle, WA, USA August 12-14, 2006 Affiliated workshops Aug 11 & 15 The 17th International Conference on Rewriting Techniques and Applications (RTA'06) is organized as part of the Federated Logic Conference (FLoC), collocated with CAV, ICLP, IJCAR, LICS, SAT, and several affiliated workshops. IMPORTANT DATES: Feb 15, 2006: Deadline for electronic submission of title and abstract Feb 22, 2006: Deadline for electronic submission of papers May 01, 2006: Notification of acceptance of papers Jun 01, 2006: Deadline for final versions of accepted papers RTA is the major forum for the presentation of research on all aspects of rewriting. Typical areas of interest include (but are not limited to): * Applications: case studies; rule-based (functional and logic) programming; symbolic and algebraic computation; theorem proving; system synthesis and verification; proof checking; reasoning about programming languages and logics; * Foundations: matching and unification; narrowing; completion techniques; strategies; constraint solving; explicit substitutions; tree automata; termination; * Frameworks: string, term, graph, and proof rewriting; lambda-calculus and higher-order rewriting; proof nets; constrained rewriting/deduction; categorical and infinitary rewriting; * Implementation: compilation techniques; parallel execution; rewrite tools; termination checking; * Semantics: equational logic; rewriting logic. The following workshops are affiliated with RTA'06: * HOR'06: 3rd International Workshop on Higher-Order Rewriting * RULE'06: 7th International Workshop on Rule-Based Programming * UNIF'06: 20th International Workshop on Unification * WG1.6: Annual meeting of the IFIP Working Group 1.6 on Term Rewriting. * WRS'06: 6th International Workshop on Reduction Strategies in Rewriting and Programming * WST'06: 8th International Workshop on Termination Please refer to the RTA'06 web site for further information on the workshops. INVITED TALKS: * Randy Bryant (jointly with LICS and SAT): Formal Verification of Infinite State Systems using Boolean Methods. * Javier Esparza: Rewriting Models of Control-Flow * Juergen Giesl: Automated Termination Analysis for Haskell: From Term Rewriting to Programming Languages BEST PAPER AWARDS AND TRAVEL GRANTS: An award is given to the best paper or papers as decided by the program committee. A limited number of travel grants may be available for students who are (co-)authors of RTA-papers. To apply for grants, students should send an e-mail to the PC chair together with their submission. RTA'06 PROGRAM COMMITTEE CHAIR: * Frank Pfenning, Carnegie Mellon University RTA'06 PROGRAM COMMITTEE: * Zena Ariola, University of Oregon * Franz Baader, Technical University Dresden * Gilles Dowek, Ecole Polytechnique and INRIA * Guillem Godoy, Technical University of Catalonia * Deepak Kapur, University of New Mexico * Delia Kesner, University Paris 7 * Denis Lugiez, University of Provence * Claude Marche, University Paris-Sud * Jose Meseguer, University of Illinois at Urbana-Champaign * Frank Pfenning, Carnegie Mellon University (Chair) * Ashish Tiwari, SRI International * Yoshihito Toyama, Tohoku University * Eelco Visser, Utrecht University * Hans Zantema, Eindhoven University of Technology RTA'06 CONFERENCE CHAIR: * Ashish Tiwari, SRI International RTA'06 SUBMISSIONS: Submissions must be original and not submitted for publication elsewhere. Submission categories include regular research papers and system descriptions. Problem sets and submissions describing interesting applications of rewriting techniques are also welcome. The page limit for submissions is 15 pages in Springer Verlag LNCS style (10 pages for system descriptions). Please consult http://rta06.csl.sri.com/ for further instructions. Submissions are now open at http://www.easychair.org/RTA-06/submit/ LOCATION, TRAVEL, ACCOMMODATION, AND REGISTRATION: RTA'06 will be part of the 2006 Federated Logic Conference (FLoC 2006) which will be held Augucst 10-22, 2006, at the Seattle Sheraton Hotel and Towers, in Seattle, Washington state, USA. Further information will be made available at the FLoC 2006 home page http://research.microsoft.com/floc06/index.htm. From carlos at !NS! math.unice.fr Tue Jan 31 09:24:46 2006 From: carlos at !NS! math.unice.fr (Carlos.SIMPSON) Date: Tue, 31 Jan 2006 10:24:46 +0100 Subject: [Coq-Club]Finite Types: Sorry a little modif! In-Reply-To: References: Message-ID: <43DF2CDE.7060408@math.unice.fr> Sorry about this but the definition in the previous message wasn't right: this should be better and also it no longer needs boolset: Definition non_zero (n:nat) : bool := match n with 0 => false | S m => true end. Inductive FinConditional (n : nat) : bool -> Set := | fin_prev : FinConditional (pred n) (non_zero n) -> Fin n true | fin_next : FinConditional n true. Definition Fin n := FinConditional n true. From roconnor at !NS! theorem.ca Tue Jan 31 15:50:51 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Tue, 31 Jan 2006 10:50:51 -0500 (EST) Subject: [Coq-Club]Finite Types: Sorry a little modif! In-Reply-To: <43DF2CDE.7060408@math.unice.fr> References: <43DF2CDE.7060408@math.unice.fr> Message-ID: On Tue, 31 Jan 2006, Carlos.SIMPSON wrote: > Inductive FinConditional (n : nat) : bool -> Set := > | fin_prev : FinConditional (pred n) (non_zero n) -> Fin n true > | fin_next : FinConditional n true. > > Definition Fin n := FinConditional n true. I don't understand how this would be an improvement over either of my two proposals. Perhaps you could explain. Also, Fin 0 ought to be empty, but this is (presumably) easy to fix. -- Russell O'Connor ``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.'' From wrs06 at !NS! redstar.cs.pdx.edu Wed Feb 1 19:45:32 2006 From: wrs06 at !NS! redstar.cs.pdx.edu (wrs06@redstar.cs.pdx.edu) Date: Wed, 1 Feb 2006 11:45:32 -0800 Subject: [Coq-Club]WRS06 1st call for paper Message-ID: <200602011945.k11JjWTX019501@redstar.cs.pdx.edu> [Our apologies if you receive multiple copies] ----------------------------------------------------------------------- WRS06 The Sixth International Workshop on Reduction Strategies in Rewriting and Programming http://www.cs.pdx.edu/~antoy/wrs06/ The Seattle Sheraton Hotel and Towers, Seattle, Washington, August 11, 2006 Scope The workshop intends to promote and stimulate international research and collaboration in the area of evaluation strategies. It encourages the presentation of new directions,developments and results as well as surveys and tutorials on existing knowledge in this area. Reduction strategies study which subexpression(s) of an expression should be selected for evaluation and which rule(s) should be applied. These choices affect fundamental properties of a computation such as laziness, strictness, completeness and need to name a few. For this reason some programming languages, e.g., Elan, Maude, *OBJ* and Stratego, allow the explicit definition of the evaluation strategy, whereas other languages,e.g., Clean, Curry, and Haskell, allow its modification. Strategies pose challenging theoretical problems and play an important role in practical tools such as theorem provers, model checkers and programming languages. In implementations of languages, strategies bridge the gap between operational principles, e.g., graph and term rewriting,narrowing and lambda-calculus, and semantics, e.g., normalization, computation of values and head-normalization. The previous editions of the workshop were: WRS 2001 (Utrecht, The Netherlands),WRS 2002 (Copenhagen, Denmark), WRS 2003 (Valencia, Spain), WRS 2004 (Aachen, Germany), and WRS 2005 (Nara, Japan). See also the WRS permanent page at http://www.dsic.upv.es/~wrs/ Important Dates Abstract Submission: May 8, 2006 Paper Submission: May 15, 2006 Author Notification: June 12, 2006 Camera-Ready: July 10, 2006 Conference: Aug 11, 2006 Program Committee Sergio Antoy, (chair) Portland State University Santiago Escobar, Universidad Politecnica de Valencia Juergen Giesl, RWTH Aachen Bernhard Gramlich, Technische Universitat Wien Ralf Laemmel, Microsoft Corp. Salvador Lucas, Universidad Politecnica de Valencia Narciso Marti-Oliet, Universidad Complutense de Madrid Mizuhito Ogawa, Japan Advanced Institute of Science and Technology Jaco van de Pol, Centrum voor Wiskunde en Informatica Manfred Schmidt-Schauss, Johann Wolfgang Goethe-Universitat Topics Topics of interest include, but are not restricted to: o theoretical foundations for the definition and semantic description of reduction strategies o strategies in different frameworks such as term rewriting, graph rewriting, infinitary rewriting, lambda calculi, higher order rewriting, conditional rewriting, rewriting with built-ins, narrowing, constraint solving, etc. o application of strategies to equational, functional, functional-logic programming languages o properties of reduction strategies and corresponding computations, e.g., completeness, computability, decidability, complexity, optimality, normalization, cofinality, fairness, perpetuality, context-freedom, need, laziness, eagerness, strictness o interrelations, combinations and applications of reduction under different strategies, e.g., evaluation mechanisms in programming languages, equivalence conditions for fundamental properties like termination and confluence, applications in modularity analysis, connections between strategies of different frameworks,etc. o program analysis and other semantics-based optimization techniques dealing with reduction strategies o rewrite systems, tools, implementations with flexible or programmable strategies as an essential concept or ingredient o specification of reduction strategies in real languages strategies suitable to software engineering problems and applications tutorials and systems related to evaluation strategies Submissions Submissions must be original and not submitted for publication elsewhere. The page limit for regular papers is 13 pages in Springer Verlag LNCS style. Surveys and tutorials maybe longer. Use the WRS06 submission page, handled by the EasyChair conference system, to submit abstracts, papers and to update a previous submission. Publication Informal proceedings of accepted contributions will be available on-line. A hard copy will be distributed at the workshop to registered participants. Authors of selected contributions will be invited to submit a revised version, after the workshop, for inclusion in a collection. We anticipate the publication of formal proceedings in the Elsevier ENTCS series. Contact Sergio Antoy, antoy@cs.pdx.edu. From carlos at !NS! math.unice.fr Mon Feb 6 13:52:12 2006 From: carlos at !NS! math.unice.fr (Carlos.SIMPSON) Date: Mon, 06 Feb 2006 14:52:12 +0100 Subject: [Coq-Club]Finite Types: Sorry a little modif! In-Reply-To: References: <43DF2CDE.7060408@math.unice.fr> Message-ID: <43E7548C.4050705@math.unice.fr> Dear Russell, We looked closely at this and you are right, the induction principle for the ``parametrized type'' is the same as for an unparametrized type in the new case when n changes inside the constructors. (Perhaps somebody could comment on why this change was made; apparently it is only for questions of universes?) In particular this should give no benefit with respect to what you called your first option, and of course you would want your second option so as to be able to specialize to specific values of n. We didn't see any way of modifying the _rec statement to do better, because when n changes in the constructors, you need to specify a dependent type P in the induction statement, over all possible values of n. So finally we completely agree that Russell's contributions should be added to the standard library. ---Carlos, Marco roconnor@theorem.ca wrote: >On Tue, 31 Jan 2006, Carlos.SIMPSON wrote: > > > >>Inductive FinConditional (n : nat) : bool -> Set := >> | fin_prev : FinConditional (pred n) (non_zero n) -> Fin n true >> | fin_next : FinConditional n true. >> >>Definition Fin n := FinConditional n true. >> >> > >I don't understand how this would be an improvement over either of my two >proposals. Perhaps you could explain. > >Also, Fin 0 ought to be empty, but this is (presumably) easy to fix. > > > From roconnor at !NS! theorem.ca Mon Feb 6 14:46:21 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Mon, 6 Feb 2006 09:46:21 -0500 (EST) Subject: [Coq-Club]Finite Types: Sorry a little modif! In-Reply-To: <43E7548C.4050705@math.unice.fr> References: <43DF2CDE.7060408@math.unice.fr> <43E7548C.4050705@math.unice.fr> Message-ID: On Mon, 6 Feb 2006, Carlos.SIMPSON wrote: > Dear Russell, > We looked closely at this and you are right, the induction principle > for the ``parametrized type'' is the same > as for an unparametrized type in the new case when n changes inside the > constructors. > (Perhaps somebody could comment on why this change was made; apparently > it is only for questions of universes?) Indeed it appears to be only a question of maintaining universe consistency. See my thread at , and also Gonthier's response at . To be honest, I would have to put some effort into restuding my problem to understand it again. -- Russell O'Connor ``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.'' From mkoconnor at !NS! gmail.com Wed Feb 8 15:30:49 2006 From: mkoconnor at !NS! gmail.com (Michael O'Connor) Date: Wed, 8 Feb 2006 10:30:49 -0500 Subject: [Coq-Club]heyting arithmetic Message-ID: ------=_Part_2012_6332685.1139412649271 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I'm interested in verifying things which can be proven in Heyting Arithmetic, i.e. intuitionistic Peano Arithmetic, so there is no higher-order induction. Would it be possible to do something like define a type HA_Prop such that if P : HA_Prop and t : P then t is guaranteed to be = a proof just using first-order induction. Thanks very much, Michael O'Connor ------=_Part_2012_6332685.1139412649271 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

I'm interested in verifying things which can be proven in Heytin= g Arithmetic, i.e. intuitionistic Peano Arithmetic, so there is no higher-o= rder induction. Would it be possible to do something like define a ty= pe HA_Prop such that if P : HA_Prop and t : P then t is guaranteed to be a = proof just using first-order induction. Thanks very much,

Michael O'Connor
------=_Part_2012_6332685.1139412649271-- From adamc at !NS! cs.berkeley.edu Wed Feb 8 16:42:18 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Wed, 08 Feb 2006 08:42:18 -0800 Subject: [Coq-Club]heyting arithmetic In-Reply-To: References: Message-ID: <43EA1F6A.90204@cs.berkeley.edu> Michael O'Connor wrote: > I'm interested in verifying things which can be proven in Heyting > Arithmetic, i.e. intuitionistic Peano Arithmetic, so there is no > higher-order induction. Would it be possible to do something like > define a type HA_Prop such that if P : HA_Prop and t : P then t is > guaranteed to be a proof just using first-order induction. Thanks > very much, You can always axiomatize a sufficiently restrictive proof system inside of Coq (probably with inductive types), and instead ask for t : MyProofsOf P, where MyProofsOf is an indexed inductive type of proofs that you define. I'd be surprised if there's a way to restrict the use of higher-order induction without doing something like this suggestion. From Benjamin.werner at !NS! inria.fr Wed Feb 8 21:34:33 2006 From: Benjamin.werner at !NS! inria.fr (Benjamin Werner) Date: Wed, 8 Feb 2006 22:34:33 +0100 Subject: [Coq-Club]heyting arithmetic In-Reply-To: <43EA1F6A.90204@cs.berkeley.edu> References: <43EA1F6A.90204@cs.berkeley.edu> Message-ID: <2DF63A2C-FACA-4EA5-9BE4-5E3F72EF9C16@inria.fr> Yes. Actually if t : P and P : HA_Prop, then HA_Prop should be Prop or Type. So indeed you have to formalize the syntax of the propositions of arithmetic as a data-type, which you can call HA_Prop, and then define a predicate HA : HA_Prop -> Prop (or Type) which states that a proposition is provable in HA. Note that you can "lift" HA into Coq by defining a translation : tr : HA_Prop -> Prop (or Type) and proving : (HA p) -> (tr p) (to be precise you have to deal with hypotheses and free variables also) This was the topic of the individual Coq projets of last year's master's course over here. Good luck, Benjamin Le 8 févr. 06 à 17:42, Adam Chlipala a écrit : > Michael O'Connor wrote: > >> I'm interested in verifying things which can be proven in Heyting >> Arithmetic, i.e. intuitionistic Peano Arithmetic, so there is no >> higher-order induction. Would it be possible to do something like >> define a type HA_Prop such that if P : HA_Prop and t : P then t is >> guaranteed to be a proof just using first-order induction. Thanks >> very much, > > You can always axiomatize a sufficiently restrictive proof system > inside of Coq (probably with inductive types), and instead ask for > t : MyProofsOf P, where MyProofsOf is an indexed inductive type of > proofs that you define. I'd be surprised if there's a way to > restrict the use of higher-order induction without doing something > like this suggestion. > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 Sergey.Berezin at !NS! synopsys.com Mon Feb 6 19:02:41 2006 From: Sergey.Berezin at !NS! synopsys.com (Sergey Berezin) Date: Mon, 6 Feb 2006 11:02:41 -0800 Subject: [Coq-Club]IJCAR 2006: Call For Papers (CFP) Message-ID: <200602061902.k16J2fgn028653@cessna.synopsys.com> (We appologize if you received this message multiple times) CALL FOR PAPERS Third International Joint Conference on Automated Reasoning (IJCAR 2006) August 16--21, 2006 Seattle, USA Submit your paper online: http://ijcar06.uni-koblenz.de/ The Third International Joint Conference on Automated Reasoning (IJCAR) is the fusion of several major conferences in Automated Reasoning: * CADE (Automated Deduction) * TABLEAUX (Automated Reasoning with Analytic Tableaux and Related Methods) * FTP (First-Order Theorem Proving) * FroCoS (Frontiers of Combining Systems) * TPHOLs (Theorem Proving in Higher-Order Logics). IJCAR 2006 will be part of the Federated Logic Conference, FLoC'06 (http://research.microsoft.com/floc06/), to be held in Seattle during August 10--22, 2006. Invited Speakers: Bruno Buchberger Adnan Darwiche David Dill Dale Miller Scope: IJCAR 2006 invites submissions related to all aspects of automated reasoning, including foundations, implementations, and applications. Original research papers and descriptions of working automated deduction systems are solicited. Logics of interest include: Propositional, first-order, classical, equational, higher-order, non-classical, constructive, modal, temporal, many-valued, substructural, description, metalogics, type theory, and set theory. Methods of interest include: Tableaux, sequent calculi, resolution, model-elimination, connection method, inverse method, paramodulation, term rewriting, induction, unification, constraint solving, decision procedures, model generation, model checking, semantic guidance, interactive theorem proving, logical frameworks, AI-related methods for deductive systems, proof presentation, efficient data-structures and indexing, integration of computer algebra systems and automated theorem provers, and combination of logics or decision procedures. Applications of interest include: Hardware and software verification, formal methods, program analysis and synthesis, computer arithmetic, metatheory of languages and logics, declarative programming, deductive databases, knowledge representation, computer security, natural language processing, linguistics, robotics, and planning. Submissions: Submitted research papers and system descriptions must be original and not submitted for publication elsewhere. Research papers can be up to 15 pages long, and system descriptions can be up to 5 pages long. In the research paper category, submissions of theoretical, practical and experimental nature are equally encouraged. Abstracts must be registered by Feb 27, 2006. All submissions must be received by March 6, 2006. Submissions that arrive late or are too long will not be considered. Submission Details: The proceedings of IJCAR 2006 will be published by Springer-Verlag in the LNAI/LNCS series. Authors are strongly encouraged to use LaTeX and the Springer "llncs" format, that can be obtained from http://www.springer.de/comp/lncs/authors.html Best Paper Awards: Awards will be given for the best paper and the best paper written solely by one or more students. The selection will be done by the program committee. A submission is eligible for the best student paper award if all authors are full-time students at the time of submission. The program committee may decline to make the awards or may split it among several papers. Important Dates: February 27, 2006: Paper registration March 6, 2006: Paper submissions April 24, 2006: Acceptance notification May 29, 2006: Camera-ready copy due August 16--21, 2006: IJCAR, Seattle, USA Program Chairs: Ulrich Furbach, University of Koblenz, uli@uni-koblenz.de Natarajan Shankar, SRI International, shankar@csl.sri.com Program Committee: Alessandro Armando Matthias Baaz David Basin Bernhard Beckert Michael Beeson Maria Paola Bonacina Hubert Comon Amy Felty Rajeev Gore Martin Giese Jason Hickey Ian Horrocks Tom Henzinger Dieter Hutter Andrew Ireland Deepak Kapur Helene Kirchner Chris Lynch Michael Kohlhase Michael Maher Bill McCune Tom Melham Jose Meseguer Aart Middeldorp Ilkka Niemela Larry Paulson Christine Paulin-Mohring Carsten Schuermann Stephan Schulz John Slaney Mark Stickel Aaron Stump Geoff Sutcliffe Frank Wolter Hantao Zhang Conference Chair: John Harrison Intel Semiconductors, johnh@ichips.intel.com Workshop Chair: Maria Paola Bonacina Universita` degli Studi di Verona, mariapaola.bonacina@univr.it Publicity Chair: Sergey Berezin Synopsys, Inc., berezin@synopsys.com Steering Committee: Franz Baader Peter Baumgartner Ulrich Furbach John Harrison Reiner Haehnle Tobias Nipkow Natarajan Shankar Cesare Tinelli Toby Walsh From adamc at !NS! cs.berkeley.edu Thu Feb 9 17:13:27 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Thu, 09 Feb 2006 09:13:27 -0800 Subject: [Coq-Club]Proof-generating theorem provers? Message-ID: <43EB7837.3030807@cs.berkeley.edu> Can anyone provide a summary of which interactive proof assistants besides Coq produce a proof of each goal that is successfully discharged, and which definitely don't? By "a proof" I mean a more or less efficiently checkable (meaning no "search" is required) term in some (hopefully simple) logic. I'm also interested in automated deduction tools in general that produce such proofs. It seems that the list of tools in this category isn't as large as I expected, but I might be looking in the wrong places. Thanks! From Yves.Bertot at !NS! sophia.inria.fr Fri Feb 10 09:41:01 2006 From: Yves.Bertot at !NS! sophia.inria.fr (Yves Bertot) Date: Fri, 10 Feb 2006 10:41:01 +0100 Subject: [Coq-Club]On the form of the axiom of description Message-ID: <1139564461.15288.165.camel@oldlace> I am dissatisfied with the form of the axiom of dependent description, as it is given in Logic/ClassicalDescription.v and the associated theorems. Axiom dependent_description : forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), (forall x:A, exists y : B x, R x y /\ (forall y':B x, R x y' -> y = y')) -> exists f : forall x:A, B x, (forall x:A, R x (f x)). This axioms gives me the existence of a function but not the possibility to use this function easily in further definitions. I believe a stronger version would be the following one: Axiom dependent_description' : forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), (forall x:A, exists y : B x, R x y /\ (forall y':B x, R x y' -> y = y')) -> sigT (fun f : forall x:A, B x => (forall x:A, R x (f x))). (the difference between dependent_description and dependent_description' is that I replaced the last exists by sigT. ) I would like to know whether adding this axiom would yield an inconsistent logic. Morally, I would be satisfied with the idea that, in classical logic, the functional notation of Coq is just a short-hand for "set-theory-like" functions but I am aware that we may be navigating close to Cantor's naive set theory I believe the answer can fall in three categories: 1/ No problem, you can already derive dependent_description' from dependent_description using other axioms of classical logic that are thought to be sensible (a coq proof would be great). 2/ Big problem, once you do that, you can encode one of the well-known paradoxes (again a coq proof would be great). 3/ Nobody knows. Does anyone have a quick answer in the direction of 1 or 2? Does anyone know that we don't know? Yves From filliatr at !NS! lri.fr Fri Feb 10 09:56:33 2006 From: filliatr at !NS! lri.fr (Jean-Christophe Filliatre) Date: Fri, 10 Feb 2006 10:56:33 +0100 Subject: [Coq-Club]Proof-generating theorem provers? In-Reply-To: <43EB7837.3030807@cs.berkeley.edu> References: <43EB7837.3030807@cs.berkeley.edu> Message-ID: <17388.25425.942283.37835@gargle.gargle.HOWL> Hello, Adam Chlipala writes: > Can anyone provide a summary of which interactive proof assistants > besides Coq produce a proof of each goal that is successfully > discharged, and which definitely don't? By "a proof" I mean a more or > less efficiently checkable (meaning no "search" is required) term in > some (hopefully simple) logic. Freek Wiedijk compiled a detailed comparison of several proof assistants, including the presence / lack of de Bruijn criterion which is your question. See page 10 of this article http://www.cs.ru.nl/~freek/comparison/diffs.ps.gz and the whole web page at http://www.cs.ru.nl/~freek/comparison/index.html > I'm also interested in automated deduction tools in general that produce > such proofs. It seems that the list of tools in this category isn't as > large as I expected, but I might be looking in the wrong places. I'm aware of at least two decision procedures that output proof terms to be checked independently: - CVC Lite : http://verify.stanford.edu/CVCL/ - Zenon; this prover is part of the Focal distribution : http://focal.inria.fr/ Hope this helps, -- Jean-Christophe Filliâtre (http://www.lri.fr/~filliatr) From Pierre.Letouzey at !NS! pps.jussieu.fr Fri Feb 10 10:22:41 2006 From: Pierre.Letouzey at !NS! pps.jussieu.fr (Pierre Letouzey) Date: Fri, 10 Feb 2006 11:22:41 +0100 Subject: [Coq-Club]On the form of the axiom of description In-Reply-To: <1139564461.15288.165.camel@oldlace> References: <1139564461.15288.165.camel@oldlace> Message-ID: <20060210102241.GA27850@pps.jussieu.fr> On Fri, Feb 10, 2006 at 10:41:01AM +0100, Yves Bertot wrote: > > Axiom > dependent_description' : > forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), > (forall x:A, > exists y : B x, R x y /\ (forall y':B x, R x y' -> y = y')) -> > sigT (fun f : forall x:A, B x => (forall x:A, R x (f x))). > Hi Yves, From my humble opinion, this doesn't look good. From the extraction point of view, this amounts to say "exists f : A->B" out of nothing. Adding additional axioms like Classical, Extensionality, ProofIrrelevance, doesn't change the point, since those axioms live in Prop. And my "doesn't-look-good" opinion can probably be formalized a bit more using realizability. In the meantime, another additional transformation gives you something perfectly provable. But it is probably not what you want... Lemma dependent_description'' : forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), (forall x:A, sigT (fun y : B x => R x y /\ (forall y':B x, R x y' -> y = y')))-> sigT (fun f : forall x:A, B x => (forall x:A, R x (f x))). Proof. intros. exists (fun x => let (y,_) := X x in y). intros. destruct (X x); intuition. Qed. With this one, extraction is just the identity. By the way, in the above proof, you don't even need the "R x y' -> y =y'" part (but you would need it to prove that the answered function is the only one that fits). Hope that helps, Pierre From jean-francois.monin at !NS! imag.fr Sat Feb 11 14:39:34 2006 From: jean-francois.monin at !NS! imag.fr (jean-francois.monin@imag.fr) Date: Sat, 11 Feb 2006 15:39:34 +0100 Subject: [Coq-Club][POSTDOC] 12 Months Postdoctoral Position at Verimag Message-ID: <17389.63270.527753.266156@bucher.imag.fr> 12 Months Postdoctoral Position at Verimag: ------------------------------------------- Verimag is opening a post-doctoral research position on certification of security properties for applications embedded on smart card. The researcher will be integrated in the DCS team of Verimag, in a research project that will start in March 2006. Based on existing results, he will develop a rigorous and general framework for certification of security properties following the requirements of the Common Criteria (an International standard for security evaluation). The aims of the project include: - Certification of the result given by a model-checker by automatic generation of formal proofs which ensure that the checked property holds. - Formalization of the Common Criteria requirements : security policies, refinement relation, correspondance between security properties and implementation mechanisms. - Verification of properties by model-checking and abstraction The former is the most challenging topic of this project. An important point is that all theoretical results are implemented in prototype tools, and experimented in case studies provided by industrial partners of the project. For this purpose, we want to use and further develop recent results on model transformation techniques. Please send your CV and motivation letter to - Michaël Périn (michael.perin@imag.fr) or - Marius Bozga (marius.bozga@imag.fr) From Gerard.Huet at !NS! inria.fr Tue Feb 14 00:54:19 2006 From: Gerard.Huet at !NS! inria.fr (=?ISO-8859-1?Q?G=E9rard_Huet?=) Date: Tue, 14 Feb 2006 01:54:19 +0100 Subject: [Coq-Club]On the form of the axiom of description In-Reply-To: <1139564461.15288.165.camel@oldlace> References: <1139564461.15288.165.camel@oldlace> Message-ID: <68AA906A-DEFC-4FFA-8B63-443BAC6769AD@inria.fr> Le 10 févr. 06 à 10:41, Yves Bertot a écrit : > > Does anyone have a quick answer in the direction of 1 or 2? Does > anyone > know that we don't know? > > Yves > Copernicus said: "To know that we know what we know, and to know that we do not know what we do not know, that is true knowledge." Gérard From Benjamin.werner at !NS! inria.fr Tue Feb 14 04:22:48 2006 From: Benjamin.werner at !NS! inria.fr (Benjamin Werner) Date: Tue, 14 Feb 2006 05:22:48 +0100 Subject: [Coq-Club]On the form of the axiom of description In-Reply-To: <1139564461.15288.165.camel@oldlace> References: <1139564461.15288.165.camel@oldlace> Message-ID: <2C723102-6172-4CBB-8C7E-CD9C1FD33CB2@inria.fr> Let me shift the frontier of what we know to know: Call dd1 and dd2 your two axioms; so dd2->dd1 is obvious. You can show that dd1+ext -> ~~dd2 (where ext is harmless extentionality for functions : Axiom ext : forall A : Type , forall B : A->Type , forall f g : (forall a:A,(B a)) , (forall a:A , (f a)=(g a)) -> f=g. so if you accept ext, if you can reformulate the above ~dd2 -> ~dd1 so you do not further endanger consistency by switching from dd1 to dd2. If you drop the condition for your relation R to be functional, you do not need ext anymore. Whether you really need ext, I do not know :-) So all these axioms are OK with the standart set-theoretic semantics. To answer Pierre : all you lose is the assurance that you will be able to extract a program form any proof. But from the consistency point of view, requiring that exists f : A -> B , ... is already quite strong, since it requires (for most model constructions) that the function f exists in the model. I attach the two proof files. They certainly need some cleaning. Maybye they could even be made really shorter ? You can thank my kid who made my night short ! Best wishes to all, Benjamin Le 10 févr. 06 à 10:41, Yves Bertot a écrit : > I am dissatisfied with the form of the axiom of dependent description, > as it is given in Logic/ClassicalDescription.v and the associated > theorems. > > Axiom > dependent_description : > forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), > (forall x:A, > exists y : B x, R x y /\ (forall y':B x, R x y' -> y = > y')) -> > exists f : forall x:A, B x, (forall x:A, R x (f x)). > > > This axioms gives me the existence of a function but not the > possibility > to use this function easily in further definitions. I believe a > stronger version would be the following one: > > Axiom > dependent_description' : > forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), > (forall x:A, > exists y : B x, R x y /\ (forall y':B x, R x y' -> y = > y')) -> > sigT (fun f : forall x:A, B x => (forall x:A, R x (f x))). > > (the difference between dependent_description and > dependent_description' > is that I replaced the last exists by sigT. ) > > I would like to know whether adding this axiom would yield an > inconsistent logic. Morally, I would be satisfied with the idea that, > in classical logic, the functional notation of Coq is just a short- > hand > for "set-theory-like" functions but I am aware that we may be > navigating > close to Cantor's naive set theory > > I believe the answer can fall in three categories: > > 1/ No problem, you can already derive dependent_description' from > dependent_description using other axioms of classical logic that > are thought to be sensible (a coq proof would be great). > > 2/ Big problem, once you do that, you can encode one of the well-known > paradoxes (again a coq proof would be great). > > 3/ Nobody knows. > > Does anyone have a quick answer in the direction of 1 or 2? Does > anyone > know that we don't know? > > Yves > > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 Benjamin.werner at !NS! inria.fr Tue Feb 14 04:25:09 2006 From: Benjamin.werner at !NS! inria.fr (Benjamin Werner) Date: Tue, 14 Feb 2006 05:25:09 +0100 Subject: [Coq-Club]On the form of the axiom of description In-Reply-To: <1139564461.15288.165.camel@oldlace> References: <1139564461.15288.165.camel@oldlace> Message-ID: <6B24E503-A872-47CF-B514-91B7D5BC167A@inria.fr> --Apple-Mail-3-522636341 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Of course I forgot the files --Apple-Mail-3-522636341 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="bertot.v" Content-Disposition: attachment; filename=bertot.v Axiom dependent_description : forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), (forall x:A, exists y : B x, R x y ) -> exists f : forall x:A, B x, (forall x:A, R x (f x)). Definition dd' := forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), (forall x:A, exists y : B x, R x y ) -> sigT (fun f : forall x:A, B x => (forall x:A, R x (f x))). Axiom abs : dd' -> False. Check sig. Definition dom := (sigT (fun A : Type => (sigT (fun B : (A->Type) => (sigT (fun R : (forall x : A , B x -> Prop) => (forall x , exists y : B x , R x y))))))). Definition p1 : dom -> Type. intros [A _] ; exact A. Defined. Definition p2 : forall d : dom , (p1 d) -> Type. intros [A [B r]]; exact B . Defined. Definition p3 : forall d : dom , (forall x : (p1 d) , (p2 d x) -> Prop). intros [A [B [R p]]]. exact R. Defined. Definition cdom : forall (A : Type)(B:A->Type)(R : forall x:A,(B x)->Prop),(forall x : A , exists y , (R x y))->dom. intros A B R h ; exists A ; exists B ; exists R. trivial. Defined. Goal False. assert (forall d : dom , exists f : (forall a : (p1 d) , (p2 d a)) , (forall a : (p1 d) , (p3 d a (f a)))). intro d ; elim (dependent_description (p1 d)(p2 d)(p3 d)). intros f hf ; exists f; auto. elim d ; simpl. intros A [ B [f h]] ; auto. elim (dependent_description dom (fun d=> (forall x : (p1 d) , (p2 d x))) (fun d f =>(forall a : (p1 d) , (p3 d a (f a))))) ; trivial. intros f hf ; apply abs. intros A B R h. exists (f (cdom A B R h)). exact (hf (cdom A B R h)). Qed. --Apple-Mail-3-522636341 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="bertot2.v" Content-Disposition: attachment; filename=bertot2.v Axiom dependent_description : forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), (forall x:A, exists y : B x, R x y /\ (forall y':B x, R x y' -> y = y')) -> exists f : forall x:A, B x, (forall x:A, R x (f x)). Axiom ext : forall A : Type , forall B : A->Type , forall f g : (forall a:A,(B a)) , (forall a:A , (f a)=(g a)) -> f=g. Definition dd' := forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), (forall x:A, exists y : B x, R x y /\ (forall y':B x, R x y' -> y = y'))-> sigT (fun f : forall x:A, B x => (forall x:A, R x (f x))). Axiom abs : dd' -> False. Check sig. Definition dom := (sigT (fun A : Type => (sigT (fun B : (A->Type) => (sigT (fun R : (forall x : A , B x -> Prop) => (forall x , exists y : B x , R x y/\ (forall y':B x, R x y' -> y = y')) )))))). Definition p1 : dom -> Type. intros [A _] ; exact A. Defined. Definition p2 : forall d : dom , (p1 d) -> Type. intros [A [B r]]; exact B . Defined. Definition p3 : forall d : dom , (forall x : (p1 d) , (p2 d x) -> Prop). intros [A [B [R p]]]. exact R. Defined. Definition cdom : forall (A : Type)(B:A->Type)(R : forall x:A,(B x)->Prop),(forall x : A , exists y , (R x y) /\ (forall y':B x, R x y' -> y = y'))->dom. intros A B R h ; exists A ; exists B ; exists R. trivial. Defined. Goal False. assert (forall d : dom , exists f : (forall a : (p1 d) , (p2 d a)) , (forall a : (p1 d) , (p3 d a (f a)))). intro d ; elim (dependent_description (p1 d)(p2 d)(p3 d)). intros f hf ; exists f; auto. elim d ; simpl. intros A [ B [f h]] ; auto. elim (dependent_description dom (fun d=> (forall x : (p1 d) , (p2 d x))) (fun d f =>(forall a : (p1 d) , (p3 d a (f a))))) ; trivial. intros f hf ; apply abs. intros A B R h. exists (f (cdom A B R h)). exact (hf (cdom A B R h)). intros d ; elim (H d) ; intros f hf ; exists f. split ; auto. generalize d f hf. intros [A [B [R h]]]; simpl. intros g hg hh. intro e. apply ext. intro a ; elim (h a) ; intros y [hy1 hy2] ; apply trans_equal with y ; auto. symmetry ; auto. Qed. --Apple-Mail-3-522636341-- From herbelin at !NS! pauillac.inria.fr Tue Feb 14 09:12:21 2006 From: herbelin at !NS! pauillac.inria.fr (Hugo Herbelin) Date: Tue, 14 Feb 2006 10:12:21 +0100 (MET) Subject: [Coq-Club]On the form of the axiom of description In-Reply-To: <2C723102-6172-4CBB-8C7E-CD9C1FD33CB2@inria.fr> from Benjamin Werner at "Feb 14, 106 05:22:48 am" Message-ID: <200602140912.KAA30896@pauillac.inria.fr> --ELM1139908341-29431-1_ Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Hi Yves, Benjamin essentially said what I planned to say. Indeed, as a side-product of Chicli-Pottier-Simpson's paradox [1], all what you can prove with the version prime (yielding a Sigma-type in Type), you can already prove it with the version in Prop, _as soon as you ultimately prove a proposition_ (*). Hence, you don't have more proofs of a paradox with the version in Type than with the version in Prop. [Incidentally, both are inconsistent in presence of classical logic and impredicative Set.] Extensionality is not needed (I attach a proof which is basically Benjamin's proof with unicity hard-wired in Benjamin's "cdom"). On the practical side: an interest in the description principle is precisely to be able to declare functions without to specify in advance the propositional contexts in which they will be used. Hence, the version in Type actually corresponds more to what we expect. Of course, this breaks extraction, since the axiom computationally specifies an oracle. So, if nobody objects, I suggest we move dependent_description to Type for the next release of Coq. By the way, notice that description in Type + excluded-middle in Prop implies excluded-middle in Type. Thinking set-theoretically (what is generally admitted sound in the absence of Set-impredicativity), this is indeed no problem. Hugo [1] Laurent Chicli, Loïc Pottier, Carlos Simpson, Mathematical Quotients and Quotient Types in Coq, Proceedings of TYPES 2002, Lecture Notes in Computer Science 2646, Springer Verlag. (*) You need some work to show that any use of version prime on some parameter in a term not of type Prop that is a subterm under some local context of a term of type Prop, can be simulated by applying the version in Prop at the upper Prop level, on a parameter generalised over its local context (this is I think the essence of Benjamin's proof). Marginally, you also need to ensure that any inductive definition that relies on the witnesss provided by version prime can be declared in advance, possibly using a generalisation of it. --ELM1139908341-29431-1_ Content-Type: text/plain; charset=ISO-8859-15 Content-Disposition: attachment; filename=descr.v Content-Description: descr.v Content-Transfer-Encoding: 7bit Notation "'exists' ! x : A , P" := (exists x : A, (fun x => P) x /\ forall x':A, (fun x => P) x' -> x = x') (at level 200, x ident, right associativity) : type_scope. Definition dependent_description := forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), (forall x:A, exists ! y : B x, R x y) -> exists f : (forall x:A, B x), forall x:A, R x (f x). Definition dependent_description' := forall (A:Type) (B:A -> Type) (R:forall x:A, B x -> Prop), (forall x:A, exists ! y : B x, R x y) -> sigT (fun f : forall x:A, B x => (forall x:A, R x (f x))). Theorem relative_consistency : (dependent_description' -> False) -> (dependent_description -> False). Proof. intros H DepDescr. pose (A0 := sigT (fun (A:Type) => sigT (fun (B:A->Type) => sigT (fun (R:forall x:A, B x -> Prop) => sigT (fun (p:(forall x:A, exists ! y : B x, R x y)) => A))))). pose (x0 := fun x:A0 => projT2 (projT2 (projT2 (projT2 x)))). pose (B0 := fun x:A0 => projT1 (projT2 x) (x0 x)). pose (R0 := fun x:A0 => fun y:B0 x => projT1 (projT2 (projT2 x)) (x0 x) y). pose (H0 := fun x:A0 => projT1 (projT2 (projT2 (projT2 x))) (x0 x)). destruct (DepDescr A0 B0 R0 H0) as (f, Hf). apply H. intros A B R H'. pose (f' := fun x:A => f (existT (fun _ => sigT _) A (existT (fun _ => sigT _) B (existT (fun _ => sigT _) R (existT (fun _ => A) H' x))))). pose (Hf' := fun x:A => Hf (existT (fun _ => sigT _) A (existT (fun _ => sigT _) B (existT (fun _ => sigT _) R (existT (fun _ => A) H' x))))). exists f'. exact Hf'. Qed. --ELM1139908341-29431-1_-- From femke at !NS! cs.vu.nl Wed Feb 15 08:40:18 2006 From: femke at !NS! cs.vu.nl (Femke van Raamsdonk) Date: Wed, 15 Feb 2006 09:40:18 +0100 (CET) Subject: [Coq-Club]HOR 2006: call for abstracts Message-ID: ******************************** * * * HOR'06 CALL FOR ABSTRACTS * * * ******************************** 3rd International Workshop on Higher-Order Rewriting Tuesday August 15, 2006 Sheraton, Seattle, WA http://hor.pps.jussieu.fr/06 IMPORTANT DATES: May 8, 2006 : deadline electronic submission of paper May 29, 2006 : notification of acceptance of papers June 8, 2006 : deadline for final version of accepted papers The aim of HOR is to provide an informal and friendly setting to discuss recent work and work in progress concerning higher-order rewriting. HOR 2002 was part of FLoC 2002 in Copenhagen, Denmark. HOR 2004 was part of RDP 2004 in Aachen, Germany. HOR 2006 will be part of FLoC 2006 in Seattle, USA. INVITED TALKS: Hugo Herbelin (INRIA Futurs, Paris) Eelco Visser (Universiteit Utrecht, The Netherlands) TOPICS of interest include (but are not limited to): APPLICATIONS: proof checking, theorem proving, generic programming, declarative programming, program transformation. FOUNDATIONS: pattern matching, unification, strategies, narrowing, termination, syntactic properties, type theory. FRAMEWORKS: term rewriting, conditional rewriting, graph rewriting, net rewriting, comparisons of different frameworks. IMPLEMENTATION: explicit substitution, rewriting tools, compilation techniques. SEMANTICS: semantics of higher-order rewriting, higher-order abstract syntax PROGRAM/ORGANIZING COMMITTEE: Delia Kesner Universite Paris 7, France kesner@pps.jussieu.fr Femke van Raamsdonk Vrije Universiteit, The Netherlands femke@cs.vu.nl Mark-Oliver Stehr SRI International, USA stehr@csl.sri.com HOR'06 SUBMISSIONS: Abstracts between 2 and 5 pages. As HOR is meant to be a platform to discuss ongoing research we are also interested in abstracts describing work in progress, or problems in higher-order rewriting. PROCEEDINGS: The proceedings of HOR 2006 will be made available on the HOR 2006 web page and copies will be distributed to the participants at the workshop. LOCAL ARRANGEMENTS: Gopal Gupta University of Texas, Dallas, USA gupta@utdallas.edu Ashish Tiwari SRI International, USA tiwari@csl.sri.com From iampure at !NS! gmail.com Sun Feb 19 15:57:21 2006 From: iampure at !NS! gmail.com (Ron) Date: Sun, 19 Feb 2006 16:57:21 +0100 Subject: [Coq-Club]Coq and proving asm security properties Message-ID: <87d4647e0602190757s68c5e464y@mail.gmail.com> Hi, I am new to this list and interested in using a theorem prover to semi-automatically prove that a certain executable containing binary code(thus a dissassembly needs to be generated first) on e.g. Linux contains no possibility for e.g. a buffer-overflow. Coq seems to be a well developed theorem prover, however, I read in Chapter 1 of Coq'Art that Coq can't prove theorems about all computable functions(in particular those that not terminate). So, it seems I can't use Coq for my purposes, since I need to prove things over programs that are possibly interactive, and hence don't need to terminate. Could anyone provide some pointers, in case, it is possible to still use Coq? More in general, it seems everyone ignores I/O (I have only seen the proof of the correctness of simple functions like max, sum, average, etc in some high-level language in the papers I skimmed). Is there some "trick" which makes I/O a non-issue? (I have seen dependent types approaches, but those seem to be still at the theoretical level). More on the limitations of Coq. I have been taught that predicate calculus can represent programs, so this would imply Coq can't do this. OTOH, I read somewhere else that someone embedded predicate logic in Coq. So, some of the above assertions must be wrong. Which one? In case Coq is not up to the task, what theorem provers are? Regards, R. P.S. I would greatly appreciate pointers to papers tackling the problem of proving general properties given plain binaries which do I/O. From lionel at !NS! mamane.lu Sun Feb 19 16:28:59 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Sun, 19 Feb 2006 17:28:59 +0100 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <87d4647e0602190757s68c5e464y@mail.gmail.com> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> Message-ID: <20060219162859.GA5776@capsaicin.mamane.lu> On Sun, Feb 19, 2006 at 04:57:21PM +0100, Ron wrote: > Coq seems to be a well developed theorem prover, however, I read in > Chapter 1 of Coq'Art that Coq can't prove theorems about all > computable functions(in particular those that not terminate). So, it > seems I can't use Coq for my purposes, since I need to prove things > over programs that are possibly interactive, and hence don't need to > terminate. The "no programs that don't terminate" bit doesn't per se exclude interactive programs. Indeed, one usually want these program to respond sooner or later to every user input. So, one can see the whole program execution as a series of execution of smaller programs that each answer to _one_ input, give answer (and terminate). Besides, if your program doesn't terminate only when given infinite input (when the user keeps giving commands that are not "quit"), then it doesn't count as "not terminating" for this matter. What counts is "not terminating given a finite input". > More on the limitations of Coq. I have been taught that predicate > calculus can represent programs, so this would imply Coq can't do > this. Err... I'm not sure what you mean exactly. What is the relationship between the two claims you are making in that sentence alone? -- Lionel From adamc at !NS! cs.berkeley.edu Sun Feb 19 17:00:05 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Sun, 19 Feb 2006 09:00:05 -0800 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <87d4647e0602190757s68c5e464y@mail.gmail.com> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> Message-ID: <43F8A415.30803@cs.berkeley.edu> Ron wrote: >I am new to this list and interested in using a theorem prover to >semi-automatically prove that a certain executable containing binary >code(thus a dissassembly needs to be generated first) on e.g. Linux >contains no possibility for e.g. a buffer-overflow. > Are you familiar with the large existing body of work on Foundational Proof-Carrying Code? In this area, we prove theorems about machine code programs using no axioms but those of the machine architecture we run on. The most well-studied and -implemented theorems here are memory safety theorems, which I think subsume buffer-overflow checking, given the right definitions. I'm aware of these FPCC projects that already use Coq: - Those in the FLINT group at Yale: http://flint.cs.yale.edu/flint/publications/ - My co-authors' and my work on building scalable FPCC systems using proof-generating or proved-sound program verifiers: see the 1st and 3rd entries on http://www.cs.berkeley.edu/~adamc/papers/ There is also work in the area using Twelf in place of Coq: - The original FPCC project at Princeton: http://www.cs.princeton.edu/sip/projects/pcc/ - The ConCert project at CMU: see the 1st entry in each of the 1st two categories of http://www.cs.cmu.edu/~crary/papers/ >Coq seems to be a >well developed theorem prover, however, I read in Chapter 1 of Coq'Art >that Coq can't prove theorems about all computable functions(in >particular those that not terminate). So, it seems I can't use Coq for >my purposes, since I need to prove things over programs that are >possibly interactive, and hence don't need to terminate. Could anyone >provide some pointers, in case, it is possible to still use Coq? > > I think you have confused the "meta language," or language of Coq itself (which is a programming language in its own right); with potential "object languages," or programming languages that you prove theorems about. There is no limitation against formalizing an object language that supports non-termination, and in fact all of the FPCC work I mentioned is in such a setting. > More in general, it seems everyone ignores I/O (I have only seen the >proof of the correctness of simple functions like max, sum, average, >etc in some high-level language in the papers I skimmed). Is there >some "trick" which makes I/O a non-issue? (I have seen dependent types >approaches, but those seem to be still at the theoretical level). > > If you are only interested in buffer overflows, then you shouldn't need to model these exactly. In any case, the first link I gave above probably has the most relevant work on proving general correctness properties of machine code. From iampure at !NS! gmail.com Sun Feb 19 21:39:48 2006 From: iampure at !NS! gmail.com (Ron) Date: Sun, 19 Feb 2006 22:39:48 +0100 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <20060219162859.GA5776@capsaicin.mamane.lu> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> <20060219162859.GA5776@capsaicin.mamane.lu> Message-ID: <87d4647e0602191339rfae0272j@mail.gmail.com> 2006/2/19, Lionel Elie Mamane : > On Sun, Feb 19, 2006 at 04:57:21PM +0100, Ron wrote: > > > Coq seems to be a well developed theorem prover, however, I read in > > Chapter 1 of Coq'Art that Coq can't prove theorems about all > > computable functions(in particular those that not terminate). So, it > > seems I can't use Coq for my purposes, since I need to prove things > > over programs that are possibly interactive, and hence don't need to > > terminate. > > The "no programs that don't terminate" bit doesn't per se exclude > interactive programs. Indeed, one usually want these program to > respond sooner or later to every user input. So, one can see the whole > program execution as a series of execution of smaller programs that > each answer to _one_ input, give answer (and terminate). > > Besides, if your program doesn't terminate only when given infinite > input (when the user keeps giving commands that are not "quit"), then > it doesn't count as "not terminating" for this matter. What counts is > "not terminating given a finite input". > > > More on the limitations of Coq. I have been taught that predicate > > calculus can represent programs, so this would imply Coq can't do > > this. > > Err... I'm not sure what you mean exactly. What is the relationship > between the two claims you are making in that sentence alone? In predicate logic you can state that a certain program, which will never terminate, will never produce output FOO, and there exists theorem provers which can handle predicate logic that can semi-decide this. And Coq couldn't handle all computable functions (as in Chapter 1). So, if you can use Coq to do all of predicate logic, then there must be something wrong in one of the above statements. They can not be all correct at the same time modulo me ot understanding something. And I want to prove things about the object language. "Are you familiar with the large existing body of work on Foundational Proof-Carrying Code? In this area, we prove theorems about machine code programs using no axioms but those of the machine architecture we run on. The most well-studied and -implemented theorems here are memory safety theorems, which I think subsume buffer-overflow checking, given the right definitions." I have heard the term, yes. I have the book 'Advanced Topics in Types and Programming Languages', which I think is related. Now, it would be very interesting if someone would have formalized all x86 instructions or similar. Did anyone do this? Or if not, what is the most complex program of which non-trivial statements have been proved? And what software is used most is this context? Coq? With what libraries? Thanks for all your answers, Ron From adamc at !NS! cs.berkeley.edu Sun Feb 19 22:34:24 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Sun, 19 Feb 2006 14:34:24 -0800 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <87d4647e0602191339rfae0272j@mail.gmail.com> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> <20060219162859.GA5776@capsaicin.mamane.lu> <87d4647e0602191339rfae0272j@mail.gmail.com> Message-ID: <43F8F270.1040805@cs.berkeley.edu> Ron wrote: >Now, it would be very interesting if someone would have formalized all >x86 instructions or similar. Did anyone do this? > I've formalized in Coq the parts of x86 that I've needed so far for the tasks I've attempted. There is the beginning of a re-usable library for parsing machine code (with OCaml) and proving things about the resulting ASTs (with Coq) here: http://cvs.sourceforge.net/viewcvs.py/proofos/asm/ I know that some other people have also created formalizations, but none are really packaged for wide use. I asked your exact question on this list before beginning the above library and received no positive answers. >Or if not, what is >the most complex program of which non-trivial statements have been >proved? > If you count memory safety as non-trivial (and the proofs are quite non-trivial!), then we can prove facts about arbitrarily complicated programs; anything outputted by a certifying ML compiler, for instance, in a format like typed assembly language. If that's not non-trivial enough for you, then probably the Certified Assembly Programming work at Yale has dealt with the most interesting properties that I've seen. >And what software is used most is this context? Coq? With what >libraries? > > Anecdotally, I've heard of the most projects in this area that use Coq. From iampure at !NS! gmail.com Sun Feb 19 22:58:13 2006 From: iampure at !NS! gmail.com (Ron) Date: Sun, 19 Feb 2006 23:58:13 +0100 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <43F8F270.1040805@cs.berkeley.edu> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> <20060219162859.GA5776@capsaicin.mamane.lu> <87d4647e0602191339rfae0272j@mail.gmail.com> <43F8F270.1040805@cs.berkeley.edu> Message-ID: <87d4647e0602191458v66cacb09w@mail.gmail.com> 2006/2/19, Adam Chlipala : > Ron wrote: > > >Now, it would be very interesting if someone would have formalized all > >x86 instructions or similar. Did anyone do this? > > > I've formalized in Coq the parts of x86 that I've needed so far for the > tasks I've attempted. There is the beginning of a re-usable library for > parsing machine code (with OCaml) and proving things about the resulting > ASTs (with Coq) here: > http://cvs.sourceforge.net/viewcvs.py/proofos/asm/ > Ok, that's very interesting. Do I understand correctly that you try to load a binary and then load that up in Coq somehow, with the theorem you want to prove about that program. And then a user could start proving something about this? I.e. this is different from all the "oh, we have this dependently typed language with programmers supplying all the proofs"-approach :) > I know that some other people have also created formalizations, but none > are really packaged for wide use. I asked your exact question on this > list before beginning the above library and received no positive answers. Great initiative :) > > >Or if not, what is > >the most complex program of which non-trivial statements have been > >proved? > > > If you count memory safety as non-trivial (and the proofs are quite > non-trivial!), then we can prove facts about arbitrarily complicated > programs; anything outputted by a certifying ML compiler, for instance, > in a format like typed assembly language. If that's not non-trivial > enough for you, then probably the Certified Assembly Programming work at > Yale has dealt with the most interesting properties that I've seen. > If you don't have this cool typed assembly language, but only a binary with x86, then that doesn't work, but if I understand correctly your "library" does not assume a typed assembly, right? > >And what software is used most is this context? Coq? With what > >libraries? > > > > > Anecdotally, I've heard of the most projects in this area that use Coq. Ok, then I am on the right track. P.S. Did you or anybody else use the book Coq'Art to become experienced with Coq? Can you recommend it? Amazon does not have reviews. From adamc at !NS! cs.berkeley.edu Sun Feb 19 23:10:50 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Sun, 19 Feb 2006 15:10:50 -0800 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <87d4647e0602191458v66cacb09w@mail.gmail.com> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> <20060219162859.GA5776@capsaicin.mamane.lu> <87d4647e0602191339rfae0272j@mail.gmail.com> <43F8F270.1040805@cs.berkeley.edu> <87d4647e0602191458v66cacb09w@mail.gmail.com> Message-ID: <43F8FAFA.8040107@cs.berkeley.edu> Ron wrote: >Ok, that's very interesting. Do I understand correctly that you try to >load a binary and then load that up in Coq somehow, with the theorem >you want to prove about that program. And then a user could start >proving something about this? I.e. this is different from all the "oh, >we have this dependently typed language with programmers supplying all >the proofs"-approach :) > > That's right. Coq is really just such a dependently typed language, with the extra facilities for interactive programming/proving. >If you don't have this cool typed assembly language, but only a binary >with x86, then that doesn't work, but if I understand correctly your >"library" does not assume a typed assembly, right? > > The types in typed assembly language are just proof hints. TAL-based approaches are quite compatible with producing standard x86 binaries. There is no idea of assembly-level types in the library I linked. >P.S. Did you or anybody else use the book Coq'Art to become >experienced with Coq? Can you recommend it? Amazon does not have >reviews. > I found it to be a very worthwhile book to read. From robdockins at !NS! fastmail.fm Mon Feb 20 02:24:54 2006 From: robdockins at !NS! fastmail.fm (Robert Dockins) Date: Sun, 19 Feb 2006 21:24:54 -0500 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <87d4647e0602191458v66cacb09w@mail.gmail.com> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> <20060219162859.GA5776@capsaicin.mamane.lu> <87d4647e0602191339rfae0272j@mail.gmail.com> <43F8F270.1040805@cs.berkeley.edu> <87d4647e0602191458v66cacb09w@mail.gmail.com> Message-ID: On Feb 19, 2006, at 5:58 PM, Ron wrote: > 2006/2/19, Adam Chlipala : >> Ron wrote: >> >>> Now, it would be very interesting if someone would have >>> formalized all >>> x86 instructions or similar. Did anyone do this? >>> >> I've formalized in Coq the parts of x86 that I've needed so far >> for the >> tasks I've attempted. There is the beginning of a re-usable >> library for >> parsing machine code (with OCaml) and proving things about the >> resulting >> ASTs (with Coq) here: >> http://cvs.sourceforge.net/viewcvs.py/proofos/asm/ >> > Ok, that's very interesting. Do I understand correctly that you try to > load a binary and then load that up in Coq somehow, with the theorem > you want to prove about that program. And then a user could start > proving something about this? I.e. this is different from all the "oh, > we have this dependently typed language with programmers supplying all > the proofs"-approach :) > >> I know that some other people have also created formalizations, >> but none >> are really packaged for wide use. I asked your exact question on >> this >> list before beginning the above library and received no positive >> answers. > Great initiative :) >> >>> Or if not, what is >>> the most complex program of which non-trivial statements have been >>> proved? >>> >> If you count memory safety as non-trivial (and the proofs are quite >> non-trivial!), then we can prove facts about arbitrarily complicated >> programs; anything outputted by a certifying ML compiler, for >> instance, >> in a format like typed assembly language. If that's not non-trivial >> enough for you, then probably the Certified Assembly Programming >> work at >> Yale has dealt with the most interesting properties that I've seen. >> > If you don't have this cool typed assembly language, but only a binary > with x86, then that doesn't work, but if I understand correctly your > "library" does not assume a typed assembly, right? > >>> And what software is used most is this context? Coq? With what >>> libraries? >>> >>> >> Anecdotally, I've heard of the most projects in this area that use >> Coq. > Ok, then I am on the right track. > > P.S. Did you or anybody else use the book Coq'Art to become > experienced with Coq? Can you recommend it? Amazon does not have > reviews. I have a copy of Coq'Art, and my opinion is that it is quite good. I refer to it with some frequency. I went into reading it after having worked with Coq for a couple of weeks; I think it was easier reading for that. I think otherwise I would have done more re-reading and scratching my head. That said, there are some of the more esoteric areas that Coq'Art doesn't cover. For example, there is an important restriction on inductive definitions called some thing like the "positivity requirement" which I could not find in Coq'Art; I had to dig around in the documentation and finally read a journal paper before I found a satisfactory explanation of what this restriction is and why it exists. Short version: it's good. Get it if you plan to do any serious work with Coq. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG From lionel at !NS! mamane.lu Mon Feb 20 05:23:37 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Mon, 20 Feb 2006 06:23:37 +0100 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <87d4647e0602191339rfae0272j@mail.gmail.com> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> <20060219162859.GA5776@capsaicin.mamane.lu> <87d4647e0602191339rfae0272j@mail.gmail.com> Message-ID: <20060220052337.GA7565@capsaicin.mamane.lu> On Sun, Feb 19, 2006 at 10:39:48PM +0100, Ron wrote: > 2006/2/19, Lionel Elie Mamane : >> On Sun, Feb 19, 2006 at 04:57:21PM +0100, Ron wrote: >>> Coq seems to be a well developed theorem prover, however, I read in >>> Chapter 1 of Coq'Art that Coq can't prove theorems about all >>> computable functions(in particular those that not terminate). >>> More on the limitations of Coq. I have been taught that predicate >>> calculus can represent programs, so this would imply Coq can't do >>> this. >> Err... I'm not sure what you mean exactly. What is the relationship >> between the two claims you are making in that sentence alone? > In predicate logic you can state that a certain program, which will > never terminate, will never produce output FOO, and there exists > theorem provers which can handle predicate logic that can > semi-decide this. And Coq couldn't handle all computable functions > (as in Chapter 1). So, if you can use Coq to do all of predicate > logic, then there must be something wrong in one of the above > statements. OK, I see. What you cannot do in Coq is, given two types A and B, construct an object of type "A -> B" (a function that takes an A and returns a B) that doesn't terminate on all a's. Even more strongly, Coq must _see_ that it terminates; the exact condition is documented in the manual. These are the Coq-native functions that Coq will automatically compute for you; meaning if f is defined in this way and for a particular a and b the computation of (f a) gives b, then these two terms are equal at the lowest level in Coq (they are _convertible_). They are indistinguishable in the Coq logic. This is called the Poincaré principle. This being said, there are ways to speak about partial functions, for example the Bove-Capretta method: Basically, you add an additional argument to your function which is the proof that it terminates on this particular input (a trace of the computation, actually). Your constructed function then artificially always terminates, because if the original function doesn't terminate on input a, then you won't be able to construct the second argument. That's in Coq's native logic. But if you encode predicate logic (as an object logic) in Coq, then obviously you get exactly the power of that predicate logic. You'd loose the Poincaré principle, I think. This maps to the two ways to use Coq: - Construct / prove something in Coq's logic itself. - Construct another logic as an object logic in Coq and do things in this logic. -- Lionel From pierre.casteran at !NS! labri.fr Mon Feb 20 06:37:14 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Mon, 20 Feb 2006 07:37:14 +0100 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: References: <87d4647e0602190757s68c5e464y@mail.gmail.com> <20060219162859.GA5776@capsaicin.mamane.lu> <87d4647e0602191339rfae0272j@mail.gmail.com> <43F8F270.1040805@cs.berkeley.edu> <87d4647e0602191458v66cacb09w@mail.gmail.com> Message-ID: <43F9639A.6020003@labri.fr> Robert Dockins wrote: > > That said, there are some of the more esoteric areas that Coq'Art > doesn't cover. For example, there is an important restriction on > inductive definitions called some thing like the "positivity > requirement" which I could not find in Coq'Art; I had to dig around > in the documentation and finally read a journal paper before I found > a satisfactory explanation of what this restriction is and why it > exists. Well, There is some stuff about that pp 389-390, and more examples in the Tutorial on [co-]inductive types (reachable from Coq's documentation page : look at "Additional Documentation"). Speaking about I/O, there is probably some interesting work [to be ?] done using co-inductive types for representing I/O streams, but I don't have any precise links. Pierre > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 ctm at !NS! cs.nott.ac.uk Mon Feb 20 08:37:52 2006 From: ctm at !NS! cs.nott.ac.uk (Conor McBride) Date: Mon, 20 Feb 2006 08:37:52 +0000 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <43F9639A.6020003@labri.fr> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> <20060219162859.GA5776@capsaicin.mamane.lu> <87d4647e0602191339rfae0272j@mail.gmail.com> <43F8F270.1040805@cs.berkeley.edu> <87d4647e0602191458v66cacb09w@mail.gmail.com> <43F9639A.6020003@labri.fr> Message-ID: <43F97FE0.4030304@cs.nott.ac.uk> Hi folks Pierre Casteran wrote: > Well, There is some stuff about that pp 389-390, and more examples in > the Tutorial on [co-]inductive > types (reachable from Coq's documentation page : look at "Additional > Documentation"). > > Speaking about I/O, there is probably some interesting work [to be ?] > done using co-inductive types for > representing I/O streams, but I don't have any precise links. A few people have given some thought to I/O in type theory, most notably Peter Hancock, Anton Setzer and Pierre Hyvernat. For useful reading, try http://homepages.inf.ed.ac.uk/v1phanc1/chat.html All the best Conor 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. From robdockins at !NS! fastmail.fm Mon Feb 20 18:03:21 2006 From: robdockins at !NS! fastmail.fm (Robert Dockins) Date: Mon, 20 Feb 2006 13:03:21 -0500 Subject: [Coq-Club]Coq and proving asm security properties In-Reply-To: <43F9639A.6020003@labri.fr> References: <87d4647e0602190757s68c5e464y@mail.gmail.com> <20060219162859.GA5776@capsaicin.mamane.lu> <87d4647e0602191339rfae0272j@mail.gmail.com> <43F8F270.1040805@cs.berkeley.edu> <87d4647e0602191458v66cacb09w@mail.gmail.com> <43F9639A.6020003@labri.fr> Message-ID: <7FF21834-4298-4554-998C-B8A7E6C23735@fastmail.fm> On Feb 20, 2006, at 1:37 AM, Pierre Casteran wrote: > Robert Dockins wrote: > >> >> That said, there are some of the more esoteric areas that Coq'Art >> doesn't cover. For example, there is an important restriction on >> inductive definitions called some thing like the "positivity >> requirement" which I could not find in Coq'Art; I had to dig >> around in the documentation and finally read a journal paper >> before I found a satisfactory explanation of what this restriction >> is and why it exists. > > > Well, There is some stuff about that pp 389-390, and more examples > in the Tutorial on [co-]inductive > types (reachable from Coq's documentation page : look at > "Additional Documentation"). Perhaps you have a different edition than me. Pages 389-390 in my edition are in section 14.1.4, a subsection titled "Dependently Typed Recursors". However, a little page flipping brings me to section 14.1.2.2, which is see does discuss positivity, albeit fairly briefly. So, I retract that particular critique. On a side note, is there any good tutorial/didactic material dealing with Coq's implicit coercion system? I find the documentation very difficult to read and Coq'Art doesn't cover it. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG From Sergey.Berezin at !NS! synopsys.com Tue Feb 21 17:27:40 2006 From: Sergey.Berezin at !NS! synopsys.com (Sergey Berezin) Date: Tue, 21 Feb 2006 09:27:40 -0800 Subject: [Coq-Club]IJCAR 2006: Call For Papers (CFP) Message-ID: <200602211727.k1LHRebC020466@cessna.synopsys.com> (We appologize if you received this message multiple times) Abstracts are due by February 27 - next Monday! CALL FOR PAPERS Third International Joint Conference on Automated Reasoning (IJCAR 2006) August 16--21, 2006 Seattle, USA Submit your paper online http://ijcar06.uni-koblenz.de/ The Third International Joint Conference on Automated Reasoning (IJCAR) is the fusion of several major conferences in Automated Reasoning: * CADE (Automated Deduction) * TABLEAUX (Automated Reasoning with Analytic Tableaux and Related Methods) * FTP (First-Order Theorem Proving) * FroCoS (Frontiers of Combining Systems) * TPHOLs (Theorem Proving in Higher-Order Logics). IJCAR 2006 will be part of the Federated Logic Conference, FLoC'06 (http://research.microsoft.com/floc06/), to be held in Seattle during August 10--22, 2006. Invited Speakers: Bruno Buchberger Adnan Darwiche David Dill Dale Miller Scope: IJCAR 2006 invites submissions related to all aspects of automated reasoning, including foundations, implementations, and applications. Original research papers and descriptions of working automated deduction systems are solicited. Logics of interest include: Propositional, first-order, classical, equational, higher-order, non-classical, constructive, modal, temporal, many-valued, substructural, description, metalogics, type theory, and set theory. Methods of interest include: Tableaux, sequent calculi, resolution, model-elimination, connection method, inverse method, paramodulation, term rewriting, induction, unification, constraint solving, decision procedures, model generation, model checking, semantic guidance, interactive theorem proving, logical frameworks, AI-related methods for deductive systems, proof presentation, efficient data-structures and indexing, integration of computer algebra systems and automated theorem provers, and combination of logics or decision procedures. Applications of interest include: Hardware and software verification, formal methods, program analysis and synthesis, computer arithmetic, metatheory of languages and logics, declarative programming, deductive databases, knowledge representation, computer security, natural language processing, linguistics, robotics, and planning. Submissions: Submitted research papers and system descriptions must be original and not submitted for publication elsewhere. Research papers can be up to 15 pages long, and system descriptions can be up to 5 pages long. In the research paper category, submissions of theoretical, practical and experimental nature are equally encouraged. Abstracts must be registered by Feb 27, 2006. All submissions must be received by March 6, 2006. Submissions that arrive late or are too long will not be considered. Submission Details: The proceedings of IJCAR 2006 will be published by Springer-Verlag in the LNAI/LNCS series. Authors are strongly encouraged to use LaTeX and the Springer "llncs" format, that can be obtained from http://www.springer.de/comp/lncs/authors.html Best Paper Awards: Awards will be given for the best paper and the best paper written solely by one or more students. The selection will be done by the program committee. A submission is eligible for the best student paper award if all authors are full-time students at the time of submission. The program committee may decline to make the awards or may split it among several papers. Important Dates: February 27, 2006: Paper registration March 6, 2006: Paper submissions April 24, 2006: Acceptance notification May 29, 2006: Camera-ready copy due August 16--21, 2006: IJCAR, Seattle, USA Program Chairs: Ulrich Furbach, University of Koblenz, uli@uni-koblenz.de Natarajan Shankar, SRI International, shankar@csl.sri.com Program Committee: Alessandro Armando Matthias Baaz David Basin Bernhard Beckert Michael Beeson Maria Paola Bonacina Hubert Comon Amy Felty Rajeev Gore Martin Giese Jason Hickey Ian Horrocks Tom Henzinger Dieter Hutter Andrew Ireland Deepak Kapur Helene Kirchner Chris Lynch Michael Kohlhase Michael Maher Bill McCune Tom Melham Jose Meseguer Aart Middeldorp Ilkka Niemela Larry Paulson Christine Paulin-Mohring Carsten Schuermann Stephan Schulz John Slaney Mark Stickel Aaron Stump Geoff Sutcliffe Frank Wolter Hantao Zhang Conference Chair: John Harrison Intel Semiconductors, johnh@ichips.intel.com Workshop Chair: Maria Paola Bonacina Universita` degli Studi di Verona, mariapaola.bonacina@univr.it Publicity Chair: Sergey Berezin Synopsys, Inc., berezin@synopsys.com Steering Committee: Franz Baader Peter Baumgartner Ulrich Furbach John Harrison Reiner Haehnle Tobias Nipkow Natarajan Shankar Cesare Tinelli Toby Walsh From Silvio.Ranise at !NS! loria.fr Wed Feb 22 08:18:21 2006 From: Silvio.Ranise at !NS! loria.fr (Silvio.Ranise@loria.fr) Date: Wed, 22 Feb 2006 09:18:21 +0100 Subject: [Coq-Club]Calculemus'06 CFP: 13 th Symposium on the Integration of Symbolic Computation and Mechanized Reasoning 2006 (co-located with ISSAC'06) Message-ID: <1140596301.43fc1e4da11e9@www.loria.fr> =========================================================================== Calculemus'06 Symposium http://calculemus2006.loria.fr 13th Symposium on the Integration of Symbolic Computation and Mechanized Reasoning 2006 Co-located with ISSAC 2006 July 7-8, 2006 Università degli Studi di Genova Genova, Italy CALL FOR PAPERS =========================================================================== Background ----------- The scientific and technological goal of the Calculemus network is to design a new generation of mathematical software systems and computer-aided verification tools based on the integration of Deduction and Computer Algebra Systems. Both Deduction Systems (DSs) and Computer Algebra Systems (CASs) are receiving growing attention from industry and academia. On the one hand, CASs have been commercially very successful in recent years. On the other hand, the use of formal methods in hardware and software development has made DSs indispensable not least because of the complexity and sheer size of the reasoning tasks involved. Such systems are now making the transition from academic applications into regular industrial practice. In spite of these successes there is still need for improvement as many application domains still fall outside the scope of existing DSs and CASs. For instance, the scope of CASs could be significantly enhanced by adding deductive reasoning power. In fact this lack of expressivity together with the unsolved problem of correctness prohibit large classes of applications. DSs, which - on the other hand - provide such an expressivity, as well as the guarantee of correctness, still lack computational power as they are not suited to directly carry out algebraic or numerical calculations. This severely restricts their scope of application in mathematics and - more importantly - in engineering applications. The main goal of the Calculemus symposiums serie is to stimulate significant research advancements in combining the reasoning capabilities of DSs and the computational power of CASs as well as to foster possible cross-fertilizations. The field of DSs has diversified into the areas of automated theorem proving and interactive proof-development, which have their own traditions, conferences and technical methods. The field of CAs has specialised on devising highly efficient methods for symbolic calculations. The mission of the Calculemus symposiums serie is to bringing together such research communities so to create new generation of expressive, automatic, and easy-to-use systems capable of performing a wide range of mathematical tasks. Goals & Topics --------------- Calculemus 2006, the 13th symposium in the series, will be held July 7-8, 2006 at the Università degli Studi di Genova, Italy, in conjunction with the International Symposium on Symbolic and Algebraic Computation (ISSAC) 2006. The main theme of Calculemus 2006 will be the interactions between automated deduction and computer algebra with particular emphasis on the applications to verification, mathematical assistants, and web services. Calculemus 2006 welcomes research papers on all aspects of integrating symbolic computation and formal deduction including: * Combining computer algebra and computer deduction systems * Adding deductive capabilities to computer algebra systems * Adding computational capabilities to computer deduction systems * Combining methods of symbolic computation and formal deduction * Design and implementation issues in integrated systems * Design and implementation of computer algebra and deduction services for the web * Formal method problems requiring mixed computing and proving * Applications of formal methods to the construction of integrated systems * Design and implementation of mathematical assistants requiring both computer algebra and deduction * Case studies and applications Audience --------- The intended audience of the symposium is mainly researchers and practicioners in the fields of computer algebra and automated deduction. More in general, anyone interested in the design of mathematical software systems and computer-aided verification tools based on the integration of the deduction and computation. Call for papers ---------------- Papers addressing the topics listed above and more in general involving techniques in both computer algebra and automated deduction are solicited. Submitted papers should not exceed 12 pages and should be written in LaTeX with the following settings: 11pt, one column, a4paper and standard margins. Submissions should be done electronically via the following web page: http://www.easychair.org/Calculemus06/submit Submissions will be peer-reviewed. The authors of accepted submissions are expected to give a 25' presentation at the symposium. The proceedings of Calculemus'06 will be distributed at the workshop and later published possibly as a special volume of the Electronic Notes in Computer Science (ENTCS). IMPORTANT! In order to ease the (possible) publication in the ENTCS volume of the workshop proceedings, please, use the following LaTeX header in your submission: \documentclass[a4paper,11pt]{article} \textwidth 14.63cm \textheight 22cm \oddsidemargin 0.65cm \evensidemargin 0.65cm \topmargin 0.55cm \headheight 0.0pt \headsep 0.0pt Important Dates (tentative...) ------------------------------- * Submission of title and abstract: April 8, 2006 * Submission of papers: April 15, 2006 * Notification of acceptance: May 15, 2006 * Final version of papers: June 4, 2006 * Symposium: July 7-8, 2006 Program Committee ------------------ * Anna Bigatti (Università degli Studi di Genova, Italy) [Co-chair] * Christoph Benzmeuller (Saarland University, Saarbrücken, Germany) * Olga Caprotti (University of Helsinki, Finland) * Jacques Carette (McMaster University, Canada) * Hoon Hong (North Carolina State University, USA) * William M. Farmer (McMaster University, Canada) * Deepak Kapur (University of New Mexico, USA) * Steve Linton (University of St. Andrews, UK) * Madan Musuvathi (Microsoft Research, USA) * Silvio Ranise (INRIA-Lorraine, France, and Università degli Studi di Milano, Italy) [Co-chair] * Christoph Ringeissen (INRIA-Lorraine, France) * Renaud Rioboo (University of Paris 6, France) * Pino Rosolini (Università degli Studi di Genova, Italy) * Roberto Sebastiani (Università di Trento, Italy) * Volker Sorge (University of Birmingham, UK) * Carlo Traverso (Università degli Studi di Pisa, Italy) * Stephen Watt, (University of Western Ontario, Canada) From baydemir at !NS! cis.upenn.edu Wed Mar 1 13:48:56 2006 From: baydemir at !NS! cis.upenn.edu (Brian E. Aydemir) Date: Wed, 1 Mar 2006 08:48:56 -0500 Subject: [Coq-Club]Type checking problem Message-ID: Hi everyone, I fail to understand why Coq cannot type check a definition involving dependent types, so I am hoping that someone here may be able to explain what is happening. I give first a simplified version of my code that illustrates the problem. (* ******************** *) Require Import Arith. Lemma le_lt_S : forall (n m : nat), n <= m -> n < S m. Proof. intros; auto with arith. Qed. Inductive Phi : nat -> Set := | pfree : forall (n : nat), nat -> Phi n | pbound : forall (n m : nat), m < n -> Phi n | papp : forall (n : nat), Phi n -> Phi n -> Phi n | plam : forall (n : nat), Phi (S n) -> Phi n. Fixpoint abs (m : nat) (n : nat) (wf : n <= m) (a : nat) (x : Phi m) {struct x} : Phi (S m) := match x with | pfree _ a' => if eq_nat_dec a a' then pbound _ n (le_lt_S _ _ wf) else pfree _ a' | papp _ s t => papp _ (abs _ n wf a s) (abs _ n wf a t) | _ => pfree _ a end. (* ******************** *) In the definition of abs, the type checker gives the following error for the occurrence of s in the recursive call in the papp case: The term "s" has type "Phi n0" while it is expected to have type "Phi m". My guess is that in the pattern "papp _ s t", Coq fills the joker in with "n0", and from the definition of papp, that fixes the type of s to "Phi n0". My intuition says that since x has type "Phi m", that means if x has the shape "papp n0 s t", then n0 and m ought to be convertible for each other and the case should type check. Matters do not improve if I fill in the joker myself. It has been pointed out to me that I can use tactics, in particular "refine", to define my function, and the resulting term suggests that I should declare my function as Fixpoint abs (m : nat) (n : nat) (a : nat) (x : Phi m) {struct x} : (n <= m) -> Phi (S m) While this solves the problem at hand, I'm still not seeing exactly why I should expect my original definition to fail. Is there some subtlety about depend types that I have missed? Any help is appreciated. Cheers, Brian -- Brian E. Aydemir | http://www.cis.upenn.edu/~baydemir/ From roconnor at !NS! theorem.ca Wed Mar 1 14:02:58 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Wed, 1 Mar 2006 09:02:58 -0500 (EST) Subject: [Coq-Club]Type checking problem In-Reply-To: References: Message-ID: On Wed, 1 Mar 2006, Brian E. Aydemir wrote: > Hi everyone, > > I fail to understand why Coq cannot type check a definition involving > dependent types, so I am hoping that someone here may be able to > explain what is happening. I give first a simplified version of my > code that illustrates the problem. > > (* ******************** *) > Fixpoint abs > (m : nat) (n : nat) (wf : n <= m) (a : nat) (x : Phi m) {struct x} > : Phi (S m) > := > match x with > | pfree _ a' => > if eq_nat_dec a a' then pbound _ n (le_lt_S _ _ wf) else > pfree _ a' > | papp _ s t => > papp _ (abs _ n wf a s) (abs _ n wf a t) > | _ => pfree _ a > end. > (* ******************** *) The match clause should read: match x in (Phi z) return (Phi (S z)) with See: After fixing this you will have more work ahead of you: convering a to a' and back in your subexpressions. -- Russell O'Connor ``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.'' From duprat at !NS! ens-lyon.fr Thu Mar 2 09:32:55 2006 From: duprat at !NS! ens-lyon.fr (Jean.Duprat) Date: Thu, 02 Mar 2006 10:32:55 +0100 Subject: [Coq-Club]specification and Type Message-ID: <4406BBC7.4080805@ens-lyon.fr> Hi, In plane geometry, where points are elements of a Set (Parameter Point : Set.) and lines are defined as property on points (Definition Line := Point -> Prop.), I would express one of the incidence axiom saying that I can construct three points, say A, B and C, such that for every line, there exists an algorithm for finding the point among these three points, that does not belong to the line. So I try : Axiom I4 : {A:Point & {B:Point & {C:Point & (forall D : Line, {~(D A)}+{~(D B)}+{ ~(D C)}) } } }. but Coq refuses since (forall D : Line, {~(D A)}+{~(D B)}+{ ~(D C)}) has type Type when Set is expected. I would know if - I have written a bad formule, and a correct one will be accepted by Coq, - this is not possible for a fundamental reason, - or it is not possible with the current version of Coq. Thanks Jean Duprat From lionel at !NS! mamane.lu Thu Mar 2 11:11:51 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Thu, 2 Mar 2006 12:11:51 +0100 Subject: [Coq-Club]specification and Type In-Reply-To: <4406BBC7.4080805@ens-lyon.fr> References: <4406BBC7.4080805@ens-lyon.fr> Message-ID: <20060302111151.GC12275@capsaicin.mamane.lu> On Thu, Mar 02, 2006 at 10:32:55AM +0100, Jean.Duprat wrote: > Axiom I4 : {A:Point & > {B:Point & > {C:Point & > (forall D : Line, {~(D A)}+{~(D B)}+{ ~(D C)}) > } > } > }. > but Coq refuses since (forall D : Line, {~(D A)}+{~(D B)}+{ ~(D C)}) has > type Type when Set is expected. Use sigT instead of sigS. I never remember the notations and the manual / standard library on the web is not immediately helpful, but this should get you going. -- Lionel From Yves.Bertot at !NS! sophia.inria.fr Thu Mar 2 14:00:39 2006 From: Yves.Bertot at !NS! sophia.inria.fr (Yves Bertot) Date: Thu, 02 Mar 2006 15:00:39 +0100 Subject: [Coq-Club]specification and Type Message-ID: <1141308039.10619.63.camel@oldlace> It seems odd that any property would be understood as a line. More over, what would be the meaning of your axiom when instantiated for the predicate (fun x => True). Even if you manage to pass through the problem of having your sigma-types being accepted, this would tantamount (after decomposition of the axiom) to working in the following context. Parameter Point :Set. Definition Line := Point ->Prop. Parameter A:Point. Parameter B:Point. Parameter C:Point. Parameter I4: forall D:Line, {~(D A)}+{~(D B)}+{~(D C)}. But this context implies False: just take the following proof: Theorem the_contradiction : False. Proof. destruct (my_algo (fun x => True)) as [[H | H]| H]; apply H;exact I. Qed. I would rather believe you need to have a predicate on predicates that distinguishes the lines from other propositions and you should work in a context of this form: Parameter Point : Set. Parameter is_a_line : (Point -> Prop) -> Prop. Now, to pass through the problem of having your sigma-types accepted, replace any instance of { x : A & B} with sigT(fun x : A => B). Here is an example which is accepted in my version of Coq Axiom I4 : sigT (fun A:Point => sigT (fun B:Point => sigT (fun C:Point => forall D:Point->Prop, is_a_line D -> {~(D A)}+{~(D B)}+{~(D B)}))). I guess you have a clearer idea than me about what should be in the definition of "is_a_line", to make sure you capture the geometrical intuition you have in mind. Yves From Julien.Narboux at !NS! inria.fr Fri Mar 3 09:51:19 2006 From: Julien.Narboux at !NS! inria.fr (Julien Narboux) Date: Fri, 03 Mar 2006 10:51:19 +0100 Subject: [Coq-Club]specification and Type In-Reply-To: <1141308039.10619.63.camel@oldlace> References: <1141308039.10619.63.camel@oldlace> Message-ID: <44081197.5030302@inria.fr> Hi Jean, I am perhaps a bit far away from your original idea/question. But if you have somehow a definition a predicate expressing that three points are collinear then you may want to use something like that for is_a_line : Parameter Point : Set. Parameter Col : Point -> Point -> Point -> Prop. Definition is_a_line : (Point -> Prop) -> Prop := fun S : Point -> Prop => exists A, exists B, A<>B /\ forall x, S x <-> Col x A B. This is more or less what is done by Tarski, Szmielew and Schwabhäuser in the book Metamathematische Methoden in der Geometrie. I have started to formalize this book. But it seems that this formalization will not suit your needs because first it is classical and second I have chosen to keep the concept of line implicit. It is less intuitive than an approach using a definition of a line, but it saves some lemmas/unfolds. This is also what is usually done in the automated theorem proving community : for example lines are implicit in the Wu, area and Gröbner basis methods. On the other side, of course there is the Hilbert's axiomatic which is based on both points and lines. Parameter Point : Set. Parameter Line : Set. From my personal experience, from the formalization point of view, the Hilbert axiomatic has the following advantages : - it is easier to convince someone that the axioms are "true". - lines and points are treated the same way - intuitive properties appear early in the formalization (in Tarski's axiomatic, he needs 60 pages to prove the existence of the midpoint.) Tarski axiomatic has the following advantages : - it contains fewer axioms - it is easy to generalize to any dimension - the axioms "includes" degenerated cases, this leads to more "generic" proof than using Hilbert's. Hope it helps. Julien Yves Bertot a écrit : > It seems odd that any property would be understood as a line. More > over, what would be the meaning of your axiom when instantiated for > the predicate (fun x => True). Even if you manage to pass through > the problem of having your sigma-types being accepted, this would > tantamount (after decomposition of the axiom) to working in the > following context. > > Parameter Point :Set. > Definition Line := Point ->Prop. > Parameter A:Point. > Parameter B:Point. > Parameter C:Point. > Parameter I4: forall D:Line, {~(D A)}+{~(D B)}+{~(D C)}. > > But this context implies False: just take the following > proof: > > Theorem the_contradiction : False. > Proof. > destruct (my_algo (fun x => True)) as [[H | H]| H]; apply H;exact I. > Qed. > > I would rather believe you need to have a predicate on predicates > that distinguishes the lines from other propositions > and you should work in a context of this form: > > Parameter Point : Set. > Parameter is_a_line : (Point -> Prop) -> Prop. > > Now, to pass through the problem of having your sigma-types accepted, > replace any instance of { x : A & B} with sigT(fun x : A => B). > > Here is an example which is accepted in my version of Coq > > Axiom I4 : > sigT (fun A:Point => > sigT (fun B:Point => > sigT (fun C:Point => > forall D:Point->Prop, is_a_line D -> > {~(D A)}+{~(D B)}+{~(D B)}))). > > I guess you have a clearer idea than me about what should be in the > definition of "is_a_line", to make sure you capture the geometrical > intuition you have in mind. > > Yves > > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 damien.doligez at !NS! inria.fr Fri Mar 3 12:34:52 2006 From: damien.doligez at !NS! inria.fr (Damien Doligez) Date: Fri, 3 Mar 2006 13:34:52 +0100 Subject: [Coq-Club]Announce: release of Zenon Message-ID: Greetings, It is my pleasure to announce the release of Zenon, an automatic theorem prover written in OCaml. Zenon handles first-order logic with equality. Its most important feature is that it outputs the proofs of the theorems, in Coq-checkable form. This is version 0.4.1, available at < http://focal.inria.fr/zenon/ >. Unfortunately, there is no documentation yet, so this is for the adventurous spirit. It is released under the New BSD license. -- Damien From robdockins at !NS! fastmail.fm Sat Mar 4 00:39:10 2006 From: robdockins at !NS! fastmail.fm (Robert Dockins) Date: Fri, 3 Mar 2006 19:39:10 -0500 Subject: [Coq-Club]Strings for coq Message-ID: <200603031939.10313.robdockins@fastmail.fm> I've downloaded the String definition from the Coq website (http://coq.inria.fr/contribs/String.html), but I'm getting compiler errors. The package contains no real information about compiling it, and I am at a bit of a loss as to how to troubleshoot this. Can someone provide some help? Thanks Rob Dockins The error message follows: $ coqc -v The Coq Proof Assistant, version 8.0pl3 (Jan 2006) compiled on Feb 08 2006 04:00:21 $ camlp4 -v Camlp4 version 3.08.3 $ ocamlc -v The Objective Caml compiler, version 3.08.3 Standard library directory: /usr/lib/ocaml $ make ocamlc -c -I . -I /kernel -I /lib -I /library -I /parsing -I /pretyping -I /interp -I /proofs -I /syntax -I /tactics -I /toplevel -I /contrib/correctness -I /contrib/extraction -I /contrib/field -I /contrib/fourier -I /contrib/graphs -I /contrib/interface -I /contrib/jprover -I /contrib/omega -I /contrib/romega -I /contrib/ring -I /contrib/xml -I `camlp4 -where` -pp "camlp4o -I . -I /parsing pa_extend.cmo pa_ifdef.cmo q_MLast.cmo grammar.cma -impl" g_ascii_syntax.ml Warning: pa_ifdef is deprecated since OCaml 3.07. Use pa_macro instead. Error while loading "grammar.cma": file not found in path. Preprocessor error make: *** [g_ascii_syntax.cmo] Error 2 From herbelin at !NS! pauillac.inria.fr Sat Mar 4 09:35:33 2006 From: herbelin at !NS! pauillac.inria.fr (Hugo Herbelin) Date: Sat, 4 Mar 2006 10:35:33 +0100 (MET) Subject: [Coq-Club]Strings for coq In-Reply-To: <200603031939.10313.robdockins@fastmail.fm> from Robert Dockins at "Mar 3, 106 07:39:10 pm" Message-ID: <200603040935.KAA00885@pauillac.inria.fr> Hi, > I've downloaded the String definition from the Coq website > (http://coq.inria.fr/contribs/String.html), but I'm getting compiler errors. As a matter of rule, all contributions that rely on ocaml code need a copy of the Coq sources archive to be compiled. Then, you have to set the variables COQTOP to the path of the Coq sources and COQBIN to the path of the directory where reside the corresponding Coq executables (be careful to add a trailing /). Typically, in bash, you have to do: export COQTOP=/path/to/coq/sources/ export COQBIN=/path/to/coq/sources/bin/ Then, some remarks specific to the String contribution: - The compilation needs ocaml 3.07 (a workaround for both ocaml 3.08 and ocaml 3.09 is to change "loc" into "dummy_loc" in each GEXTEND block of the ml files). - The contribution provides specifications and properties of various operations on strings, and concrete syntax for parse them. The printer is not available (due to limitations of the printing mechanism that comes with Coq version 8.0). - With the consent of the contributor, the package has been integrated to the standard library of Coq version 8.1 that will be released in the spring. It will then come with a printer for the concrete syntax. Hugo Herbelin From nouvid-coq at !NS! yahoo.fr Mon Mar 6 10:40:48 2006 From: nouvid-coq at !NS! yahoo.fr (Fabrice Lemercier) Date: Mon, 6 Mar 2006 11:40:48 +0100 (CET) Subject: [Coq-Club]Graphs in Coq In-Reply-To: <200603040935.KAA00885@pauillac.inria.fr> Message-ID: <20060306104048.51388.qmail@web25914.mail.ukl.yahoo.com> I want to formalize in Coq finite directed graphs with a relation on paths. But I cannot find an elegant definition. My graphs are defined by: * The number of nodes n; * A list of arrows l: already here I have to use sig in order to make sure that source and target are existing nodes (i.e., integers strictly less that the number of nodes n); * A list of pairs of path: here I must use sig to make sure that path are composed of existing arrows (i.e., in the list of arrows l), and to make sure that the two paths have the same source and target nodes! It seems tricky. Is there more elegant way to define such notion? I had a look inside the library GRAPH-BASICS but it does not seem simpler, on the contrary. Thanks for any suggestion. ___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com From fbesson at !NS! irisa.fr Mon Mar 6 12:37:51 2006 From: fbesson at !NS! irisa.fr (=?ISO-8859-1?Q?fr=E9d=E9ric_BESSON?=) Date: Mon, 6 Mar 2006 13:37:51 +0100 Subject: [Coq-Club]Graphs in Coq In-Reply-To: <20060306104048.51388.qmail@web25914.mail.ukl.yahoo.com> References: <20060306104048.51388.qmail@web25914.mail.ukl.yahoo.com> Message-ID: On 6 Mar 2006, at 11:40, Fabrice Lemercier wrote: > I want to formalize in Coq finite directed graphs with > a relation on paths. But I cannot find an elegant > definition. What about something like that: * data-structures are not cluttered with sig types. * well-formedness conditions are stated. Require Import List. (* My data-structure for graphs *) Record Graph: Set := { Nb : nat; Edges : list (nat* nat); sources_ok : forall source target, In (source,target) Edges -> source <= Nb; target_ok : forall source target, In (source,target) Edges -> target <= Nb }. Definition path := list nat. (* What it means for a path to belong to a graph *) Inductive path_ok (G:Graph) : path -> Prop := | empty_path : path_ok G nil | cons_path : forall s t, In (s,t) (Edges G) -> forall p, path_ok G (t::p) -> path_ok G (s::t::p) . (* Returns the last element of a path *) Fixpoint last (A:Set) (l:list A) {struct l}: option A := match l with | nil => None | e::nil => Some e | e::l => last A l end. Record Graph_with_relation : Set := { (* The graph *) G : Graph; (* The relation *) R : list (path * path); (* well-formedness conditions *) R_path_ok1 : forall p1 p2 , In (p1,p2) R -> path_ok G p1; R_path_ok2 : forall p1 p2 , In (p1,p2) R -> path_ok G p2; R_same_orig : forall p1 p2, In (p1,p2) R -> head p1 = head p2; R_same_dest : forall p1 p2 , In (p1,p2) R -> last _ p1 = last _ p2 (* You might also want to rule out the empty path *) }. -- Frédéric Besson From riccardo-pini at !NS! libero.it Tue Mar 7 16:12:00 2006 From: riccardo-pini at !NS! libero.it (riccardo-pini) Date: Tue, 7 Mar 2006 17:12:00 +0100 Subject: [Coq-Club]Coq and Pocket PC Message-ID: Hi, im already using Coq under Linux, but i have also a Pocket Pc HP4700, is there a version of it for Windows Mobile 2003 on my Ipaq HP4700? Greetings, Riccardo Pini From lionel at !NS! mamane.lu Fri Mar 10 12:09:52 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Fri, 10 Mar 2006 13:09:52 +0100 Subject: [Coq-Club]Coq and Pocket PC In-Reply-To: References: Message-ID: <20060310120952.GA15943@capsaicin.mamane.lu> On Tue, Mar 07, 2006 at 05:12:00PM +0100, riccardo-pini wrote: > im already using Coq under Linux, but i have also a Pocket Pc > HP4700, is there a version of it for Windows Mobile 2003 on my Ipaq > HP4700? I don't know, but you can install GNU/Linux on your Ipaq HPO4700 and use it there :) -- Lionel From roconnor at !NS! theorem.ca Mon Mar 13 10:08:14 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Mon, 13 Mar 2006 05:08:14 -0500 (EST) Subject: [Coq-Club]Making intros with explict patterns. Message-ID: I don't suppose there is a tool for taking coq source files and replacing all intros tactics with intros with explicit names. intros. replaced by intros H. (and similiary replacing destruct with destruct as, etc.) -- Russell O'Connor ``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.'' From jean-francois.monin at !NS! imag.fr Mon Mar 13 11:11:59 2006 From: jean-francois.monin at !NS! imag.fr (jean-francois.monin@imag.fr) Date: Mon, 13 Mar 2006 12:11:59 +0100 Subject: [Coq-Club]Making intros with explict patterns. In-Reply-To: References: Message-ID: <17429.21375.348970.476377@ferrat.imag.fr> Try info . I think you could be satisfied with info intros. info (destruct x) and info (induction x) are less satisfactory. JFM roconnor@theorem.ca a ecrit : > I don't suppose there is a tool for taking coq source files and > replacing all intros tactics with intros with explicit names. > > intros. > > replaced by > > intros H. > > (and similiary replacing destruct with destruct as, etc.) > > -- > Russell O'Connor > ``All talk about `theft,''' the general counsel of the American Graphophone -- Jean-François Monin Univ. Joseph Fourier, GRENOBLE VERIMAG - Centre Equation http://www-verimag.imag.fr/~monin/ 2 avenue de Vignate tel (+33 | 0) 4 56 52 03 72 F-38610 GIERES fax (+33 | 0) 4 56 52 03 44 From lionel at !NS! mamane.lu Mon Mar 13 14:28:53 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Mon, 13 Mar 2006 15:28:53 +0100 Subject: [Coq-Club]Making intros with explict patterns. In-Reply-To: <17429.21375.348970.476377@ferrat.imag.fr> References: <17429.21375.348970.476377@ferrat.imag.fr> Message-ID: <20060313142853.GA17305@capsaicin.mamane.lu> On Mon, Mar 13, 2006 at 12:11:59PM +0100, jean-francois.monin@imag.fr wrote: > I think you could be satisfied with info intros. There is also "Show Intros.", but it seems to be buggy. I'm trying with a fresh SVN trunk checkout and reporting a bug if not fixed. -- Lionel From Miki.Hermann at !NS! lix.polytechnique.fr Mon Mar 13 14:32:45 2006 From: Miki.Hermann at !NS! lix.polytechnique.fr (Miki Hermann) Date: Mon, 13 Mar 2006 15:32:45 +0100 Subject: [Coq-Club]3rd CFP LPAR 2006, Phnom Penh, SUBMISSION IS OPEN NOW Message-ID: <17429.33421.779199.894353@mucha.polytechnique.fr> [Apologies for multiple copies and crossposting] ========================================================================== LPAR-13 Phnom Penh, Cambodia http://www.lix.polytechnique.fr/~hermann/LPAR2006/ 13th-17th November 2006 2nd Call For Papers The 13th International Conference on Logic for Programming Artificial Intelligence and Reasoning (LPAR-13) will be held 13th-17th November 2006, at the Hotel Cambodiana, Phnom Penh, Cambodia. Submission of papers for presentation at the conference is now invited. Topics of interest include: + automated reasoning + propositional reasoning + interactive theorem proving + description logics + software verification + hardware verification + software testing + logic and ontologies + proof assistants + network and protocol verification + proof planning + nonmonotonic reasoning + proof checking + constructive logic and type theory + rewriting and unification + lambda and combinatory calculi + logic programming + knowledge representation and reasoning + modal and temporal logics + constraint programming + systems specification and synthesis + logical foundations of programming + model checking + computational interpretations of logic + proof-carrying code + logic and computational complexity + logic and databases + logic in artificial intelligence + reasoning for the semantic web + reasoning about actions Full and short papers are welcome. Full papers may be either regular papers containing new results, or experimental papers describing implementations or evaluations of systems. Short papers may describe work in progress or provide system descriptions. Submitted papers must be original, and not submitted concurrently to a journal or another conference. The full paper proceedings of LPAR-13 will be published by Springer-Verlag in the LNAI series. Authors of accepted full papers will be required to sign a form transferring copyright of their contribution to Springer-Verlag. The short paper proceedings of LPAR-13 will be published by the conference. Program Committee ----------------- María Alpuente Technical University of Valencia Franz Baader Technische Universität Dresden Matthias Baaz Vienna University of Technology Christoph Benzmüller Universität des Saarlandes Koen Claessen Chalmers University of Technology Javier Esparza University of Stuttgart Berndt Fischer University of Southampton Jürgen Giesl RWTH Aachen Jean Goubault-Larrecq ENS Cachan Erich Grädel Aachen University of Technology Ziyad Hanna Intel Pascal van Hentenryck Brown University Miki Hermann CNRS and École Polytechnique Brahim Hnich University College Cork Ian Horrocks, University of Manchester Viktor Kuncak MIT Orna Kupferman Hebrew University Christopher Lynch Clarkson University Dale Miller INRIA Futurs and École Polytechnique George Necula UC Berkeley Joachim Niehren LIFL and INRIA Futurs Luke Ong Oxford University Catuscia Palamidessi LIX and INRIA Futurs Michel Parigot PPS and CNRS Frank Pfenning Carnegie Mellon University Reinhard Pichler Vienna University of Technology Michael Rusinowitch LORIA and INRIA-Lorraine Mooly Sagiv Tel-Aviv University Gernot Salzer Vienna University of Technology Christelle Scharff Pace University Sopheap Seng ITC Phnom Penh Geoff Sutcliffe University of Miami Sophie Tison LIFL and Université de Lille Margus Veanes Microsoft Research Andrei Voronkov University of Manchester and Microsoft Research Submission Instructions ----------------------- Papers must be prepared using the Springer-Verlag instructions for authors (http://www.springer.de/comp/lncs/authors.html). Papers may be up to 15 pages. If proofs do not fit in 15 pages, an appendix with proofs may be added. Short papers may be up to 5 pages. Papers must be submitted in plain postscript or PDF format, through the online submission system (http://www.easychair.org/LPAR06/). Dates and Deadlines: + Submission of full paper abstracts 2nd May + Submission of full papers 9th May + Notification of acceptance of full papers 10th July + Camera ready versions of full papers due 5th September + Submission of short papers 28th August + Notification of acceptance of short papers 11th September + Camera ready versions of short papers due 25th September Questions related to submission may be sent to the program chairs, Miki Hermann and Andrei Voronkov. -------------------------------------------------------------------------- Cambodia ... Land of LPAR and Pagodas -------------------------------------------------------------------------- From Peter.Sewell at !NS! cl.cam.ac.uk Mon Mar 13 15:55:04 2006 From: Peter.Sewell at !NS! cl.cam.ac.uk (Peter Sewell) Date: Mon, 13 Mar 2006 15:55:04 +0000 Subject: [Coq-Club]Three Research Positions - Foundations of Distributed Computation Message-ID: [Apologies for multiple posting!] We'd be grateful if you could draw this to the attention of any suitable candidates. Thanks, Peter RESEARCH ASSOCIATE/RESEARCH ASSISTANT (THREE POSTS) Foundations of Distributed Computation Computer Laboratory, University of Cambridge Ref No: NR60 Grade: NRAS Salary: £20,044 - £30,002 pa. Grade: RAST Salary: £20,044 - £22,289 pa Limit of tenure: Up to two years for two Research Associate positions; one year for one Research Assistant position. Three Research Assistant/Research Associate positions are available in the foundations of distributed computation, funded by EPSRC grants EP/C510712 (Sewell, Gibbens, Norrish) and GR/T11715 (Sewell, Pitts). The work spans several areas: * Design, semantics and implementation of programming language constructs for distribution - covering type-safe communication, naming, version change, module systems, and dynamic linking. * Formal specification, automated testing and proof about real-world network protocols. * Tool support for mechanisation of large semantic definitions. * Reasoning about executable distributed programs. It builds on previous work on the experimental Acute programming language, on the NetSem semantics of real-world network protocols, and on the concerns of the POPLmark challenge problem in semantic mechanisation. Details of all these can be found at . For the two-year positions you should have (or expect soon to obtain) a PhD in Computer Science, with a strong background in one or more of the following: * Programming Language Semantics * Programming Language Implementation (especially with respect to OCaml) * Automated proof assistants (especially one or more of HOL, Isabelle, Coq, and Twelf). * Network Protocols * Distributed Systems The one-year appointment may be either at the postdoctoral level (Research Associate) as above, or at a post-graduate level (Research Assistant). For the latter you should have a good first-class degree in Computer Science. For a suitably experienced candidate it may be possible to upgrade to a Senior Research Associate appointment. Enquiries about the project should be addressed to Dr Peter Sewell, . To apply please send as soon as possible a letter of application including a brief statement of the particular contribution you would make to the project, a CV, a completed PD18 form () and the names and contact details (postal and email addresses) of 2 referees to Kate Ellis University of Cambridge Computer Laboratory 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom or by e-mail (with documents in PDF format) to personnel-admin@cl.cam.ac.uk. Closing date: 20 April 2006. From ctm at !NS! cs.nott.ac.uk Tue Mar 14 15:15:15 2006 From: ctm at !NS! cs.nott.ac.uk (Conor McBride) Date: Tue, 14 Mar 2006 15:15:15 +0000 Subject: [Coq-Club]Penultimate Call for Talks & Early Registration: TYPES 2006 Message-ID: <4416DE03.1040901@cs.nott.ac.uk> The deadline is approaching (Wednesday 23:59, Samoan time) - please register. So far we have 57 external registrations, i.e. all your friends are going. Consider coming as well... :-) Cheers, Thorsten TYPES 2006 Main Conference of the Types Project Nottingham, UK, 18-21 April 2006 http://www.cs.nott.ac.uk/types06/ This is the latest meeting in a series that started 1992, the previous conference was in December 2004 in Paris. The topic of the meeting is formal reasoning and computer programming based on Type Theory : languages and computerised tools for reasoning, and applications in several domains such as analysis of programming languages, certified software, formalisation of mathematics and mathematics education. TYPES 2006 is colocated with TFP 2006 (Trends in Functional Programming) and we plan to hold a joint session on Dependently Typed Programming. Invited Speakers are: Bart Jacobs, Simon Peyton Jones (joint with TFP) and Hongwei Xi The conference takes place at Jubilee campus of the University of Nottingham, on-site accomodation will be available together with the registration. For more information see: http://www.cs.nott.ac.uk/types06/ Please direct all emails related to TYPES 2006 to types06@cs.nott.ac.uk Cheers, The Organisation Comittee Thorsten Altenkirch, James Chapman, Conor McBride, Peter Morris and Wouter Swierstra . From flaviomoura at !NS! unb.br Tue Mar 14 15:42:11 2006 From: flaviomoura at !NS! unb.br (Flavio de Moura) Date: Tue, 14 Mar 2006 13:42:11 -0200 Subject: [Coq-Club]Explicit substitutions Message-ID: <4416E453.3040103@unb.br> Hello, I am interested in explicit substitutions and, I am looking for some paper that explains how Coq deal with higher-order unification. Does it use explicit substitutions? If so, which calculus is implemented? Any paper (or comments) in this direction is very appreciated. Best regards, Flavio de Moura. From isratju1 at !NS! yahoo.com Thu Mar 16 04:38:27 2006 From: isratju1 at !NS! yahoo.com (Israt Jahan) Date: Wed, 15 Mar 2006 20:38:27 -0800 (PST) Subject: [Coq-Club]Seeking help on Coq Message-ID: <20060316043827.48128.qmail@web53713.mail.yahoo.com> --0-93452895-1142483907=:46172 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sir, In Coq version 8.0, what command is used instead of the command Syntactic Definition. Israt Jahan. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-93452895-1142483907=:46172 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Sir,

In Coq version 8.0, what command is used instead of the command Syntactic Definition.

Israt Jahan.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-93452895-1142483907=:46172-- From Christine.Paulin at !NS! lri.fr (Christine Paulin) Thu Mar 16 14:40:32 2006 From: Christine.Paulin at !NS! lri.fr (Christine Paulin) (Christine Paulin) Date: Thu, 16 Mar 2006 15:40:32 +0100 Subject: [Coq-Club]Post-doc positions at INRIA In-Reply-To: <16977.977.607564.800977@serveur9-10.lri.fr> References: <16977.977.607564.800977@serveur9-10.lri.fr> Message-ID: <17433.30944.981372.682540@serveur9-10.lri.fr> Hello, INRIA proposes one-year post-doctoral positions for young Phd graduates. Deadline for application is March 30th see http://www.inria.fr/travailler/opportunites/postdoc/postdoc.en.html You may be interested in particular by subjects proposed by the following groups Located in Saclay (Orsay) near Paris Comete (C. Palamidessi) Tools for the specification and verification of probabilistic security protocols LogiCal (G. Dowek, B. Werner) Structuration and development of the standard library of the Coq system Parsifal (D. Miller) Reasoning about Logic Specifications ProVal (C. Paulin) Trustworthy Decision Procedures Integration of interactive and automatic proof tools Certified Compilation of Scade/Lustre or Located in Sophia-Antipolis Everest (G. Barthe) Formal proofs of provable cryptography Christine Paulin -- Christine Paulin-Mohring mailto : Christine.Paulin@lri.fr LRI, UMR 8623 CNRS, Bat 490, Université Paris Sud, 91405 ORSAY Cedex tel : (+33) (0)1 69 15 66 35 fax : (+33) (0)1 69 15 65 86 From pierre.casteran at !NS! labri.fr Thu Mar 16 15:17:59 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Thu, 16 Mar 2006 16:17:59 +0100 Subject: [Coq-Club]Seeking help on Coq In-Reply-To: <20060316043827.48128.qmail@web53713.mail.yahoo.com> References: <20060316043827.48128.qmail@web53713.mail.yahoo.com> Message-ID: <441981A7.8070203@labri.fr> Israt Jahan wrote: > Sir, > In Coq version 8.0, what command is used instead of the command > Syntactic Definition. > Israt Jahan. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > Hello, Abbreviations are like syntactic definitions of versions prior to V8. Ex : Notation List := (list nat). Abbreviations are described in section 11.3 of the Reference manual. Notice that the vernacular command "Notation" allows much more than this kind of example. Have a look at section 11.1 too. Pierre From Guillaume.Rousse at !NS! inria.fr Fri Mar 17 13:04:01 2006 From: Guillaume.Rousse at !NS! inria.fr (Guillaume Rousse) Date: Fri, 17 Mar 2006 14:04:01 +0100 Subject: [Coq-Club]Packaging coq for mandriva Message-ID: <441AB3C1.3050203@inria.fr> Hello. I introduced an official coq package in mandriva contributions. Currently, it is only available for development version (cooker), but it should be automatically included from next stable version. You may be interested by the spec file, so as to improve your current redhat package. It is available from http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/coq. Please don't distribute the mandriva package, however, and redirect mandriva users to official mirrors instead. Curiously, I had to disable automatic stripping of the binaries, as it broke them: [guillomovitch@n2 bin]$ file coqc coqc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped [guillomovitch@n2 bin]$ ./coqc -v The Coq Proof Assistant, version 8.0pl3 (Jan 2006) compiled on Mar 17 2006 13:47:38 [guillomovitch@n2 bin]$ strip coqc [guillomovitch@n2 bin]$ file coqc coqc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped [guillomovitch@n2 bin]$ ./coqc -v No bytecode file specified. The same is true for all binaries. I don't know if this can be considered as a bug in coq, or in strip, but Im' interested by a sensible explanation :) From lionel at !NS! mamane.lu Fri Mar 17 13:18:54 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Fri, 17 Mar 2006 14:18:54 +0100 Subject: [Coq-Club]Packaging coq for mandriva In-Reply-To: <441AB3C1.3050203@inria.fr> References: <441AB3C1.3050203@inria.fr> Message-ID: <20060317131854.GA17218@capsaicin.mamane.lu> On Fri, Mar 17, 2006 at 02:04:01PM +0100, Guillaume Rousse wrote: > I introduced an official coq package in mandriva contributions. > Curiously, I had to disable automatic stripping of the binaries, as > it broke them: > I don't know if this can be considered as a bug in coq, or in strip, > but Im' interested by a sensible explanation :) 1) It seems you built Coq as bytecode and not as native code. It would be best to ship _both_ bytecode and native code versions (the bytecode version can do more, but the native code version is faster). 2) The executables you produced are made of the bytecode interpreter, plus the bytecode itself in an ELF section that strip will strip. Thus strip removes the actual program to be executed and leaves only the bytecode interpreter in place. See http://camltest.inria.fr/pub/ml-archives/caml-list/2002/08/5ebd2f600fc266e0e551d97492fedb86.en.html . -- Lionel From Guillaume.Rousse at !NS! inria.fr Fri Mar 17 13:53:03 2006 From: Guillaume.Rousse at !NS! inria.fr (Guillaume Rousse) Date: Fri, 17 Mar 2006 14:53:03 +0100 Subject: [Coq-Club]Packaging coq for mandriva In-Reply-To: <20060317131854.GA17218@capsaicin.mamane.lu> References: <441AB3C1.3050203@inria.fr> <20060317131854.GA17218@capsaicin.mamane.lu> Message-ID: <441ABF3F.3020100@inria.fr> Lionel Elie Mamane wrote: > On Fri, Mar 17, 2006 at 02:04:01PM +0100, Guillaume Rousse wrote: > >> I introduced an official coq package in mandriva contributions. > >> Curiously, I had to disable automatic stripping of the binaries, as >> it broke them: > >> I don't know if this can be considered as a bug in coq, or in strip, >> but Im' interested by a sensible explanation :) > > > 1) It seems you built Coq as bytecode and not as native code. It would > be best to ship _both_ bytecode and native code versions (the > bytecode version can do more, but the native code version is > faster). Arf :( According to the INSTALL file, just having the native ocaml compiler available should be sufficient to build both versions. However, this is only true for coqide and coqtop, all others are built in just one version. > 2) The executables you produced are made of the bytecode interpreter, > plus the bytecode itself in an ELF section that strip will > strip. Thus strip removes the actual program to be executed and > leaves only the bytecode interpreter in place. I guess the purpose of mixing both bytecode and native in the same file is to make execution easier (./coqc instead of camlrun coqc), but it quite defeats the purpose of bytecode portability (and mislead file identification). Shouldn't some kind of shellbang use (#!/usr/bin/ocmalrun) achieve the same result without the side-effects ? I've seen this with some scheme implementations, for instance. From Xavier.Leroy at !NS! inria.fr Fri Mar 17 14:06:59 2006 From: Xavier.Leroy at !NS! inria.fr (Xavier Leroy) Date: Fri, 17 Mar 2006 15:06:59 +0100 Subject: [Coq-Club]Packaging coq for mandriva In-Reply-To: <441ABF3F.3020100@inria.fr> References: <441AB3C1.3050203@inria.fr> <20060317131854.GA17218@capsaicin.mamane.lu> <441ABF3F.3020100@inria.fr> Message-ID: <441AC283.9060806@inria.fr> >>2) The executables you produced are made of the bytecode interpreter, >> plus the bytecode itself in an ELF section that strip will >> strip. Thus strip removes the actual program to be executed and >> leaves only the bytecode interpreter in place. > > I guess the purpose of mixing both bytecode and native in the same file > is to make execution easier (./coqc instead of camlrun coqc), but it > quite defeats the purpose of bytecode portability (and mislead file > identification). Shouldn't some kind of shellbang use > (#!/usr/bin/ocmalrun) achieve the same result without the side-effects ? Yes, Caml can do that as well. However, there are cases where a pure bytecode executable cannot be produced, e.g. when linking with C code that cannot be dynamically loaded. For Coq, it's hard to tell whether a pure bytecode executable is possible, because scripts/coqmktop.ml invokes ocamlc with the "-custom" flag, which forces creation of a mixed ELF/bytecode executable in any case. I don't know whether this flag is here because it is really necessary or because it's a left-over from the times when Caml lacked dynamic loading of C libraries and needed -custom more often than now. - Xavier Leroy From roconnor at !NS! theorem.ca Fri Mar 17 15:41:27 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Fri, 17 Mar 2006 10:41:27 -0500 (EST) Subject: [Coq-Club]Unexpected behavour of Opaque Message-ID: Why is it that when you declare something as Opaque in a module, it become transparent when the module is imported. For example (* File: foo.v *) Definition X := nat. Lemma foo1 : X -> nat. unfold X. tauto. Qed. Opaque X. Lemma foo2 : X -> nat. (* unfold X. doesn't work *) apply foo1. Qed. But now when foo.v is imported (* File: bar.v *) Require Export foo. Lemma bar1 : X -> nat. unfold X. (* Now works *) tauto. Qed. -- Russell O'Connor ``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.'' From lionel at !NS! mamane.lu Fri Mar 17 21:56:34 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Fri, 17 Mar 2006 22:56:34 +0100 Subject: [Coq-Club]Unexpected behavour of Opaque In-Reply-To: References: Message-ID: <20060317215634.GF19765@capsaicin.mamane.lu> On Fri, Mar 17, 2006 at 10:41:27AM -0500, roconnor@theorem.ca wrote: > Why is it that when you declare something as Opaque in a module, it become > transparent when the module is imported. For example > (* File: foo.v *) > Definition X := nat. (...) > Opaque X. Well, it is the documented behaviour. At section or module closing, a constant recovers the status it got at the time of its definition. I suppose that the "Opaque/Transparent" commands were supposed to be mainly tactic hints, and not actually change the status of the defined object. -- Lionel From jg at !NS! netvisao.pt Mon Mar 20 22:31:08 2006 From: jg at !NS! netvisao.pt (=?iso-8859-1?Q?Jo=E3o_Gomes?=) Date: Mon, 20 Mar 2006 22:31:08 -0000 (WET) Subject: [Coq-Club]problems installing Coq Message-ID: <40303.217.129.251.65.1142893868.squirrel@webmail.cabovisao.pt> Hi! I'm having problems installing Coq in Ubuntu Linux: " $ ./configure You have Objective-Caml 3.09.1. Good! You have native-code compilation. Good! LablGtk2 found, native threads: native CoqIde will be available Where should I install the Coq binaries [/usr/local/bin] ? Where should I install the Coq library [/usr/local/lib/coq] ? Where should I install the Coq man pages [/usr/local/man] ? Where should I install the Coq Emacs mode [/usr/share/emacs/site-lisp] ? Where should I install Coqdoc TeX/LaTeX files [/usr/share/texmf/tex/latex/misc] ? Should I compile the complete theory of real analysis [Y/N, default is Y] ? Coq top directory : /home/joao/coq-8.0pl3 Architecture : i686 OS dependent libraries : -cclib -lunix Objective-Caml/Camlp4 version : 3.09.1 Objective-Caml/Camlp4 binaries in : /usr/local/bin Objective-Caml library in : /usr/local/lib/ocaml Camlp4 library in : +camlp4 Reals theory : All CoqIde : opt Paths for true installation: binaries will be copied in /usr/local/bin library will be copied in /usr/local/lib/coq man pages will be copied in /usr/local/man emacs mode will be copied in /usr/share/emacs/site-lisp If anything in the above is wrong, please restart './configure' *Warning* To compile the system for a new architecture don't forget to do a 'make archclean' before './configure'. $ make world OCAMLC config/coq_config.ml OCAMLC -o bin/coqmktop /usr/bin/ld: cannot open output file bin/coqmktop: Arquivo ou diretório não encontrado collect2: ld returned 1 exit status Error while building custom runtime system make: ** [bin/coqmktop] Erro 2 " I can't understand what is going on. Please, can someone help me? Thank you! João From bruno.barras at !NS! inria.fr Tue Mar 21 17:08:08 2006 From: bruno.barras at !NS! inria.fr (Bruno Barras) Date: Tue, 21 Mar 2006 18:08:08 +0100 Subject: [Coq-Club]problems installing Coq In-Reply-To: <40303.217.129.251.65.1142893868.squirrel@webmail.cabovisao.pt> References: <40303.217.129.251.65.1142893868.squirrel@webmail.cabovisao.pt> Message-ID: <442032F8.2090802@inria.fr> João Gomes wrote: >$ make world >OCAMLC config/coq_config.ml >OCAMLC -o bin/coqmktop >/usr/bin/ld: cannot open output file bin/coqmktop: Arquivo ou diretório >não encontrado >collect2: ld returned 1 exit status >Error while building custom runtime system >make: ** [bin/coqmktop] Erro 2 >" > >I can't understand what is going on. > > > Check that you have a (possibly empty) directory bin/ in coq-8.0pl3. If not, create it and try again (some decompression tools might not create empty dirs, which is nasty). If it exists, check that it does not contain a write-protected coqmktop file. Otherwise, you might have a serious installation problem with either ocaml or gcc. Try running LC_ALL=C make VERBOSE=1 CAMLDEBUG="-ccopt -###" bin/coqmktop it may help spot at which stage compilation fails and why. Hope this helps. Bruno Barras. From jg at !NS! netvisao.pt Tue Mar 21 19:33:40 2006 From: jg at !NS! netvisao.pt (=?iso-8859-1?Q?Jo=E3o_Gomes?=) Date: Tue, 21 Mar 2006 19:33:40 -0000 (WET) Subject: [Coq-Club]problems installing Coq In-Reply-To: <442032F8.2090802@inria.fr> References: <40303.217.129.251.65.1142893868.squirrel@webmail.cabovisao.pt> <442032F8.2090802@inria.fr> Message-ID: <56062.217.129.251.65.1142969620.squirrel@webmail.cabovisao.pt> Sorry, I forgot to say that I had already found the solution. You are right. It was the simple problem of bin directory did existed. :) Thank you for your help! João Bruno Barras wrote: João Gomes wrote: >$ make world >OCAMLC config/coq_config.ml >OCAMLC -o bin/coqmktop >/usr/bin/ld: cannot open output file bin/coqmktop: Arquivo ou diretório >não encontrado >collect2: ld returned 1 exit status >Error while building custom runtime system >make: ** [bin/coqmktop] Erro 2 >" > >I can't understand what is going on. > > > Check that you have a (possibly empty) directory bin/ in coq-8.0pl3. If not, create it and try again (some decompression tools might not create empty dirs, which is nasty). If it exists, check that it does not contain a write-protected coqmktop file. Otherwise, you might have a serious installation problem with either ocaml or gcc. Try running LC_ALL=C make VERBOSE=1 CAMLDEBUG="-ccopt -###" bin/coqmktop it may help spot at which stage compilation fails and why. Hope this helps. Bruno Barras. From isratju1 at !NS! yahoo.com Fri Mar 17 03:29:29 2006 From: isratju1 at !NS! yahoo.com (Israt Jahan) Date: Thu, 16 Mar 2006 19:29:29 -0800 (PST) Subject: [Coq-Club]Seeking help on Coq Message-ID: <20060317032929.44825.qmail@web53715.mail.yahoo.com> --0-938954930-1142566169=:42582 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sir, Ihank you very much for your reply. I am developing a program, in which cons operator is necessary. But, after compiling the following line alaways an error is coming. I am giving the line: Inductive known_in : C -> SD -> Prop := E0 : (c1 c2 : C) (s :SD) (known_in c1 s) -> (known_in c1 (cons C c2 s)) Here, I have declared C as Set, SD is defined as (list C). While compiling this line in Coq, it declares that c2 is defined as type C but it must be of type listSet. Sir, if could help me to solve this problem, it will be very helpful to me. Israt Jahan. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-938954930-1142566169=:42582 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Sir,

Ihank you very much for your reply. I am developing a program, in which cons operator is necessary. But, after compiling the following line alaways an error is coming. I am giving the line:

Inductive known_in : C -> SD -> Prop :=

E0 : (c1 c2 : C) (s :SD) (known_in c1 s) -> (known_in c1 (cons C c2 s))

Here, I have declared C as Set, SD is defined as (list C). While compiling this line in Coq, it declares that c2 is defined as type C but it must be of type listSet.

Sir, if could help me to solve this problem, it will be very helpful to me.

Israt Jahan.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-938954930-1142566169=:42582-- From isratju1 at !NS! yahoo.com Sun Mar 19 04:36:45 2006 From: isratju1 at !NS! yahoo.com (Israt Jahan) Date: Sat, 18 Mar 2006 20:36:45 -0800 (PST) Subject: [Coq-Club]seeking helpon Coq. Message-ID: <20060319043645.46185.qmail@web53709.mail.yahoo.com> --0-2107085107-1142743005=:33808 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sir, When I write ' Require Import securite', then after compilation, the answer is securite library is not found on the load path. Sir, my question is whether securite library exists in coq version 8.0. Thanks, Israt Jahan --------------------------------- Yahoo! Mail Bring photos to life! New PhotoMail makes sharing a breeze. --0-2107085107-1142743005=:33808 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Sir,

When I write ' Require Import securite', then after compilation, the answer is securite library is not found on the load path. Sir, my question is whether securite library exists in coq version 8.0.

Thanks,

Israt Jahan

Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze. --0-2107085107-1142743005=:33808-- From chechik at !NS! cs.toronto.edu Tue Mar 21 01:21:47 2006 From: chechik at !NS! cs.toronto.edu (Marsha Chechik) Date: Mon, 20 Mar 2006 20:21:47 -0500 Subject: [Coq-Club]Formal Methods 2006: Call for Demos (Commercial and Research) and Posters Message-ID: <20060321012147.4E5244A933@qew.cs> Appologies if you receive multiple copies of this announcement. For information on commercial demos and exhibits, please read on. --------------------------------- Call for Posters & Research Tool Demonstrations 14th International Formal Methods Symposium (FM'06) McMaster University, Hamilton, Canada August 21-27, 2006 http://fm06.mcmaster.ca FM'06 is the fourteenth in a series of symposia organized by Formal Methods Europe, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. The symposia have been notably successful in bringing together innovators and practitioners in precise mathematical methods for software development, industrial users as well as researchers. Tools are central to the success of formal methods in practice. Hence, tool demonstrations will have a prominent role in the conference. Demonstrators will be expected to present their tools during specially-designated time that will be scheduled into the conference program. Tool demonstrations should be accompanied by a poster. In addition, a collection of short papers (2-3 pages), for every accepted tool demonstration, will be published as a technical report and available to conference attendees. The authors maintain copyright on their written tool description. We solicit proposals for tool demonstrations related to automated reasoning using formal methods. Tools can range from alpha-versions to fully developed products that are being prepared for commercialization. Products that are currently being commercialized will not be accepted as subjects of demonstrations (see call for commercial exhibits and tool demonstrations). Research tool demonstrations are not intended to be sales pitches, and should consequently highlight technical contributions. For further clarification, please contact the tool demonstrations chair. Priority will be given to tools based on sound, rigorous research results to support the automation of analysis and/or verification of software or hardware systems. We also solicit posters describing late-breaking results related to the theme of the conference. Like tool demonstrations, accepted posters will be accompanied by a short paper published as a technical report and available to conference attendees. Poster presenters are expected to be available during a specially-scheduled time during the conference to present their work. Review Process The Posters & Demos Committee will review each submission using the standard FM criteria: originality and importance of contribution, soundness of rationale or demonstration, quality of written and graphic presentation, and appropriate consideration of relevant literature. Equipment Demonstrators are expected to provide their own equipment. How to submit Submissions of proposals for posters & tool demonstrations must: For demos: * be no more than 3 pages in LNCS format, describing the technology or approach, what is the research that has gone into the tool, how it relates to other industrial or research efforts, including references, and what are the expected benefits. * have an appendix (not included in the 3-page count) that provides a detailed description of how the presentation would be conducted (possibly illustrated with a number of snapshots), information on tool availability and maturity, and the URL of a web-page for the tool (if one exists). For Posters: * be no more than 3 pages in LNCS format, describing the approach, how it relates to other industrial or research efforts, including references, and what are the expected benefits. For Demos and Posters: * be sent to by email to Marsha Chechik (chechik at cs dot toronto dot edu) by the Posters & Demos submission deadline. Please begin the subject line with "FM 2006 Demo" or "FM 2006 Poster". Accepted Posters and Demonstrations Accepted posters and demonstrations will be published as short papers in a special technical report, available to conference attendees. In addition, the authors should be available for answering questions or demonstrating their tools at scheduled times during the conference. Important Dates Submission deadline: May 26, 2006. Author notification: June 12, 2006. Camera-ready papers: June 22, 2006. Tool Demo & Poster Chair Marsha Chechik Department of Computer Science University of Toronto Toronto, Ontario Canada -------------------------------------------------------------------- Call for Commercial Exhibits and Tool Demonstrations 14th International Formal Methods Symposium (FM'06) McMaster University, Hamilton, Canada August 21-27, 2006 http://fm06.mcmaster.ca FM'06 is the fourteenth in a series of symposia organized by Formal Methods Europe, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. The symposia have been notably successful in bringing together innovators and practitioners in precise mathematical methods for software development, industrial users as well as researchers. Attendance will include roughly 250 researchers and practitioners from industry and academia. This is the first time FM is held in North America. Exhibition and commercial tool demonstration space is available and will be accessible to attendees for the duration of the conference (August 21-27, 2006.). One-day attendance is also available. For a nominal cost, the conference will provide space for a booth and a demo, as well as an opportunity to present the tool at lunch time during the Industry Day (August 23, 2006), and once as a parallel track to the technical paper session. Interested exhibitors should contact Marsha Chechik (chechik at cs dot toronto dot edu) for payment details and to request any special space or demonstration needs. Important Dates Application due May 26, 2006 Full Payment Due June 23, 2006 From ctm at !NS! cs.nott.ac.uk Tue Mar 21 17:33:35 2006 From: ctm at !NS! cs.nott.ac.uk (Conor McBride) Date: Tue, 21 Mar 2006 17:33:35 +0000 Subject: [Coq-Club]CFP2: Mathematically Structured Functional Programming Message-ID: <442038EF.5000306@cs.nott.ac.uk> SECOND CALL FOR PAPERS Workshop on Mathematically Structured Functional Programming MSFP 2006 Kuressaare, Estonia, 2 July 2006 http://cs.ioc.ee/mpc-amast06/msfp/ a satellite workshop of MPC 2006 a "small workshop" of the TYPES project Background Something wonderful happened when monads arrived in Haskell: some human mathematics explaining the structure of certain computational phenomena became a mechanical means to implement those phenomena. It's a good way to go about functional programming - to dig out the mathematical structure underlying a problem and set it to work! There's more where monads came from, and we want it. This new workshop is about getting it. In recent years, a diverse array of mathematical structures has appeared in our programs: monads dualise to comonads and generalise to Freyd categories aka 'arrows'; 'container' types have a generalised polynomial structure supporting generic programming, not to mention a differential calculus; isomorphisms from 'high school algebra' are used to search libraries and repair type errors; coalgebras give structure to recursion; the list goes on... MSFP is broad in scope, covering the extraction of functionality from structure wherever it can be found. It complements the remit of its host conference, Mathematics of Program Construction, by seeking to enrich the language and toolset available for specifications and programs alike. It is also a "small workshop" of the FP6 IST coordination action TYPES. Invited speakers Andrzej Filinski, Kbenhavns Universitet John Power, University of Edinburgh Important dates * Submission of papers: 10 April 2006 * Notification of authors: 8 May 2006 * Camera-ready version: 5 June 2006 Topics Submissions are welcome on, but by no means restricted to, topics from the following partially computed coinductive list: * structured effectful computation * structured recursion * structured tree and graph operations * structured syntax with variable binding * structures for datatype-genericity * structures for search * structured representations of functions * structured manipulation of mathematical structure * structured in functional programming Authors concerned about the suitability of a topic are very welcome to contact Conor McBride, ctm(at)cs.nott.ac.uk. Submission and publication Papers in pdf not exceeding 15 pages and adhering to the eWiC style must be submitted by 10 April 2006 via an online submission webpage. Papers must report previously unpublished work and not be submitted concurrently to another conference with refereed proceedings. Accepted papers must be presented at the workshop by one of the authors. The proceedings of MSFP 2006 will be published in the Electronic Workshops in Computing (eWiC) series of the British Computer Society, http://ewic.bcs.org/. After the workshop, the authors of the best papers will be invited to submit revised and expanded versions to a special issue of the Journal of Functional Programming from Cambridge University Press. Programme committee Yves Bertot, INRIA Sophia Antipolis Marcelo Fiore, University of Cambridge Masahito Hasegawa, Kyoto University Graham Hutton, University of Nottingham Paul Levy, University of Birmingham Andres Lh, Universitt Bonn Christoph Lth, Universitt Bremen Conor McBride, University of Nottingham (co-chair) Marino Miculan, Universit degli Studi di Udine Randy Pollack, University of Edinburgh Amr Sabry, Indiana University Tarmo Uustalu, Institute of Cybernetics (co-chair) Main conferences MSFP 2006 is a satellite workshop of the 8th International Conference on Mathematics on Program Construction, MPC 2006, to take place 3-5 July. Co-located with MPC 2006, the 11th International Conference on Algebraic Methodology and Software Technology, AMAST 2006, will follow 5-8 July. Venue Kuressaare (pop. 16000) is the main town on Saaremaa, the second-largest island of the Baltic Sea. Kuressaare is a charming seaside resort on the shores of the Gulf of Riga highly popular with Estonians as well as visitors to Estonia. The scientific sessions of MPC/AMAST 2006 will take place at Saaremaa Spa Hotel Meri, one among the several new spa hotels in the town. The social events will involve a number of sites, including the 14th-century episcopal castle. Accommodation will be at Saaremaa Spa Hotels Meri and Rtli. To get to Kuressaare and away, one must pass through Tallinn (pop. 402000), Estonia's capital city. Tallinn is famous for its picturesque medieval Old Town, inscribed on UNESCO's World Heritage List. TYPES support MSFP 2006 is an official workshop of the EU FP6 IST coordination action TYPES. Participants from TYPES sites/subsites may use project funds to cover their travel and participation. Local organizers MPC/AMAST 2006 is organized by Institute of Cybernetics, a research institute of Tallinn University of Technology. The local organizers are Tarmo Uustalu (chair), Monika Perkmann, Juhan Ernits, Ando Saabas, Olha Shkaravska, Kristi Uustalu. Contact email address of the local organizers: mpc06(at)cs.ioc.ee. 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. From adamc at !NS! cs.berkeley.edu Thu Mar 23 16:49:31 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Thu, 23 Mar 2006 08:49:31 -0800 Subject: [Coq-Club]Seeking help on Coq In-Reply-To: <20060317032929.44825.qmail@web53715.mail.yahoo.com> References: <20060317032929.44825.qmail@web53715.mail.yahoo.com> Message-ID: <4422D19B.70005@cs.berkeley.edu> Israt Jahan wrote: > Inductive known_in : C -> SD -> Prop := > E0 : (c1 c2 : C) (s :SD) (known_in c1 s) -> (known_in c1 (cons C c2 s)) > > Here, I have declared C as Set, SD is defined as (list C). While > compiling this line in Coq, it declares that c2 is defined as type C > but it must be of type listSet. The first argument of 'cons' is an implicit argument. Simply leave it out and your example should work fine. Israt Jahan wrote: > When I write ' Require Import securite', then after compilation, > the answer is securite library is not found on the load path. Sir, my > question is whether securite library exists in coq version 8.0. I've never heard of that library. You can check what's in the standard library here: http://coq.inria.fr/library-eng.html As a meta-point, I suggest giving future messages to this mailing list more descriptive titles, related to the actual problems you are facing. From c0107040 at !NS! alunos.dcc.fc.up.pt Tue Mar 28 11:53:43 2006 From: c0107040 at !NS! alunos.dcc.fc.up.pt (Ricardo Sousa) Date: Tue, 28 Mar 2006 11:53:43 +0100 Subject: [Coq-Club]Wrong answer Exercise 6.29 of the book Message-ID: <442915B7.6090201@alunos.dcc.fc.up.pt> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEF242DF88EE951FF8A71E4A0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi. In the exercise 6.29, where i can only use certain rules to prove "Theorem plus_n_O : forall n, n+0 =3Dn.", there is a problem in the given= solution (http://www.labri.fr/perso/casteran/CoqArt/structinduct/SRC/plus_n_O.v) on the application step. Open Scope nat_scope. Theorem plus_n_O : forall n, n+0 =3Dn. Proof. intro n; elim n; simpl. reflexivity. intros n0 e. apply eq_ind with (P:=3D fun n =3D> S(n0 + 0) =3D S n) (x:=3D n0 + 0). reflexivity. assumption. Qed. I can't find why this doesn't work. I also don't understand in which step of the unification this error corresponds. Is in the app rule? Or is in other? Toplevel input, characters 260-324 > apply eq_ind with (P:=3D fun n1 =3D> S (n0 + 0) =3D S n1)(x:=3D (n0 +0)= ). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error: Impossible to unify "S (n0 + 0) =3D S ?29" with "S n0 =3D S n0 + 0= " Thank you in advance, Ricardo Sousa --------------enigEF242DF88EE951FF8A71E4A0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKRW717b9iF3Oh0cRAnl1AJ9LY/YxM0qyxwOBsSoJ3ZizZvYK2wCfSzj6 k4rJJyh8wtJADkLdDxQuWMM= =49dq -----END PGP SIGNATURE----- --------------enigEF242DF88EE951FF8A71E4A0-- From fdc at !NS! cage.ugent.be Thu Mar 23 23:00:34 2006 From: fdc at !NS! cage.ugent.be (Frank De Clerck) Date: Fri, 24 Mar 2006 00:00:34 +0100 Subject: [Coq-Club]vacancy for Professor in Mathematical Computer Science at Ghent University Message-ID: <44232892.8050003@cage.ugent.be> This is a multi-part message in MIME format. --------------040103020202010906060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear colleague (sorry if you receive this message in duplicate) The Faculty of Sciences at Ghent University (Belgium) has a vacancy for a professorship in mathematical computer science, starting from October 1, 2006. It concerns a job as full-time professor in the rank of lecturer (docent) or senior lecturer (hoofddocent) in the Department of Pure Mathematics and Computer Algebra, charged with academic teaching (in Dutch), scientific research and carrying out scientific duties in the field of mathematical computer science, preferably in one of the following areas: - formal methods and computer-supported proving; - formal methods for software safety and software quality. Deadline for application is April 18. For more details see http://aivwww.ugent.be/DPO/vacatures/ZAP/WE01eng.html Frank De Clerck Deputy Head of the Department of Pure Mathematics and Computer Algebra. --------------040103020202010906060405 Content-Type: text/x-vcard; charset=utf-8; name="fdc.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fdc.vcf" begin:vcard fn:Frank De Clerck n:De Clerck;Frank org:Ghent University;Department of Pure Mathematics and Computer Algebra adr:;;Krijgslaan 281 - S22;Gent;;9000;Belgium email;internet:http://cage.ugent.be/~fdc tel;work:+32 (0)92644918 tel;fax:+32 (0)92644993 tel;home:+32 (0)92303077 tel;cell:+32 (0)486362231 x-mozilla-html:TRUE url:http://cage.ugent.be/~fdc version:2.1 end:vcard --------------040103020202010906060405-- From pierre.casteran at !NS! labri.fr Tue Mar 28 15:23:57 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Tue, 28 Mar 2006 16:23:57 +0200 Subject: [Coq-Club]Wrong answer Exercise 6.29 of the book In-Reply-To: <442915B7.6090201@alunos.dcc.fc.up.pt> References: <442915B7.6090201@alunos.dcc.fc.up.pt> Message-ID: <1143555837.442946fd2ed95@iona.labri.fr> Selon Ricardo Sousa : Hi, I tried again this solution with coqV8 (pl3) and found no problem. Could you send me a script of the session? Pierre > Hi. > In the exercise 6.29, where i can only use certain rules to prove > "Theorem plus_n_O : forall n, n+0 =n.", there is a problem in the given > solution > (http://www.labri.fr/perso/casteran/CoqArt/structinduct/SRC/plus_n_O.v) > on the application step. > > Open Scope nat_scope. > > Theorem plus_n_O : forall n, n+0 =n. > Proof. > intro n; elim n; simpl. > reflexivity. > intros n0 e. > apply eq_ind with (P:= fun n => S(n0 + 0) = S n) (x:= n0 + 0). > reflexivity. > assumption. > Qed. > > I can't find why this doesn't work. > I also don't understand in which step of the unification this error > corresponds. Is in the app rule? Or is in other? > > Toplevel input, characters 260-324 > > apply eq_ind with (P:= fun n1 => S (n0 + 0) = S n1)(x:= (n0 +0)). > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Error: Impossible to unify "S (n0 + 0) = S ?29" with "S n0 = S n0 + 0" > > Thank you in advance, > Ricardo Sousa > > > > -- Pierre Casteran http://www.labri.fr/Perso/~casteran/ (+33) 540006931 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From c0107040 at !NS! alunos.dcc.fc.up.pt Tue Mar 28 21:24:23 2006 From: c0107040 at !NS! alunos.dcc.fc.up.pt (Ricardo Sousa) Date: Tue, 28 Mar 2006 21:24:23 +0100 Subject: [Coq-Club]Wrong answer Exercise 6.29 of the book In-Reply-To: <1143555837.442946fd2ed95@iona.labri.fr> References: <442915B7.6090201@alunos.dcc.fc.up.pt> <1143555837.442946fd2ed95@iona.labri.fr> Message-ID: <44299B77.8070808@alunos.dcc.fc.up.pt> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDDAFD75BC2E3AB2FA140838F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My apologies. Was my mistake transcribing the question of the exercise. nat do the difference :) Once again, thank you. Ricardo Sousa Pierre Casteran wrote: > Selon Ricardo Sousa : >=20 >=20 > Hi, > I tried again this solution with coqV8 (pl3) and found no problem. >=20 > Could you send me a script of the session? >=20 > Pierre >=20 >=20 >=20 >=20 >=20 >> Hi. >> In the exercise 6.29, where i can only use certain rules to prove >> "Theorem plus_n_O : forall n, n+0 =3Dn.", there is a problem in the gi= ven >> solution >> (http://www.labri.fr/perso/casteran/CoqArt/structinduct/SRC/plus_n_O.v= ) >> on the application step. >> >> Open Scope nat_scope. >> >> Theorem plus_n_O : forall n, n+0 =3Dn. >> Proof. >> intro n; elim n; simpl. >> reflexivity. >> intros n0 e. >> apply eq_ind with (P:=3D fun n =3D> S(n0 + 0) =3D S n) (x:=3D n0 + 0)= =2E >> reflexivity. >> assumption. >> Qed. >> >> I can't find why this doesn't work. >> I also don't understand in which step of the unification this error >> corresponds. Is in the app rule? Or is in other? >> >> Toplevel input, characters 260-324 >>> apply eq_ind with (P:=3D fun n1 =3D> S (n0 + 0) =3D S n1)(x:=3D (n0 += 0)). >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Error: Impossible to unify "S (n0 + 0) =3D S ?29" with "S n0 =3D S n0 = + 0" >> >> Thank you in advance, >> Ricardo Sousa >> >> >> >> >=20 >=20 --------------enigDDAFD75BC2E3AB2FA140838F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKZt/17b9iF3Oh0cRAskcAJ9Ix/sjK03XOHlSSdYmezWF/H4aPwCcCB88 s/+jj2gEbm0vjHSm9KLKA4c= =51ln -----END PGP SIGNATURE----- --------------enigDDAFD75BC2E3AB2FA140838F-- From pierre.casteran at !NS! labri.fr Wed Mar 29 15:00:07 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Wed, 29 Mar 2006 16:00:07 +0200 Subject: [Coq-Club]dependent conjunction ????? Message-ID: <442A92E7.2050608@labri.fr> Hello, Is there already in Coq something like the following and_dep ? Pierre Inductive and_dep (P : Prop)(Q : P -> Prop) :Prop := conj_dep : forall (p:P), Q p -> and_dep P Q. Set Implicit Arguments. Require Import Ensembles. Parameters (OT : Type) (ordinal : Ensemble OT) (critical : forall alpha : OT, ordinal alpha -> Ensemble OT). (* I prefer to write (Cr alpha) than (Cr H) where H assumes (ordinal alpha) *) Definition Cr (alpha : OT) : Ensemble OT := fun beta => and_dep (ordinal alpha) (fun H => (critical H beta)). From levy at !NS! iiia.csic.es Thu Mar 30 11:46:19 2006 From: levy at !NS! iiia.csic.es (Jordi Levy) Date: Thu, 30 Mar 2006 12:46:19 +0200 (CEST) Subject: [Coq-Club]UNIF'06 first call for papers Message-ID: <20060330104619.2F932226EF8@gollum.iiia.csic.es> [Apologies if you receive multiple copies] ************************************* * * * UNIF'06 FIRST CALL FOR PAPERS * * * * Deadline: May 29, 2006 * * * ************************************* UNIF'06 20th Int. Workshop on Unification A satellite workshop of RTA'6 and FLoC'06 The Seattle Sheraton Hotel and Towers Seattle, WA, USA August 11, 2006 http://www.iiia.csic.es/~levy/unif06.html UNIF is the main international meeting on unification. Unification is concerned with the problem of identifying given terms, either syntactically or modulo a given logical theory. Syntactic unification is the basic operation of most automated reasoning systems, and unification modulo theories can be used, for instance, to build in special equational theories into theorem provers. The aim of UNIF 2006, as that of the previous meetings, is to to bring together people interested in unification, present recent (even unfinished) work, and discuss new ideas and trends in unification and related fields. This includes scientific presentations, but also descriptions of applications and softwares using unification as a strong component. In 2006, UNIF has been organized as part of the 2006 Federated Logic Conference (FLoC 2006). This workshop is the twentieth in the series: UNIF'87 (Val D'Ajol, France), UNIF'88 (Val D'Ajol, France), UNIF'89 (Lambrecht, Germany), UNIF'90 (Leeds, England), UNIF'91 (Barbizon, France), UNIF'92 (Dagstuhl, Germany), UNIF'93 (Boston, USA), UNIF'94 (Val D'Ajol, France), UNIF'95 (Sitges, Spain), UNIF'96 (Herrsching, Germany), UNIF'97 (Orl%/1€Œiso8859-15éans, France), UNIF'98 (Rome, Italy), UNIF'99 (Frankfurt, Germany), UNIF'00 (Pittsburgh, USA), UNIF'01 (Siena, Italy), UNIF'02 (Copenhagen, Denmark). UNIF'03 (Valencia, Spain). UNIF'04 (Cork, Ireland). UNIF'05 (Nara, Japan). ------------------------------------------------------------------------------- Topics of Interest: The meeting will include invited talks, contributed talks, and social time to discuss current topics of interest, which include (but are not limited to): * Unification o E-unification o Unification Algorithms o Higher-Order Unification o String Unification o Context Unification o Nominal Unification o Combination problems o Disunification o Typed Unification * Related Topics o Constraint Solving o Tree Descriptions o Matching o Narrowing * Applications o Type Checking and Type Inference o Automated Deduction o Rewriting o Functional and Logic Programming o Grammars o Computational Linguistics * Implementations ------------------------------------------------------------------------------- Important Dates: May 29, 2006 Deadline for submission of papers, abstracts and system descriptions June 19, 2006 Notification of acceptance July 17, 2006 Camera-ready papers August 11 , 2006 Workshop ------------------------------------------------------------------------------- Program Committee: Temur Kutsia Research Institute for Symbolic Computation Johannes Kepler University of Linz, Linz, Austria Jordi Levy (chair) Institut d'Investigació en Intel.ligència Artificial (IIIA) Consejo Superior de Investigaciones Científicas (CSIC), Barcelona, Spain Christian Urban Mathematisches Institut der LMU Munchen, Germany Mateu Villaret Dept. Informàtica i Matemàtica Aplicada (IMA) Universitat de Girona (UdG), Girona, Spain ------------------------------------------------------------------------------- Submission: Authors are invited to submit via email an abstract (1-5 pages), a paper (no longer than 15 pages), or a system description (no more than 5 pages) in Postscript or PDF format using the UNIF'06 submission page, handled by the EasyChair conference system: http://www.easychair.org/UNIF06/ Authors have been encouraged to use LaTeX2e and the Springer llncs class files. Publication Informal proceedings of accepted contributions will be available on-line. A hard copy will be distributed at the workshop to registered participants. From admin at !NS! satrajit.com Sun Apr 2 05:03:38 2006 From: admin at !NS! satrajit.com (Satrajit Roy) Date: Sat, 1 Apr 2006 20:03:38 -0800 (PST) Subject: [Coq-Club]Inheritance in Coq? Message-ID: <20060402040338.79617.qmail@web407.biz.mail.mud.yahoo.com> --0-191950703-1143950618=:79396 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I'm new to Coq. How can I define something like the following in Coq: Inductive kind:Set:= | x | y | z. Inductive xKind:kind:=|x'|x''|..|x''''. Inductive yKind:kind:=|y'|y''|..|y''''. Inductive zKind:kind:=|z'|z''|..|z''''. FixPoint funcKind (k:kind) (...) .. {struct k} : kind := match k with | x => some recursive term using xKind | y => some recursive term using yKind | z => some recursive term using zKind end. I know the above is syntactically wrong. But I hope I got my intention across. Is the above even possible? Thanks in anticipation. --0-191950703-1143950618=:79396 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I'm new to Coq. How can I define something like the following in Coq:

Inductive kind:Set:= | x | y | z.

Inductive xKind:kind:=|x'|x''|..|x''''.
Inductive yKind:kind:=|y'|y''|..|y''''.
Inductive zKind:kind:=|z'|z''|..|z''''.

FixPoint funcKind (k:kind) (...) .. {struct k} : kind := match k with
| x => some recursive term using xKind
| y => some recursive term using yKind
| z => some recursive term using zKind
end.

I know the above is syntactically wrong. But I hope I got my intention across.
Is the above even possible?

Thanks in anticipation.

--0-191950703-1143950618=:79396-- From jean-francois.monin at !NS! imag.fr Mon Apr 3 11:48:00 2006 From: jean-francois.monin at !NS! imag.fr (jean-francois.monin@imag.fr) Date: Mon, 3 Apr 2006 12:48:00 +0200 Subject: [Coq-Club]Inheritance in Coq? In-Reply-To: <20060402040338.79617.qmail@web407.biz.mail.mud.yahoo.com> References: <20060402040338.79617.qmail@web407.biz.mail.mud.yahoo.com> Message-ID: <17456.64864.340969.226242@girose.imag.fr> Hello, If you mean "some recursive term of type xKind" etc. instead of "some recursive term using xKind", yes. This is not inheritance but dependent types. You need a function such as Definition kind_of k := match k with | x => xKind | y => yKind | z => zKind end. Then the body of your fixpoint is something like this: match k return kind_of k with | x => something of type xKind | y => something of type yKind | z => something of type zKind end. Hope this helps, JF Satrajit Roy a ecrit : > I'm new to Coq. How can I define something like the following in Coq: > > Inductive kind:Set:= | x | y | z. > > Inductive xKind:kind:=|x'|x''|..|x''''. > Inductive yKind:kind:=|y'|y''|..|y''''. > Inductive zKind:kind:=|z'|z''|..|z''''. > > FixPoint funcKind (k:kind) (...) .. {struct k} : kind := match k with > | x => some recursive term using xKind > | y => some recursive term using yKind > | z => some recursive term using zKind > end. > > I know the above is syntactically wrong. But I hope I got my intention across. > Is the above even possible? > > Thanks in anticipation. -- Jean-François Monin Univ. Joseph Fourier, GRENOBLE VERIMAG - Centre Equation http://www-verimag.imag.fr/~monin/ 2 avenue de Vignate tel (+33 | 0) 4 56 52 03 72 F-38610 GIERES fax (+33 | 0) 4 56 52 03 44 From adam.koprowski at !NS! gmail.com Mon Apr 10 14:03:32 2006 From: adam.koprowski at !NS! gmail.com (Adam Koprowski) Date: Mon, 10 Apr 2006 15:03:32 +0200 Subject: [Coq-Club]Equality problem. Message-ID: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> ------=_Part_3778_18032377.1144674212202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello everybody, During my work in Coq I encountered something that looks rather as an elementary problem but I got stucked on it nevertheless. Here is the relevant snippet: Variable A: Set. Inductive Test: Set :=3D | Elem: A -> Test | Pair: Test -> Test -> Test. Fact discr: forall a b, ~a =3D Pair a b. Proof. ? How can one prove discr? I tried all varations of discriminate, injection etc. I could think of. Or is this equality not valid intuitionistically? An= y indications why? Any help appreciated! Adam Koprowski -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Adam.Koprowski@gmail.com, ICQ: 3204612 http://www.win.tue.nl/~akoprows The difference between impossible and possible lies in determination (Tommy Lasorda) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D ------=_Part_3778_18032377.1144674212202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello everybody,

During my work in Coq I encountered something that looks rather as an elementary problem but I got stucked on it nevertheless. Here is the relevant snippet:

Variable A: Set.
Inductive Test: Set :=3D
| Elem: A -> Test
| Pair: Test -> Test -> Test.

Fact discr: forall a b, ~a =3D Pair a b.
Proof. ?

How can one prove discr? I tried all varations of discriminate, injection etc. I could think of. Or is this equality not valid intuitionistically? Any indications why? Any help appreciated!

Adam Koprowski

--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Adam.Koprowski@gmail.com, ICQ: 3204612=
http://www.win.tue.nl/~akoprows
The difference between impossible an= d possible
lies in determination (Tommy Lasorda)
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------=_Part_3778_18032377.1144674212202-- From roconnor at !NS! theorem.ca Mon Apr 10 14:26:31 2006 From: roconnor at !NS! theorem.ca (roconnor@theorem.ca) Date: Mon, 10 Apr 2006 09:26:31 -0400 (EDT) Subject: [Coq-Club]Equality problem. In-Reply-To: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> References: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> Message-ID: On Mon, 10 Apr 2006, Adam Koprowski wrote: > Variable A: Set. > Inductive Test: Set := > | Elem: A -> Test > | Pair: Test -> Test -> Test. > > Fact discr: forall a b, ~a = Pair a b. > Proof. ? I have the following Fact discr: forall a b, ~a = Pair a b. Proof. induction a; intros b H. discriminate H. inversion H. firstorder. Qed. Perhaps there is a nicer way. -- Russell O'Connor ``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.'' From Xavier.Leroy at !NS! inria.fr Mon Apr 10 14:26:49 2006 From: Xavier.Leroy at !NS! inria.fr (Xavier Leroy) Date: Mon, 10 Apr 2006 15:26:49 +0200 Subject: [Coq-Club]Equality problem. In-Reply-To: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> References: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> Message-ID: <443A5D19.2030704@inria.fr> > During my work in Coq I encountered something that looks rather as an > elementary problem but I got stucked on it nevertheless. Here is the > relevant snippet: > > Variable A: Set. > Inductive Test: Set := > | Elem: A -> Test > | Pair: Test -> Test -> Test. > > Fact discr: forall a b, ~a = Pair a b. > Proof. ? > > How can one prove discr? By induction over a, followed by equality-related tactics (I'm quite fond of "congruence" myself). > I tried all varations of discriminate, > injection etc. I could think of. Or is this equality not valid > intuitionistically? It is, but only because your type Test is inductive (all values of type Test are finite trees): if it were coinductive, you could construct an a such that a = Pair a b. So, it is not surprising that you need to use induction to prove a property that depends crucially on the inductive nature of your data type. Hope this helps, - Xavier Leroy From andrew.mccreight at !NS! yale.edu Mon Apr 10 14:28:31 2006 From: andrew.mccreight at !NS! yale.edu (Andrew McCreight) Date: Mon, 10 Apr 2006 09:28:31 -0400 (EDT) Subject: [Coq-Club]Equality problem. In-Reply-To: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> References: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> Message-ID: You can prove it by induction: Fact discr: forall a b, ~a = Pair a b. Proof. intros a b. induction a. discriminate. intro Z; injection Z; clear Z; intros H1 H2. subst a2. apply IHa1. assumption. Qed. On Mon, 10 Apr 2006, Adam Koprowski wrote: > Hello everybody, > > During my work in Coq I encountered something that looks rather as an > elementary problem but I got stucked on it nevertheless. Here is the > relevant snippet: > > Variable A: Set. > Inductive Test: Set := > | Elem: A -> Test > | Pair: Test -> Test -> Test. > > Fact discr: forall a b, ~a = Pair a b. > Proof. ? > > How can one prove discr? I tried all varations of discriminate, injection > etc. I could think of. Or is this equality not valid intuitionistically? Any > indications why? Any help appreciated! > > Adam Koprowski > > -- > ===================================================== > Adam.Koprowski@gmail.com, ICQ: 3204612 > http://www.win.tue.nl/~akoprows > The difference between impossible and possible > lies in determination (Tommy Lasorda) > ===================================================== > From notin at !NS! lix.polytechnique.fr Mon Apr 10 14:32:32 2006 From: notin at !NS! lix.polytechnique.fr (Jean-Marc Notin) Date: Mon, 10 Apr 2006 15:32:32 +0200 Subject: [Coq-Club]Equality problem. In-Reply-To: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> References: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> Message-ID: <1144675952.2761.7.camel@surcouf.polytechnique.fr> --=-6j3sjzz2TzpKJojxN+cA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le lundi 10 avril 2006 =E0 15:03 +0200, Adam Koprowski a =E9crit : >=20 > Hello everybody, >=20 > During my work in Coq I encountered something that looks rather as an > elementary problem but I got stucked on it nevertheless. Here is the > relevant snippet: >=20 > Variable A: Set. > Inductive Test: Set :=3D > | Elem: A -> Test > | Pair: Test -> Test -> Test. >=20 > Fact discr: forall a b, ~a =3D Pair a b. > Proof. ? >=20 > How can one prove discr? I tried all varations of discriminate, > injection etc. I could think of. Or is this equality not valid > intuitionistically? Any indications why? Any help appreciated! >=20 There may be simpler ways for this, but you can use the inversion tactic: Fact discr: forall a b, ~a =3D Pair a b. Proof. unfold not; intros a b; induction a as [x|x IHx y IHy]; inversion 1 as [H']. rewrite H0 in H'; contradiction. Qed. --=20 Jean-Marc Notin LIX --=-6j3sjzz2TzpKJojxN+cA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEOl5wH4FxxOSsTdMRAjD7AJ9Iv18W6kkfy4eXQhEep7wV5AjRAQCfeBhK XAV6vV/4/+hjeTgz2wfQ8MA= =lyVT -----END PGP SIGNATURE----- --=-6j3sjzz2TzpKJojxN+cA-- From ctm at !NS! cs.nott.ac.uk Mon Apr 10 14:49:28 2006 From: ctm at !NS! cs.nott.ac.uk (Conor McBride) Date: Mon, 10 Apr 2006 14:49:28 +0100 Subject: [Coq-Club]Equality problem. In-Reply-To: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> References: <76f16cd50604100603t3c15bf98s9374bca58af5af3a@mail.gmail.com> Message-ID: <443A6268.3020508@cs.nott.ac.uk> Hi all Adam Koprowski wrote: > > Hello everybody, > > During my work in Coq I encountered something that looks rather as an > elementary problem but I got stucked on it nevertheless. Here is the > relevant snippet: > > Variable A: Set. > Inductive Test: Set := > | Elem: A -> Test > | Pair: Test -> Test -> Test. > > Fact discr: forall a b, ~a = Pair a b. > Proof. ? > > How can one prove discr? I tried all varations of discriminate, > injection etc. I could think of. Or is this equality not valid > intuitionistically? Any indications why? Any help appreciated! If this is a one-off problem, then some sort of induction will do nicely. If you want to do this sort of thing a lot, and especially if your cycle length gets longer than 1, eg disproving a = Pair b (Pair a c), you can prove a once-per-datatype 'no cycles' theorem following the scheme in 'A Few Constructions on Constructors' by myself, Healf Goguen and James McKinna, in proceedings of TYPES 2004. Basically, the idea is that given some x = t, compute the tuple of proofs that x is not equal to any of the constructor-guarded subterms of t. In your case, given the above, you would get a tuple containing 'a is not a', which is quite useful. Hope this helps Conor 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. From urbanc at !NS! in.tum.de Wed Apr 12 12:46:20 2006 From: urbanc at !NS! in.tum.de (Christian Urban) Date: Wed, 12 Apr 2006 13:46:20 +0200 Subject: [Coq-Club]Open position for a postdoctoral researcher at the TU Munich Message-ID: <20060412114622.5DCF1C0017@talisker.in.tum.de> Apologies for multiple postings. Please bring this announcement to the attention of anyone who might be interested. Postdoctoral researcher in the Nominal Methods Group at the TU Munich We have an open position for a postdoctoral researcher in the newly formed nominal methods group at the TU Munich. The research of our group is centered around the nominal datatype package. This package pushes the state of the art of formalising programming languages and solving POPLmark-like problems without having to resort to using de-Bruijn indices and higher-order abstract syntax. More information about the group can be found under http://www4.in.tum.de/~urbanc/Nominal/ The work we are interested in is both theoretical and practical, in the sense of implementing the tools we design. An ideal candidate for the position has therefore experience with formalisations and theorem provers as well as with functional programming. The research themes for the position are broad including developing novel features of Isabelle, advancing the nominal logic theory and conducting case-studies using our tools. We offer an active and friendly research environment in the Isabelle group in Munich. We have close ties with many international researchers working on the POPLmark Challenge. Munich is Germany's most attractive city - the Alps are very close and local beer and merrymaking are not frowned upon in Bavaria. The appointment is for two years initially with possible extensions. The position is open from September 2006, but slightly earlier or later starting dates can also be considered. Remuneration will be in accordance with the German Scale BAT-IIa for researchers. The salary depends on age and family circumstances; typical numbers are 2980 Euros per month for a single 25 year old rising to 3200 Euros per month for a single 30 year old. Informal inquiries about the position may be send to urbanc@in.tum.de. Send applications no later than 26th of May 2006. To apply send your application (preferably electronically) including a CV, publication list, contact details of 2 referees and a statement of research to urbanc@in.tum.de or Dr Christian Urban Institute for Computer Science I4 TU Munich, Boltzmannstr. 3, D-85748 Garching, Germany. From vladimir at !NS! ias.edu Fri Apr 14 18:06:31 2006 From: vladimir at !NS! ias.edu (Vladimir Voevodsky) Date: Fri, 14 Apr 2006 13:06:31 -0400 Subject: [Coq-Club]a type equality question Message-ID: Are any one of the following two opposite statements provable in Coq (with or without the boolean assumption): 1. there exist types A, B, C such that A->(B->C) is not equal to B-> (A->C) 2. for all A, B, C one has A->(B->C) = B->(A->C) If neither one is provable can one prove (outside of coq) that both are not provable? Vladimir. From femke at !NS! cs.vu.nl Tue Apr 18 09:12:17 2006 From: femke at !NS! cs.vu.nl (Femke van Raamsdonk) Date: Tue, 18 Apr 2006 10:12:17 +0200 (CEST) Subject: [Coq-Club]HOR 2006: last call for abstracts Message-ID: ******************************** * * * HOR'06 CALL FOR ABSTRACTS * * * ******************************** 3rd International Workshop on Higher-Order Rewriting Tuesday August 15, 2006 Sheraton, Seattle, WA http://hor.pps.jussieu.fr/06 IMPORTANT DATES: May 8, 2006 : deadline electronic submission of paper May 29, 2006 : notification of acceptance of papers June 8, 2006 : deadline for final version of accepted papers The aim of HOR is to provide an informal and friendly setting to discuss recent work and work in progress concerning higher-order rewriting. HOR 2002 was part of FLoC 2002 in Copenhagen, Denmark. HOR 2004 was part of RDP 2004 in Aachen, Germany. HOR 2006 will be part of FLoC 2006 in Seattle, USA. INVITED TALKS: Hugo Herbelin (INRIA Futurs, Paris) Eelco Visser (Universiteit Utrecht, The Netherlands) TOPICS of interest include (but are not limited to): APPLICATIONS: proof checking, theorem proving, generic programming, declarative programming, program transformation. FOUNDATIONS: pattern matching, unification, strategies, narrowing, termination, syntactic properties, type theory. FRAMEWORKS: term rewriting, conditional rewriting, graph rewriting, net rewriting, comparisons of different frameworks. IMPLEMENTATION: explicit substitution, rewriting tools, compilation techniques. SEMANTICS: semantics of higher-order rewriting, higher-order abstract syntax PROGRAM/ORGANIZING COMMITTEE: Delia Kesner Universite Paris 7, France kesner@pps.jussieu.fr Femke van Raamsdonk Vrije Universiteit, The Netherlands femke@cs.vu.nl Mark-Oliver Stehr SRI International, USA stehr@csl.sri.com HOR'06 SUBMISSIONS: Abstracts between 2 and 5 pages. As HOR is meant to be a platform to discuss ongoing research we are also interested in abstracts describing work in progress, or problems in higher-order rewriting. Please use the EasyChair page http://www.easychair.org/HOR06/ to submit or update your paper. PROCEEDINGS: The proceedings of HOR 2006 will be made available on the HOR 2006 web page and copies will be distributed to the participants at the workshop. LOCAL ARRANGEMENTS: Gopal Gupta University of Texas, Dallas, USA gupta@utdallas.edu Ashish Tiwari SRI International, USA tiwari@csl.sri.com From dam.ledoux at !NS! gmail.com Sun Apr 23 11:54:22 2006 From: dam.ledoux at !NS! gmail.com (Damien Ledoux) Date: Sun, 23 Apr 2006 12:54:22 +0200 Subject: [Coq-Club]=?iso-8859-15?Q?Probl=E8me_de_d=E9monstration_pas_induct?= =?iso-8859-15?Q?ion?= Message-ID: Bonjour, J'ai un petit problème avec la tactique elim. En effet quand je veux réaliser une démonstration par induction, elle me remplace directement le terme de mon induction dans mon lemme alors que j'aimerais l'avoir en hypothèse. Pour etre plus clair, j'ai fait un petit exemple montrant mon problème. Mon problème est la démonstration du lemme test. Je dois mal utiliser les tactiques ou bien faire une mauvaise induction. Si je ne me trompe pas il faut réaliser une induction sur "(N2nat n)" puis après sur "r". Merci d'avance pour votre aide, Damien (************** DEBUT *****************) Inductive N : Set := | base : N | next : N -> N. Implicit Types n : N. Fixpoint N2nat n : nat := match n with | base => O | next n' => S (N2nat n') end. Fixpoint succ_fix (n:nat) : nat := match n with | O => (S 0) | S n => S (succ_fix n) end. Definition succ (n:N) : nat := (N2nat n) + 1. Lemma test : forall (n : N) (r:nat), succ_fix (N2nat n) = r -> succ n = r. intro n. elim (N2nat n). (* CB : (N2nat n) *) simpl. (*************** FIN ******************) From Julien.Narboux at !NS! inria.fr Sun Apr 23 12:19:38 2006 From: Julien.Narboux at !NS! inria.fr (Julien Narboux) Date: Sun, 23 Apr 2006 13:19:38 +0200 Subject: [Coq-Club]Re: =?ISO-8859-15?Q?=5BCoq-Club=5DProbl=E8me_de_d=E9monstrat?= =?ISO-8859-15?Q?ion_pas_induction?= In-Reply-To: References: Message-ID: <444B62CA.1050503@inria.fr> Bonjour, Voici une solution, a priori r ne sert à rien et ce que tu prouves ne parle en fait que de nat et pas de N : Lemma test : forall (n : nat), succ_fix n = n + 1. Proof. induction n. reflexivity. simpl. rewrite IHn. reflexivity. Qed. Lemma test2 : forall (n : N) (r:nat), succ_fix (N2nat n) = r -> succ n = r. Proof. intros. rewrite test in H. assumption. Qed. Bonne journée. Julien Damien Ledoux a écrit : > Bonjour, > > J'ai un petit problème avec la tactique elim. > En effet quand je veux réaliser une démonstration par induction, > elle me remplace directement le terme de mon induction dans mon lemme > alors que j'aimerais l'avoir en hypothèse. > > Pour etre plus clair, j'ai fait un petit exemple montrant mon problème. > > Mon problème est la démonstration du lemme test. > Je dois mal utiliser les tactiques ou bien faire une mauvaise induction. > Si je ne me trompe pas il faut réaliser une induction sur "(N2nat n)" puis > après sur "r". > > > Merci d'avance pour votre aide, > Damien > > > (************** DEBUT *****************) > > Inductive N : Set := > | base : N > | next : N -> N. > > Implicit Types n : N. > > Fixpoint N2nat n : nat := > match n with > | base => O > | next n' => S (N2nat n') > end. > > > Fixpoint succ_fix (n:nat) : nat := > match n with > | O => (S 0) > | S n => S (succ_fix n) > end. > > Definition succ (n:N) : nat := (N2nat n) + 1. > > > Lemma test : > forall (n : N) (r:nat), succ_fix (N2nat n) = r -> succ n = r. > intro n. > elim (N2nat n). > > (* CB : (N2nat n) *) > simpl. > > (*************** FIN ******************) > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 mulhern at !NS! gmail.com Mon Apr 24 19:00:46 2006 From: mulhern at !NS! gmail.com (mulhern) Date: Mon, 24 Apr 2006 13:00:46 -0500 Subject: [Coq-Club]Question about refine tactic Message-ID: <54f15b6e0604241100g5458142aqc661dbebd1087b33@mail.gmail.com> Hi! Using the refine tactic and I got this error. User error: execute: found a non-instanciated goal Aren't non-instantiated goals exactly the things refine is supposed to allow? I tried giving the placeholders their correct types but got the same error message. I then filled in the placeholders with their correct values; luckily for these particular placeholders the correct value was easy. Does anybody have any suggestions as to what would cause refine to give this particular error? Thanks! -mulhern Here is the context of the offending underscores: (f_equal (fun e : term => match e with | TmTrue => _ | TmFalse => _ | TmIf _ t _ => t end) H3 ) H3 has type TmIf t1 t2 t3 = TmIf tm1 tm2 tm3. So the anonymous function above needs to have the underscores replaced with subterms of (TmIf t1 t2 t3) thus: (f_equal (fun e : term => match e with | TmTrue => t2 | TmFalse => t2 | TmIf _ t _ => t end) H3) From mulhern at !NS! gmail.com Tue Apr 25 02:08:01 2006 From: mulhern at !NS! gmail.com (mulhern) Date: Mon, 24 Apr 2006 20:08:01 -0500 Subject: [Coq-Club]Applying reduction rules to generated proofs Message-ID: <54f15b6e0604241808vf69ecf6wcfc9b0449a6c85cf@mail.gmail.com> Hi! Suppose I have developed a proof in the normal way. Theorem name : . Proof. . Qed. I want to apply zeta reductions to the body of the proof once it has been generated. Currently the way I do this is: Print name. Then I copy the generated output and paste it into the command. Definition name_reduced := Eval cbv zeta in ( ). Is there any way to do this through Coq instead of by this cumbersome and not really scalable cut and paste method? I have tried Definition name_reduced := Eval cbv zeta in name. The problem with that is that I can't tell what the body of name_reduced consists of because I cannot Print it. When I use the Print command I just get name_reduced = name : goal My purpose in performing these reductions is to transform the proof to one that is more readily accepted by the refine tactic. -mulhern From Roland.Zumkeller at !NS! polytechnique.fr Tue Apr 25 07:13:50 2006 From: Roland.Zumkeller at !NS! polytechnique.fr (Roland Zumkeller) Date: Tue, 25 Apr 2006 08:13:50 +0200 Subject: [Coq-Club]Applying reduction rules to generated proofs In-Reply-To: <54f15b6e0604241808vf69ecf6wcfc9b0449a6c85cf@mail.gmail.com> References: <54f15b6e0604241808vf69ecf6wcfc9b0449a6c85cf@mail.gmail.com> Message-ID: <54B0AA9A-A744-46A6-AD20-9354F6D8638E@polytechnique.fr> I think you are looking for Eval cbv zeta delta[name] in name. On Apr 25, 2006, at 3:08 AM, mulhern wrote: > My purpose in performing these reductions is to transform the proof to > one that is more readily accepted by the refine tactic. Could you show us an example? Hope this helps, Roland -- http://www.lix.polytechnique.fr/~zumkeller/ From phil.andouard at !NS! gmail.com Tue Apr 25 08:51:49 2006 From: phil.andouard at !NS! gmail.com (Philippe Andouard) Date: Tue, 25 Apr 2006 09:51:49 +0200 Subject: [Coq-Club][Bvector] Message-ID: <14b4215a0604250051w4e050e2do37b3083eebb8846c@mail.gmail.com> Bonjour, J'aimerais pouvoir simuler le fonctionnement d'un octet. J'ai vu que la librairie standard de Coq proposait des vecteurs de bits au travers du module Bvector. Mon problème est le suivant, je voudrais convertir un entier en base dix en sa représentation en base deux et le stocker dans un vecteur de bits. Par exemple si on considère l'entier 15 je voudrais pouvoir stoker [0 0 0 0 1 1 1 1] dans mon vecteur. J'arrive à déclarer des Bvector mais je n'arrive pas à stocker quoi que ce soit dedans. Quelqu'un saurait-il comment stocker des valeurs dans des vecteurs? From jasper at !NS! cs.ru.nl Wed Apr 19 11:21:10 2006 From: jasper at !NS! cs.ru.nl (Jasper Stein) Date: Wed, 19 Apr 2006 12:21:10 +0200 Subject: [Coq-Club]Reals theory Message-ID: <200604191221.10490.jasper@cs.ru.nl> Dear Coq-club, I have a question regarding the theory Reals from the standard library. I would contact the author but I can't find out who it is, hence I send this to this list. In the file Coq/Reals/Raxioms.v an injection is defined from nat to R, as follows: Fixpoint INR (n:nat) : R := match n with | O => 0 | S O => 1 | S n => INR n + 1 end. It seems a bit strange to have a separate clause for S O - it can be proved that a function inR, defined without this clause, is extensionally equal to INR, and indeed "auto with real" cannot solve some subgoals that it /can/ prove using inR. So - is there a reason to define INR this way? Groeten, -- Jasper Stein From duprat at !NS! ens-lyon.fr Mon Apr 24 09:13:35 2006 From: duprat at !NS! ens-lyon.fr (Jean.Duprat) Date: Mon, 24 Apr 2006 10:13:35 +0200 Subject: [Coq-Club]Re: =?ISO-8859-15?Q?=5BCoq-Club=5DProbl=E8me_de_d=E9monstrat?= =?ISO-8859-15?Q?ion_pas_induction?= In-Reply-To: References: Message-ID: <444C88AF.6060306@ens-lyon.fr> Bonjour, En choisissant de faire l'elimination sur (N2nat n) les valeurs de n ne sont pas reportees dans l'expression succ n, d'ou l'echec de ta demonstration. Si tu tiens a "elim (N2nat n).", je te suggere la demonstration suivante : unfold succ in |- *; intro n. elim (N2nat n); simpl in |- *; intros. trivial. rewrite <- H0; apply f_equal with (f := S). apply H; trivial. Mais je te conseille de choisir plutot les variables dont le type est un inductif pour faire une elimination, ici n. Ce qui donne par exemple : unfold succ in |- *; induction n; simpl in |- *; intros. trivial. rewrite (IHn (succ_fix (N2nat n))); auto. Amities Jean Duprat Damien Ledoux wrote: > Bonjour, > > J'ai un petit problème avec la tactique elim. > En effet quand je veux réaliser une démonstration par induction, > elle me remplace directement le terme de mon induction dans mon lemme > alors que j'aimerais l'avoir en hypothèse. > > Pour etre plus clair, j'ai fait un petit exemple montrant mon problème. > > Mon problème est la démonstration du lemme test. > Je dois mal utiliser les tactiques ou bien faire une mauvaise induction. > Si je ne me trompe pas il faut réaliser une induction sur "(N2nat n)" > puis > après sur "r". > > > Merci d'avance pour votre aide, > Damien > > > (************** DEBUT *****************) > > Inductive N : Set := > | base : N > | next : N -> N. > > Implicit Types n : N. > > Fixpoint N2nat n : nat := > match n with > | base => O > | next n' => S (N2nat n') > end. > > > Fixpoint succ_fix (n:nat) : nat := > match n with > | O => (S 0) > | S n => S (succ_fix n) > end. > > Definition succ (n:N) : nat := (N2nat n) + 1. > > > Lemma test : > forall (n : N) (r:nat), succ_fix (N2nat n) = r -> succ n = r. > intro n. > elim (N2nat n). > > (* CB : (N2nat n) *) > simpl. > > (*************** FIN ******************) > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 Pierre.Courtieu at !NS! cnam.fr Mon Apr 24 11:31:31 2006 From: Pierre.Courtieu at !NS! cnam.fr (Pierre Courtieu) Date: Mon, 24 Apr 2006 12:31:31 +0200 Subject: =?ISO-8859-15?Q?[Coq-Club]Probl=E8me?= de =?ISO-8859-15?Q?d?= =?ISO-8859-15?Q?=E9monstration?= pas induction In-Reply-To: References: Message-ID: <20060424123131.56684feb@centaur.cnam.fr> On Sun, 23 Apr 2006 12:54:22 +0200 "Damien Ledoux" wrote: > Bonjour, > > J'ai un petit problème avec la tactique elim. > En effet quand je veux réaliser une démonstration par induction, > elle me remplace directement le terme de mon induction dans mon lemme > alors que j'aimerais l'avoir en hypothèse. > > Pour etre plus clair, j'ai fait un petit exemple montrant mon problème. > > Mon problème est la démonstration du lemme test. > Je dois mal utiliser les tactiques ou bien faire une mauvaise induction. > Si je ne me trompe pas il faut réaliser une induction sur "(N2nat n)" puis > après sur "r". > > > Merci d'avance pour votre aide, > Damien Ceci n'est pas un bug, c'est le comportement normal de l'induction. Si vous voulez "garder" l'information du cas dans lequel vous vous trouvez, il faut créer une nouvelle variable égale à (N2nat n), sur laquelle vous ferez l'élimination: Lemma test : forall (n : N) (r:nat), succ_fix (N2nat n) = r -> succ n = r. intro n. set (X:=N2nat n). (* création de la variable X *) assert (hyp: N2nat n = X). (* création de l'égalité *) trivial. (* preuve de l'égalité*) generalize hyp. clear hyp. (* on met l'égalité dans le contexte *) elim X;clear X. (* on fait la récurrence sur la variable *) Ceci passe avec un coq plus récent que la V8.0, il se peut qu'il ne passe pas directement. Pierre Courtieu From ethan.aubin at !NS! gmail.com Mon Apr 17 21:02:54 2006 From: ethan.aubin at !NS! gmail.com (Ethan Aubin) Date: Mon, 17 Apr 2006 16:02:54 -0400 Subject: [Coq-Club]theorems from inductive type declarations Message-ID: <9760dc1c0604171302m6947b308y592c124b834c691@mail.gmail.com> Hi, I'm wondering if/how coq can be made to generate additional lemmas on a per inductive type basis. More specifically, I'd like to generate a 'fold-fusion' and 'fold-unfold' theorem from the datatype definition. Can anyone point me in the right direction? Thanks! - Ethan From pierre.casteran at !NS! labri.fr Tue Apr 25 09:48:47 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Tue, 25 Apr 2006 10:48:47 +0200 Subject: [Coq-Club][Bvector] In-Reply-To: <14b4215a0604250051w4e050e2do37b3083eebb8846c@mail.gmail.com> References: <14b4215a0604250051w4e050e2do37b3083eebb8846c@mail.gmail.com> Message-ID: <444DE26F.7010808@labri.fr> Philippe Andouard wrote: >Bonjour, > >J'aimerais pouvoir simuler le fonctionnement d'un octet. J'ai vu que >la librairie standard de Coq proposait des vecteurs de bits au travers >du module Bvector. > >Mon problème est le suivant, je voudrais convertir un entier en base >dix en sa représentation en base deux et le stocker dans un vecteur de >bits. Par exemple si on considère l'entier 15 je voudrais pouvoir >stoker [0 0 0 0 1 1 1 1] dans mon vecteur. >J'arrive à déclarer des Bvector mais je n'arrive pas à stocker quoi >que ce soit dedans. > >Quelqu'un saurait-il comment stocker des valeurs dans des vecteurs? > > The constructor Vcons can be used to store values in vectors. Require Import Bvector. About Vcons. Implicit Arguments Vcons [A n]. Check (Vcons true (Vcons false (Vcons true (Vcons true (Vnil bool))))). (* Vcons true (Vcons false (Vcons true (Vcons true (Vnil bool)))) : vector bool 4 *) Pierre >-------------------------------------------------------- >Bug reports: http://coq.inria.fr/bin/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 abbrugia at !NS! math.unice.fr Tue Apr 25 10:26:00 2006 From: abbrugia at !NS! math.unice.fr (Pierre.ABBRUGIATI) Date: Tue, 25 Apr 2006 11:26:00 +0200 Subject: [Coq-Club]Real functions In-Reply-To: <200604191221.10490.jasper@cs.ru.nl> References: <200604191221.10490.jasper@cs.ru.nl> Message-ID: <444DEB28.7050209@math.unice.fr> Dear Coq-Club, Apologies for my pityful english (french message following). Can one study the variations of of real function in Coq ? ie : can one prove that a real function is (strictly) monotonous on a given interval ? My problem is the following : I would like to prove the function x -> ln(x)/x is strictly decreasing on ]e,+infinity[. (maybe I need a stronger version of |negative_derivative| ? although I may not be able to prove that (ln(x)/x)' = (1-ln(x))/x^2... :'() Thanks a lot, Pierre Abbrugiati. ************************************************* Bonjour, Peut-on étudier les variations d'une fonction réelle en Coq ? C'est à dire : peut-on établir qu'une fonction réelle est (strictement) monotone sur un intervalle donné (autre que R) ? Mon exemple est le suivant : j'aimerais montrer que la fonction x -> ln(x)/x est strictement décroissante sur ]e, +infini[. (j'aurais donc peut-être besoin d'une version adaptée de |negative_derivative| ? ...quoique, a priori, je ne suis même pas capable de prouver que la dérivée de ma fonction est bien (1-ln(x))/x^2... :'() D'avance, merci beaucoup. Pierre Abbrugiati. From Pierre.Courtieu at !NS! cnam.fr Tue Apr 25 10:32:24 2006 From: Pierre.Courtieu at !NS! cnam.fr (Pierre Courtieu) Date: Tue, 25 Apr 2006 11:32:24 +0200 Subject: [Coq-Club]Applying reduction rules to generated proofs In-Reply-To: <54f15b6e0604241808vf69ecf6wcfc9b0449a6c85cf@mail.gmail.com> References: <54f15b6e0604241808vf69ecf6wcfc9b0449a6c85cf@mail.gmail.com> Message-ID: <20060425113224.43cd35eb@centaur.cnam.fr> On Mon, 24 Apr 2006 20:08:01 -0500 mulhern wrote: > Theorem name : . > Proof. > . > Qed. First if you want your proof term to be transparent (ie unfoldable), you have to finish your proof by "Defined" instead of Qed or Save. > Definition name_reduced := Eval cbv zeta in name. This is the right idea but you have to tell cbv to unfold names (delta reduction). You can try this first: Definition name_reduced := Eval cbv zeta delta in name. but this may give to much unfolding. You can focus the delta reduction by this: Definition name_reduced := Eval cbv zeta delta [name_reduced] in name. This should do the work. [..] can contain a space separated list of constant names. Hope this helps. Pierre Courtieu > > The problem with that is that I can't tell what the body of > name_reduced consists of because I cannot Print it. When I use the > Print command I just get > name_reduced > = > name : goal From mulhern at !NS! gmail.com Tue Apr 25 19:17:46 2006 From: mulhern at !NS! gmail.com (mulhern) Date: Tue, 25 Apr 2006 13:17:46 -0500 Subject: [Coq-Club]Re: Applying reduction rules to generated proofs In-Reply-To: <54f15b6e0604241808vf69ecf6wcfc9b0449a6c85cf@mail.gmail.com> References: <54f15b6e0604241808vf69ecf6wcfc9b0449a6c85cf@mail.gmail.com> Message-ID: <54f15b6e0604251117o176e79beu751e8785880575da@mail.gmail.com> Thanks all! The key points are: 1) Make sure the original theorem is transparent. 2) Perform a delta reduction on the constant corresponding to the original theorem in order to make the zeta reduced body visible. -mulhern On 4/24/06, mulhern wrote: > Hi! > > Suppose I have developed a proof in the normal way. > > Theorem name : . > Proof. > . > Qed. > > I want to apply zeta reductions to the body of the proof once it has > been generated. > > Currently the way I do this is: > > Print name. > > Then I copy the generated output and paste it into the command. > > Definition name_reduced := Eval cbv zeta in > ( > > ). > > Is there any way to do this through Coq instead of by this cumbersome > and not really scalable cut and paste method? > > I have tried > > Definition name_reduced := Eval cbv zeta in name. > > The problem with that is that I can't tell what the body of > name_reduced consists of because I cannot Print it. When I use the > Print command I just get > name_reduced > = > name : goal > > My purpose in performing these reductions is to transform the proof to > one that is more readily accepted by the refine tactic. > > -mulhern > From marche at !NS! lri.fr Wed Apr 26 14:09:53 2006 From: marche at !NS! lri.fr (Claude Marche) Date: Wed, 26 Apr 2006 15:09:53 +0200 Subject: [Coq-Club]CFP: Workshop on Verified Software: Theories, Tools, and Experiments (VSTTE 2006) Message-ID: <17487.28961.58508.254953@serveur9-10.lri.fr> Call for papers Workshop on Verified Software: Theories, Tools, and Experiments (VSTTE 2006) http://research.microsoft.com/~leino/vstte2006/ This one-day FLoC 2006 workshop on Verified Software continues the discussion initiated at the IFIP Working Conference on Verified Software in Zurich, Switzerland. Consisting of contributed papers and invited talks, the workshop will focus on the development of systematic methods for specifying, building, and verifying high-quality software. This includes topics like: * Program logic * Specification and verification techniques * Design methodologies * Automated verification tools * Tool integration * Achieving scale and automation in formal verification * Experimental studies * Benchmark applications and challenges * Tool and benchmark repositories The contributed papers, which should report on previously unpublished work, can reflect current and preliminary work in areas of software verification. New technical results, overviews of new developments in software verification projects, short papers accompanying tool demonstrations, as well as position papers on how to further advance the goal of verified software are all welcome. The papers can be up to 8 pages in length (in any reasonable format). Papers are submitted at http://www.easychair.org/VSTTE2006/. The workshop registration and submission process is open to everyone. Important dates * Submission deadline: 19 May 2006 * Notification of acceptance: 9 June 2006 * Final version due: 7 July 2006 * Day of workshop: 22 August 2006 Proceedings of the workshop will be published as a Microsoft Research technical report. Program committee * Marieke Huisman, INRIA Sophia Antipolis, France * K. Rustan M. Leino (co-chair), Microsoft Research, USA * Claude Marché, Université Paris-Sud, France * Wolfgang J. Paul, Saarland University, Germany * Wolfram Schulte (co-chair), Microsoft Research, USA * Cesare Tinelli, University of Iowa, USA * Arnaud Venet, Kestrel Technologies, USA -- | Claude Marché | mailto:Claude.Marche@lri.fr | | LRI - Bât. 490 | http://www.lri.fr/~marche/ | | Université de Paris-Sud | phoneto: +33 1 69 15 64 85 | | F-91405 ORSAY Cedex | faxto: +33 1 69 15 65 86 | From Pierre.Letouzey at !NS! pps.jussieu.fr Thu Apr 27 12:22:08 2006 From: Pierre.Letouzey at !NS! pps.jussieu.fr (Pierre Letouzey) Date: Thu, 27 Apr 2006 13:22:08 +0200 Subject: [Coq-Club][Bvector] + NArith + Intmap ... In-Reply-To: <444DE26F.7010808@labri.fr> References: <14b4215a0604250051w4e050e2do37b3083eebb8846c@mail.gmail.com> <444DE26F.7010808@labri.fr> Message-ID: <20060427112208.GB16242@pps.jussieu.fr> On Tue, Apr 25, 2006 at 10:48:47AM +0200, Pierre Casteran wrote: > Philippe Andouard wrote: > > >Bonjour, > > > >J'aimerais pouvoir simuler le fonctionnement d'un octet. J'ai vu que > >la librairie standard de Coq proposait des vecteurs de bits au travers > >du module Bvector. > > > >Mon problème est le suivant, je voudrais convertir un entier en base > >dix en sa représentation en base deux et le stocker dans un vecteur de > >bits. Par exemple si on considère l'entier 15 je voudrais pouvoir > >stoker [0 0 0 0 1 1 1 1] dans mon vecteur. > >J'arrive à déclarer des Bvector mais je n'arrive pas à stocker quoi > >que ce soit dedans. > > > >Quelqu'un saurait-il comment stocker des valeurs dans des vecteurs? > > > > > The constructor Vcons can be used to store values in vectors. > ... > > Pierre > * NArith: --------- It just happens that I've been busy these days improving Coq library NArith. This not-so-well-known part of the standard library proposes a type N = N0 | Npos of positive, i.e. a type for natural numbers coded in a binary way. In particular, you may find interesting the new file theories/NArith/Ndigits.v, that contains some operations over bits of an N number (for instance a bitwise xor). After seeing your mail, I've placed at the end of this file some conversions functions between N and Bvector: N2Bv and Bv2N. There is also a N2Bv_gen that forces the production of a bit vector with a precise size. All this is currently only available for Coq SVN, that you can download or browse at: http://gforge.inria.fr/scm/?group_id=269 With it, you can now write for instance: Require Import Bvector BinNat Ndigits. Implicit Arguments Vcons. Eval compute in (N2Bv 15). (* = Vcons true (Vcons true (Vcons true (Vcons true (Vnil bool)))) : Bvector (Nsize 15) *) Moreover, conversion functions between N and nat are now also available, in file Nnat, so it should be fairly easy now to access the binary digits of any form of natural numbers. * Intmap: -------- A somewhat related question: is anyone on this list aware of any development that uses the library IntMap, apart from the ones already in the user's contribs (Rocq/GRAPHS, Rocq/TreeAutomata, Dyade/BDDS, Cachan/SMC) ? These recent additions to the library NArith are mostly bits and parts coming from IntMap, since the type of addresses in IntMap is ad, which is isomorphic to N. Overall, NArith+Intmap contains now at least as much as before, but lots of names have changed. Moreover, Intmap now uses the same option type as the rest of Coq. I've adapted the four user's contribs to this revised Intmap, please contact me if you have code that needs to be adapted as well, since I've a script that can do a good deal of the job. More generally, I would be glad to hear from anybody that uses or plans to use finite sets or maps, in order to see if the new FSet/Fmap framework fits her/his needs (see directory theories/FSets/ in the SVN repository of Coq). Best regards, Pierre Letouzey From jasper at !NS! cs.ru.nl Fri Apr 28 11:16:14 2006 From: jasper at !NS! cs.ru.nl (Jasper Stein) Date: Fri, 28 Apr 2006 12:16:14 +0200 Subject: [Coq-Club]Re: Reals theory In-Reply-To: <200604191221.10490.jasper@cs.ru.nl> References: <200604191221.10490.jasper@cs.ru.nl> Message-ID: <200604281216.14795.jasper@cs.ru.nl> Dear Coq-Club, Since no one has answered my last week's question on why Raxioms.v defines the injection INR with a separate clause S O => 1, I have now turned to trying to compile a version without it. However, black magic and scrying ensue - and I'd be grateful if anyone could tell me how it's done (or answer my previous question - or, preferably, both). Basically, my question is this: how does Coq know that when I type 0, I mean R0? Consider the following transcript: ========== jasper@Gainsay:~/coq-8.0pl3/theories/Reals$ coqtop Welcome to Coq 8.0pl3 (Jan 2006) Coq < Check 0%R. Toplevel input, characters 6-9 > Check 0%R. > ^^^ User error: Unknown scope delimiting key R Coq < Require Export Rdefinitions. Coq < Unset Printing Notations. Coq < Set Printing Coercions. Coq < Check 0%R. R0 : R =========== Now one would think there's a Notation or Syntactic Definition command somewhere - but there isn't! And stranger still, if I make a copy of Rdefinitions (where R0 is defined), and only change R_scope into MyR_scope throughout, I can do this: ============ jasper@Gainsay:~/coq-8.0pl3/theories/Reals$ coqtop Welcome to Coq 8.0pl3 (Jan 2006) Coq < Add LoadPath "/home/jasper/coq/MyReals". Coq < Require Export MyRdefinitions. Coq < Check 0%R. 0 : nat ============= So indeed the scope key R is defined, but it isn't bound to MyR_scope or to the type R. Clarification, anyone? Or is this a bug? Groeten, -- Jasper Stein From mayero at !NS! pauillac.inria.fr Sun Apr 30 07:42:00 2006 From: mayero at !NS! pauillac.inria.fr (Micaela Mayero) Date: Sun, 30 Apr 2006 08:42:00 +0200 (MET DST) Subject: [Coq-Club]Reals theory In-Reply-To: <200604191221.10490.jasper@cs.ru.nl> from Jasper Stein at "Apr 19, 106 12:21:10 pm" Message-ID: <200604300642.IAA27759@pauillac.inria.fr> Hi, Sorry for this late answer. > I have a question regarding the theory Reals from the standard library. I > would contact the author but I can't find out who it is, hence I send this to > this list. Some time ago, it was written in the CREDITS file but it seems this file has changed (I don't know why?). Actually, I developped this library, which was completed later by Olivier Desmettre. > In the file Coq/Reals/Raxioms.v an injection is defined from nat to R, as > follows: > > Fixpoint INR (n:nat) : R := > match n with > | O => 0 > | S O => 1 > | S n => INR n + 1 > end. > > It seems a bit strange to have a separate clause for S O - it can be proved > that a function inR, defined without this clause, is extensionally equal to > INR, and indeed "auto with real" cannot solve some subgoals that it /can/ > prove using inR. > > So - is there a reason to define INR this way? It is due to an historical reason (to use "simpl" in order to reduce (INR 1) directly to 1, very useful in some cases). I plan to clean this library significantly during this summer... If it is a really a problem for you, as you said, for the moment, a simple idea could be to define another INR, that you could use with an extentionality lemma. This solution allows you to use all the properties of INR after one step of rewriting. Hope this helps, Micaela. ---------------------------------------- Micaela.Mayero@lipn.univ-paris13.fr http://www-lipn.univ-paris13.fr/~mayero/ From pierre.casteran at !NS! labri.fr Tue May 2 12:20:19 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Tue, 02 May 2006 13:20:19 +0200 Subject: [Coq-Club]Using coqdoc Message-ID: <44574073.6010503@labri.fr> Hi. Which is the good option for coqdoc in case of a multi-directory development ? I have a development splitted in various subdirectories D1 D2 D3. I call coq_makefile D1/*.v D2/*.v D3/*.v -I D1 -I D2 -I D3 and I manage to have : COQC=$(COQBIN)coqc -dump-glob htmllinks and a target doc: $(VFILES) $(COQDOC) --glob-from htmllinks \ $(VFILES) The problem is that all html files are put in the current directory with names like D1.M1.html, D2.M2.html, though the a- links in html files have the (correct) form ".../D1/M1.html" Is there something to change in the call to coq_makefile and/or the options to coqc and coqdoc ? Thanks, Pierre From pierre.casteran at !NS! labri.fr Wed May 3 10:20:49 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Wed, 03 May 2006 11:20:49 +0200 Subject: [Coq-Club]Using coqdoc In-Reply-To: <44574073.6010503@labri.fr> References: <44574073.6010503@labri.fr> Message-ID: <445875F1.9060408@labri.fr> I tried another way: putting the option --glob-from htmllinks for coqdoc in the makefile then doing make html as a result, each subdirectory has is proper index.html and html file for ecah module, but none links within or between html files. Is coqdoc truely compatible with multi-directories developments with a single makefile ? Pierre Pierre Casteran wrote: > Hi. > > Which is the good option for coqdoc in case of a multi-directory > development ? > > I have a development splitted in various subdirectories D1 D2 D3. > > I call coq_makefile D1/*.v D2/*.v D3/*.v -I D1 -I D2 -I D3 > and I manage to have : COQC=$(COQBIN)coqc -dump-glob htmllinks > and a target > > doc: $(VFILES) > $(COQDOC) --glob-from htmllinks \ > $(VFILES) > > > The problem is that all html files are put in the current directory > with names like > D1.M1.html, D2.M2.html, though the a- links in html files have the > (correct) > form ".../D1/M1.html" > > > Is there something to change in the call to coq_makefile and/or the > options to coqc and coqdoc ? > > Thanks, > Pierre > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 lionel at !NS! mamane.lu Wed May 3 12:34:31 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Wed, 3 May 2006 13:34:31 +0200 Subject: [Coq-Club]Using coqdoc In-Reply-To: <445875F1.9060408@labri.fr> References: <44574073.6010503@labri.fr> <445875F1.9060408@labri.fr> Message-ID: <20060503113431.GA924@capsaicin.mamane.lu> On Wed, May 03, 2006 at 11:20:49AM +0200, Pierre Casteran wrote: > Is coqdoc truely compatible with multi-directories developments with > a single makefile ? CoRN uses it that way; I'm not sure which one exactly of the many options passed to it makes it work well. Maybe the -R $(CORNROOT) CoRN stuff. -- Lionel From herbelin at !NS! pauillac.inria.fr Wed May 3 16:53:36 2006 From: herbelin at !NS! pauillac.inria.fr (Hugo Herbelin) Date: Wed, 3 May 2006 17:53:36 +0200 (MET DST) Subject: [Coq-Club]STRATEGIES 2006 -- Final CFP Message-ID: <200605031553.RAA26583@pauillac.inria.fr> (Apologies for multiple copies) *** Final Call for Papers and Call for Participation *** Sixth International Workshop on Strategies in Automated Deduction STRATEGIES 2006 http://research.nianet.org/strategies06 An IJCAR'06 Affiliated Workshop at FLoC 2006 STRATEGIES 2006 is a successor to both the series of STRATEGIES workshops associated with CADE and IJCAR and to the STRATA 2003 workshop associated with TPHOLs. The workshop is the primary forum for the communication of new results on control strategies and search plans in automated theorem proving, automated model building, decision procedures, interactive proof assistants, proof planners, and logical frameworks, in first-order (including propositional and purely equational as special cases), modal (e.g., temporal) and higher-order logics. Papers and participation are invited from both the fully automatic and interactive theorem proving communities. The proceedings of the workshop will appear in the Electronic Notes in Theoretical Computer Science (ENTCS). The page limit for regular paper has been increased to 16 pages and for position papers to 5 pages. For the full Call for Papers see: http://research.nianet.org/strategies06/cfp.html * Submission deadline: May 22, 2006 * Notification: June 26, 2006 * Final versions: July 10, 2006 * Workshop: August 16, 2006 * IJCAR: August 16 - August 21, 2006 * Inquiries: strategies06@nianet.org From Frederic.Blanqui at !NS! loria.fr Wed May 10 08:15:44 2006 From: Frederic.Blanqui at !NS! loria.fr (Frederic Blanqui) Date: Wed, 10 May 2006 09:15:44 +0200 (CEST) Subject: [Coq-Club]Using coqdoc In-Reply-To: <20060503113431.GA924@capsaicin.mamane.lu> References: <44574073.6010503@labri.fr> <445875F1.9060408@labri.fr> <20060503113431.GA924@capsaicin.mamane.lu> Message-ID: On Wed, 3 May 2006, Lionel Elie Mamane wrote: > On Wed, May 03, 2006 at 11:20:49AM +0200, Pierre Casteran wrote: > >> Is coqdoc truely compatible with multi-directories developments with >> a single makefile ? > > CoRN uses it that way; I'm not sure which one exactly of the many > options passed to it makes it work well. Maybe the > -R $(CORNROOT) CoRN > stuff. we also do it like this in http://color.loria.fr/ html: clean-doc coqdoc --html -g -d doc --glob-from $(DUMP) -R `pwd` Rewriting `find . -name \*.v` ./createIndex every thing is put in the directory doc/ with no subdirectory d1/d2/f.v gives doc/d1.d2.f.html see http://color.loria.fr/doc/main.html From femke at !NS! cs.vu.nl Wed May 10 09:47:06 2006 From: femke at !NS! cs.vu.nl (Femke van Raamsdonk) Date: Wed, 10 May 2006 10:47:06 +0200 (CEST) Subject: [Coq-Club]HOR 2006: extended deadline Message-ID: !!!!!!!!!!!!!!!!!! Extended Deadline: May 17 !!!!!!!!!!!!!!!!!!!! ******************************** * * * HOR'06 CALL FOR ABSTRACTS * * * ******************************** 3rd International Workshop on Higher-Order Rewriting Tuesday August 15, 2006 Sheraton, Seattle, WA http://hor.pps.jussieu.fr/06 Important DATES: May 17, 2006 : deadline electronic submission of paper May 29, 2006 : notification of acceptance of papers June 8, 2006 : deadline for final version of accepted papers The aim of HOR is to provide an informal and friendly setting to discuss recent work and work in progress concerning higher-order rewriting. HOR 2002 was part of FLoC 2002 in Copenhagen, Denmark. HOR 2004 was part of RDP 2004 in Aachen, Germany. HOR 2006 will be part of FLoC 2006 in Seattle, USA. INVITED TALKS: Hugo Herbelin (INRIA Futurs, Paris) Eelco Visser (Universiteit Utrecht, The Netherlands) TOPICS of interest include (but are not limited to): APPLICATIONS: proof checking, theorem proving, generic programming, declarative programming, program transformation. FOUNDATIONS: pattern matching, unification, strategies, narrowing, termination, syntactic properties, type theory. FRAMEWORKS: term rewriting, conditional rewriting, graph rewriting, net rewriting, comparisons of different frameworks. IMPLEMENTATION: explicit substitution, rewriting tools, compilation techniques. SEMANTICS: semantics of higher-order rewriting, higher-order abstract syntax PROGRAM/ORGANIZING COMMITTEE: Delia Kesner Universite Paris 7, France kesner@pps.jussieu.fr Femke van Raamsdonk Vrije Universiteit, The Netherlands femke@cs.vu.nl Mark-Oliver Stehr SRI International, USA stehr@csl.sri.com HOR'06 SUBMISSIONS: Abstracts between 2 and 5 pages. As HOR is meant to be a platform to discuss ongoing research we are also interested in abstracts describing work in progress, or problems in higher-order rewriting. Please use the EasyChair page http://www.easychair.org/HOR06/ to submit or update your paper. PROCEEDINGS: The proceedings of HOR 2006 will be made available on the HOR 2006 web page and copies will be distributed to the participants at the workshop. LOCAL ARRANGEMENTS: Gopal Gupta University of Texas, Dallas, USA gupta@utdallas.edu Ashish Tiwari SRI International, USA tiwari@csl.sri.com From Frederic.Blanqui at !NS! loria.fr Wed May 10 12:06:32 2006 From: Frederic.Blanqui at !NS! loria.fr (Frederic Blanqui) Date: Wed, 10 May 2006 13:06:32 +0200 (CEST) Subject: [Coq-Club]CoLoR: new release with HORPO ! Message-ID: i'm very pleased to announce a new release of CoLoR with Adam Koprowski's proof of the well-foundedness of the higher-order recursive path ordering (HORPO)! note that it contains a library on simply typed lambda-terms with de Bruijn indices. see http://color.loria.fr/ for more details. see http://color.loria.fr/doc/main.html to browse the files. From topwl at !NS! free.fr Thu May 11 14:46:25 2006 From: topwl at !NS! free.fr (topwl@free.fr) Date: Thu, 11 May 2006 15:46:25 +0200 Subject: [Coq-Club]induction proof Message-ID: <1147355185.4463403142af2@imp2-g19.free.fr> Hello, I have a problem with a proof. I simplified the problem. I don't arrive to prove invariant_trans lemma. I think that it is by induction ... thank you for your assistance. Martin Parameter valeur : Set. Parameter lecture : nat -> nat -> valeur -> Prop. Definition invariant (rf0: nat) (offset0: nat) (rf1: nat) (offset1: nat) (length: nat) : Prop := forall idx:nat, O<=idx -> idx forall val:valeur, (lecture rf0 (offset0+idx) val) <-> (lecture rf1 (offset1+idx) val). Lemma invariant_trans : forall l1 l2 rf0 offset0 rf1 offset1, invariant rf0 offset0 rf1 offset1 l1 -> invariant rf0 (offset0+l1) rf1 (offset1+l1) l2 -> invariant rf0 offset0 rf1 offset1 (l1+l2). Proof. intros l1. elim l1. (* CB : l1 = 0 *) intro l2. elim l2. (* CB : l2 = 0 *) intros rf0 offset0 rf1 offset1. simpl. auto. (* HI : l2 = n2 *) intros n2 Hn2. intros rf0 offset0 rf1 offset1. simpl. rewrite <- plus_n_O. rewrite <- plus_n_O. auto. (* HI : l1 = n1 *) intros n1 Hn1. intro l2. elim l2. (* CB : l2 = 0 *) intros rf0 offset0 rf1 offset1. simpl. rewrite <- plus_n_O. auto. (* HI : l2 = n2 *) intros n2 Hn2. intros rf0 offset0 rf1 offset1. From venanzio at !NS! site.uottawa.ca Thu May 11 16:09:10 2006 From: venanzio at !NS! site.uottawa.ca (Venanzio Capretta) Date: Thu, 11 May 2006 11:09:10 -0400 Subject: [Coq-Club]drinker paradox Message-ID: <1147360150.28439.1.camel@gauss.mathstat.uottawa.ca> Hi, just a curiosity: can somebody give me some references for the drinker paradox. The Coq tutorial says that it is by Smullyan: in which of his books can I find it? Cheers, Venanzio From pierre.casteran at !NS! labri.fr Thu May 11 16:33:13 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Thu, 11 May 2006 17:33:13 +0200 Subject: [Coq-Club]induction proof In-Reply-To: <1147355185.4463403142af2@imp2-g19.free.fr> References: <1147355185.4463403142af2@imp2-g19.free.fr> Message-ID: <44635939.4080707@labri.fr> topwl@free.fr wrote: >Hello, > >I have a problem with a proof. >I simplified the problem. >I don't arrive to prove invariant_trans lemma. >I think that it is by induction ... > >thank you for your assistance. >Martin > > > Hi, First, you can simplify a little yours statement avoiding the (always true) 0<=idx, etc. Your proof of transitivity can be done if you first prove (or admit) a little lemma (I hope it's true). Lemma lt_plus_ab : forall n a b : nat, n < a + b -> n < a \/ exists y, n=a+y /\ y < b. Admitted. The following proof works, although, it is written in a bas style, can certainly be shortened. Pierre Require Import Arith. Lemma invariant_trans : forall l1 l2 rf0 offset0 rf1 offset1, invariant rf0 offset0 rf1 offset1 l1 -> invariant rf0 (offset0+l1) rf1 (offset1+l1) l2 -> invariant rf0 offset0 rf1 offset1 (l1+l2). Proof. intros. red. intros idx H' val. split. case (lt_plus_ab idx l1 l2 H'). intro. red in H. red in H0. intro. case (H idx H1 val). auto. intro. red in H;red in H0. case H1;intros y (Hy,H'y). case (H0 y H'y val). subst idx. repeat rewrite plus_assoc. auto. case (lt_plus_ab idx l1 l2 H'). intro. red in H. red in H0. intro. case (H idx H1 val). auto. intros (y, (Hy,H'y)). case (H0 y H'y val). subst idx. repeat rewrite plus_assoc. auto. Qed. >Parameter valeur : Set. >Parameter lecture : nat -> nat -> valeur -> Prop. > >Definition invariant > (rf0: nat) (offset0: nat) (rf1: nat) (offset1: nat) (length: nat) : Prop := > forall idx:nat, > O<=idx -> idx > forall val:valeur, > (lecture rf0 (offset0+idx) val) <-> > (lecture rf1 (offset1+idx) val). > > >Lemma invariant_trans : > forall l1 l2 rf0 offset0 rf1 offset1, > > invariant rf0 offset0 rf1 offset1 l1 -> > invariant rf0 (offset0+l1) rf1 (offset1+l1) l2 -> > invariant rf0 offset0 rf1 offset1 (l1+l2). >Proof. > intros l1. > elim l1. > > (* CB : l1 = 0 *) > intro l2. > elim l2. > > (* CB : l2 = 0 *) > intros rf0 offset0 rf1 offset1. > simpl. > auto. > > (* HI : l2 = n2 *) > intros n2 Hn2. > intros rf0 offset0 rf1 offset1. > simpl. > rewrite <- plus_n_O. > rewrite <- plus_n_O. > auto. > > (* HI : l1 = n1 *) > intros n1 Hn1. > intro l2. > elim l2. > > (* CB : l2 = 0 *) > intros rf0 offset0 rf1 offset1. > simpl. > rewrite <- plus_n_O. > auto. > > (* HI : l2 = n2 *) > intros n2 Hn2. > intros rf0 offset0 rf1 offset1. > > >-------------------------------------------------------- >Bug reports: http://coq.inria.fr/bin/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 pierre.casteran at !NS! labri.fr Thu May 11 16:43:09 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Thu, 11 May 2006 17:43:09 +0200 Subject: [Coq-Club]induction proof In-Reply-To: <44635939.4080707@labri.fr> References: <1147355185.4463403142af2@imp2-g19.free.fr> <44635939.4080707@labri.fr> Message-ID: <44635B8D.2060804@labri.fr> Pierre Casteran wrote: > > Your proof of transitivity can be done if you first prove (or admit) > a little lemma > > (I hope it's true). > Lemma lt_plus_ab : forall n a b : nat, n < a + b -> > n < a \/ exists y, n=a+y /\ y < b. > Admitted. > Require Import Peano_dec. Require Import Omega. Lemma lt_plus_ab : forall n a b : nat, n < a + b -> n < a \/ exists y, n=a+y /\ y < b. intros n a b; case (le_lt_dec a n). intros. right;exists (n-a). omega. auto. Qed. From carlos at !NS! math.unice.fr Fri May 12 07:45:28 2006 From: carlos at !NS! math.unice.fr (Carlos.SIMPSON) Date: Fri, 12 May 2006 08:45:28 +0200 Subject: [Coq-Club]induction proof In-Reply-To: <44635B8D.2060804@labri.fr> References: <1147355185.4463403142af2@imp2-g19.free.fr> <44635939.4080707@labri.fr> <44635B8D.2060804@labri.fr> Message-ID: <44642F08.5020601@math.unice.fr> Require Arith. Require Omega. Lemma lt_plus_ab : forall n a b : nat, n < a + b -> n < a \/ exists y, n=a+y /\ y < b. Proof. intros. assert (n< a \/ n>= a). omega. induction H0. apply or_introl. assumption. apply or_intror. apply ex_intro with (n-a). apply conj. omega. omega. Qed. Conclusion: omega is great, we need more tactics like that! ---Carlos Simpson From benjamin.werner at !NS! inria.fr Sun May 7 01:22:27 2006 From: benjamin.werner at !NS! inria.fr (Benjamin Werner) Date: Sun, 7 May 2006 02:22:27 +0200 (CEST) Subject: [Coq-Club]Announcement and CFP: Workshop Proofs & Numbers 12-13/06 in Orsay Message-ID: <50223.129.104.11.29.1146961347.squirrel@argos.lix.polytechnique.fr> Dear Colleagues, We plan a workshop on the upcoming research field of interactions between numerical computations and formal proofs. The workshop will take place over 1 and 1/2 days, on June 12th and 13th in Orsay; it will follow a more general seminar the 12th in the morning. We encourage you to participate and to present work on the topic. The aim is to bring together from different fields; please feel free to forward this announcement to other possibly interested colleagues. More information is given below and can also be found on : http://www-sop.inria.fr/marelle/Laurent.Thery/microsoft/Workshop%20on%20numbers%20and%20proofs.html Given the short delay, the program will be established as propositions come in and the web-site will grow progressively. We already plan talks about formal primality proofs, representation of numbers in type theory, formal real optimization, representation of arbitrary precision real numbers in Coq... The workshop will be supported by the EU TYPES project and the new joint laboratory of INRIA and Microsoft Research. Members of TYPES can therefore use their TYPES money to fund their trip. Hoping to see many of you in Orsay, Benjamin Grégoire, Laurent Théry, Benjamin Werner ------------------------------------------ TYPES Workshop on Numbers and Proofs Orsay (France), June 12-13 2006 Scope ********* There is a growing trend of bringing together formal proofs and efficient numerical computations. On one hand, people working designing efficient numerical libraries are more and more interested by proving their correctness. On the other hand, theorem proving people want to use non-trivial numerical computations inside formal proofs. Indeed, recent examples show that the naive representations of numbers in proof systems are not sufficient anymore: * New developments like work on Hales' proof of the Kepler conjecture or primality tests show that computations over numbers are a crucial part of the proof. New proof tactics like * Grˆbner bases or Cylindrical Algebraic Decomposition or interval arithmetic show that computation over numbers are crucial to define semi-decision procedures. In both cases, checking the resulting proof requires efficient computations over integers, rational or real numbers ... We believe that this area is meant to grow in the near future and opens new perspectives to formal mathematics. This workshop 's goal is to encourage the cross-fertilization between theorem proving and computer arithmetic. In particular to promote the design of proof-systems with reasonably efficient computational abilities using certified routines. More generally, this workshop should be an occasion for the communities of theorem proving and computer arithmetic to meet. Location and Dates ************************* The workshop will be held on June 12-13 in France (Orsay / Plateau de Saclay). For people that want to give a talk or simply participate, please send an email to one of the organizers before May 25: Benjamin.Werner@inria.fr Laurent.Thery@sophia.inria.fr Benjamin.Gregoire@sophia.inria.fr --------------------- _______________________________________________ Types mailing list Types@lists.chalmers.se https://lists.chalmers.se/mailman/listinfo/types From topwl at !NS! free.fr Fri May 12 18:10:59 2006 From: topwl at !NS! free.fr (topwl@free.fr) Date: Fri, 12 May 2006 19:10:59 +0200 Subject: [Coq-Club]induction proof bis Message-ID: <1147453859.4464c1a3c548b@imp1-g19.free.fr> Hello, I thank you for your answer. but I'm sorry, I was mistaken in my problem. I have a transitivity problem with copy definition. I try to proof it for one week. I don't have a new idea. If you have an indication, an idea or other Thanks very much, Martin Require Import ZArith. Parameter memory : Set. Parameter valeur : Set. Parameter lecture : memory -> nat -> nat -> valeur -> Prop. (* offset <= idx < offset + len *) Definition check (offset: nat) (idx: nat) (len: nat) : bool := (Zle_bool (Z_of_nat offset) (Z_of_nat idx)) && (Zlt_bool (Z_of_nat idx) (Z_of_nat (offset+len))). Definition copy (min mout : memory) (mem_length: nat) (adrSrc: nat) (adrDest: nat) (offset: nat) (len:nat) : Prop := forall idx:nat, idx forall val:valeur, lecture min adrSrc idx val -> if (check offset idx len) then lecture mout adrDest idx val else (lecture min adrDest idx val) <-> (lecture mout adrDest idx val). Lemma copy_trans : forall min mem mout mem_length adrSrc adrDest offset l1 l2, copy min mem mem_length adrSrc adrDest offset l1 -> copy mem mout mem_length adrSrc adrDest (offset+l1) l2 -> copy min mout mem_length adrSrc adrDest offset (l1+l2). From duprat at !NS! ens-lyon.fr Fri May 12 08:36:13 2006 From: duprat at !NS! ens-lyon.fr (Jean.Duprat) Date: Fri, 12 May 2006 09:36:13 +0200 Subject: [Coq-Club]induction proof In-Reply-To: <1147355185.4463403142af2@imp2-g19.free.fr> References: <1147355185.4463403142af2@imp2-g19.free.fr> Message-ID: <44643AED.7000303@ens-lyon.fr> This is a multi-part message in MIME format. --------------060405010400020707000901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Theorem invariant_trans can be proved by cases : Require Export Omega. Lemma invariant_trans : forall l1 l2 rf0 offset0 rf1 offset1, invariant rf0 offset0 rf1 offset1 l1 -> invariant rf0 (offset0+l1) rf1 (offset1+l1) l2 -> invariant rf0 offset0 rf1 offset1 (l1+l2). Proof. intros l1 l2 rf0 offset0 rf1 offset1 H1 H2 idx Hi0 Hi1. destruct (le_lt_dec l1 idx). replace idx with (l1 + (idx - l1)); repeat rewrite plus_assoc. apply H2; omega. omega. apply H1; omega. Qed. Yours Jean Duprat topwl@free.fr wrote: >Hello, > >I have a problem with a proof. >I simplified the problem. >I don't arrive to prove invariant_trans lemma. >I think that it is by induction ... > >thank you for your assistance. >Martin > > >Parameter valeur : Set. >Parameter lecture : nat -> nat -> valeur -> Prop. > >Definition invariant > (rf0: nat) (offset0: nat) (rf1: nat) (offset1: nat) (length: nat) : Prop := > forall idx:nat, > O<=idx -> idx > forall val:valeur, > (lecture rf0 (offset0+idx) val) <-> > (lecture rf1 (offset1+idx) val). > > >Lemma invariant_trans : > forall l1 l2 rf0 offset0 rf1 offset1, > > invariant rf0 offset0 rf1 offset1 l1 -> > invariant rf0 (offset0+l1) rf1 (offset1+l1) l2 -> > invariant rf0 offset0 rf1 offset1 (l1+l2). >Proof. >... > > --------------060405010400020707000901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Theorem invariant_trans can be proved by cases :
Require Export Omega.

Lemma invariant_trans :
  forall l1 l2 rf0 offset0 rf1 offset1,
    invariant rf0 offset0 rf1 offset1 l1 ->
    invariant rf0 (offset0+l1) rf1 (offset1+l1) l2 ->
    invariant rf0 offset0 rf1 offset1 (l1+l2).
Proof.
intros l1 l2 rf0 offset0 rf1 offset1 H1 H2 idx Hi0 Hi1.
destruct (le_lt_dec l1 idx).
 replace idx with (l1 + (idx - l1)); repeat rewrite plus_assoc.
  apply H2; omega.
  omega.
 apply H1; omega.
Qed.

Yours

	Jean Duprat

topwl@free.fr wrote:

Hello,

I have a problem with a proof.
I simplified the problem.
I don't arrive to prove invariant_trans lemma.
I think that it is by induction ...

thank you for your assistance.
Martin


Parameter valeur : Set.
Parameter lecture  : nat -> nat -> valeur -> Prop.

Definition invariant
  (rf0: nat) (offset0: nat) (rf1: nat) (offset1: nat) (length: nat) : Prop :=
  forall idx:nat,
    O<=idx -> idx<length ->
  forall val:valeur,
   (lecture rf0 (offset0+idx) val) <->
   (lecture rf1 (offset1+idx) val).


Lemma invariant_trans :
  forall l1 l2 rf0 offset0 rf1 offset1,

    invariant rf0 offset0 rf1 offset1 l1 ->
    invariant rf0 (offset0+l1) rf1 (offset1+l1) l2 ->
    invariant rf0 offset0 rf1 offset1 (l1+l2).
Proof.
...

--------------060405010400020707000901-- From dubois at !NS! iie.cnam.fr Fri May 12 11:00:30 2006 From: dubois at !NS! iie.cnam.fr (catherine DUBOIS) Date: Fri, 12 May 2006 12:00:30 +0200 Subject: [Coq-Club]propostion de post-doc au CEDRIC (CNAM) Message-ID: <44645CBE.8090503@iie.cnam.fr> Chères et chers collègues, Veuillez trouver ci-joint une annonce d'un poste de post doctorant à pourvoir, à partir de septembre 2006, sur le projet ARA SSIA REVE. Merci de diffuser l'annonce. Cordialement, Catherine Dubois ------------------------------------------------------------------------ VEUILLEZ EXCUSER LES RECEPTIONS MULTIPLES A PARTIR DE DIFFERENTES LISTES ------------------------------------------------------------------------ Spécification et certification de propriétés de qualité de service liées aux changement de contexte d'éxécution dans le modèle à base composants du projet REVE EQUIPE D'ACCUEIL : Équipe CPR (Systèmes sûrs: Conception et Programmation Raisonnées) Laboratoire CEDRIC (Centre d'Etude et De Recherche en Informatique du Cnam) Conservatoire National des Arts et Métiers 292, rue St. Martin FR-75141 Paris Cedex 03 Tel : +33 01 40 27 22 96 Fax : +33 01 40 27 22 96 url : http://cedric.cnam.fr/ CADRE DE LA PROPOSITION : Le travail s'inscrit dans le cadre du projet REVE (safe Reuse of Embedded components in heterogeneous enVironmEnts) (projet ARA SSIA) http://reve.futurs.inria.fr/ Les applications modernes dans les domaines des middlewares, des systèmes embarqués ou des systèmes d'information, sont de plus en plus conçus en termes d'architectures logicielles et de composants. Les composants peuvent êtres vus comme des unités logicielles connectables entre elles, offrant des ressources à la condition que certaines autres lui soient fournies. Un trait caractéristique des composants repose sur la nécessité de configuration ou de reconfiguration dynamique dues par exemple à des changements dans le contexte d'éxécution (réseau, niveau de batterie, etc). Les changemement de contexte d'éxécution visés par le projet REVE concernent éssentiellement le niveau de disponibilité des ressources critiques pour l'éxécution des composants embarqués: niveau de batterie, quantité de CPU, activité du réseau, etc. Le but du projet REVE est de construire un modèle de développement et un environnement d'exécution à base de composants pour des applications embarquées où les politiques de changement de contexte peuvent être spécifiées, programmées et vérifiées. Afin de valider la généralité de l'approche, ce modèle doit pouvoir être projété vers des plateformes ou vers des modèles à composants existants, dont principalement FRACTAL et ACCORD/UML. Le travail demandé au post-doctorant consistera à définir, en collaboration avec les membres de l'équipe CPR participant au projet, un langage pour spécifier les composants et les politiques de changement de contexte et d'adaptation au contexte, ainsi que les propriétés de qualité de service souhaitées pour les composants dans un certain contexte d'éxécution. Le modèle FRACTAL sera le point de départ des travaux (http://fractal.objectweb.org/). SUJET DU STAGE POST DOCTORAL Axe 1 : En partant des études de cas fournies par le projet REVE, dégager les besoins du langage de spécification pour l'expression des propriétés fonctionnelles et des propriétes de qualité de service des composants (restreintes au contexte des logiciels embarqués : ressources en batterie, CPU, mémoire ...). Axe 2 : Étude de la specification de la reconfiguration dynamique d'un système à base des composants et de ses conséquences en termes de certification. Axe 3 : Étude comparative des différents langages de spécification outillés existants (fondés sur la logique d'ordre supérieur ou la théorie des ensembles) et proposition d'adaptation au modèle des composants du projet REVE. Ce programme étant très vaste, il sera ciblé le cas échéant, en fonction des compétences et des intérêts du candidat. PROFIL REQUIS Connaissances très solides en méthodes formelles. Très bonne connaissance en sémantique des langages de programmation objets et/ou modulaires et en typage. Une connaissane ou pratique des composants est appréciable mais non nécessaire. En revanche l'envie d'aborder ce domaine (où assez peu de formalisation et de certification existe à l'heure actuelle) est absolument nécessaire. DUREE SOUHAITEE : 12 ou 18 mois. Début souhaité: septembre 2006. COMPETENCES DE L'EQUIPE D'ACCUEIL CPR : http://cedric.cnam.fr Nous nous intéressons à la certification de systèmes, notamment par la preuve. Un des axes de recherche est celui du développement de l'atelier de programmation et certification FOCAL (http://focal.inria.fr/site/index.php). Cet environnement est basé sur un langage de programmation qui possèdedes traits fonctionnels, objets et modulaires. Dans ce langage, le programmeur peut écrire également des spécifications et preuves de son code, qui sont ensuite vérifiées par un prouveur automatique. Actuellement, dans le cadre du projet REVE, nous cherchons à aborder du point de vue de la certification, le paradigme de programmation et de conception à base des composants. CONTACT : Si vous êtes intéressé, contactez : Virginia Aponte (CNAM - CEDRIC), E-mail: aponte@cnam.fr Téléphone: 01 40 27 28 15 ou Catherine Dubois, E-mail : dubois@iie.cnam.fr Téléphone : 01 69 36 73 40 From zucker at !NS! cas.mcmaster.ca Fri May 12 19:53:35 2006 From: zucker at !NS! cas.mcmaster.ca (Jeffery Zucker) Date: Fri, 12 May 2006 14:53:35 -0400 (EDT) Subject: [Coq-Club]FORMAL METHODS 2006: Call for Participation Message-ID: <200605121853.k4CIrZpk015403@birkhoff.cas.mcmaster.ca> [Apologies for multiple postings] FM'06: 14TH INTERNATIONAL SYMPOSIUM ON FORMAL METHODS August 21 - 27, 2006 McMaster University, Hamilton, Ontario, Canada http://fm06.mcmaster.ca/ CALL FOR PARTICIPATION NOTE: REGISTRATION INFORMATION IS AVAILABLE AT http://fm06.mcmaster.ca/symposium_reg.htm NOTE: THE CALLS FOR POSTERS AND TOOL DEMONSTRATIONS, AND FOR THE DOCTORAL SYMPOSIUM, ARE STILL OPEN. Deadline May 26. See http://fm06.mcmaster.ca/call_research_exhibition.htm http://fm06.mcmaster.ca/doctoral_symposium.htm FM'06 is the fourteenth in a series of symposia organized by Formal Methods Europe, http://www.fmeurope.org, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. The symposia have been notably successful in bringing together innovators and practitioners in precise mathematical methods for software development, industrial users as well as researchers. INVITED SPEAKERS There are 5 distinguished invited speakers: * Ernie Cohen, Microsoft: "Validating the Microsoft Hypervisor" * Nicholas Griffin, Director, Bertrand Russell Research Centre, McMaster: "Bertrand Russell: A Philosophy for Formal Methods and a Formal Method for Philosophy" * Thomas A. Henzinger, Professor of Computer and Communication Sciences, EPFL, Switzerland: "Software Design Automation" * Peter Lindsay, Boeing Chair in Systems Engineering, University of Queensland: "Distributed Control in Network-Based Systems" * George Necula, Associate Professor in Computer Science, UC Berkeley: "Data Structure Specifications via Local Equality Axioms" TECHNICAL SYMPOSIUM: August 23 - 25 There are 36 speakers. See http://fm06.mcmaster.ca/technical_program.htm WORKSHOPS There are 4 workshops: * Formal Methods Education Workshop Saturday, August 26, 2006 * International Workshop on Formal Aspects in Security and Trust Saturday August 26 - Sunday August 27, 2006S * Workshop on Software Certification Saturday August 26 - Sunday August 27, 2006 * The Second Overture Workshop Sunday August 27, 2006 For more information, go to http://fm06.mcmaster.ca/workshops.htm TUTORIALS There are 9 full-day and half-day tutorials. See http://fm06.mcmaster.ca/tutorials.htm ORGANIZATION General Chair: Emil Sekerinski (McMaster) Program Chairs: Jayadev Misra (U. Texas, Austin), Tobias Nipkow (TU Munich) Workshop Chair: Tom Maibaum (McMaster) Tutorial Chair: Jin Song Dong (NUS) Tools and Poster Exhibition Chair: Marsha Chechik (U. Toronto) Industry Day Chairs: Volkmar Lotz (SAP France), Asuman Suenbuel (SAP US) Doctoral Symposium Chair: Augusto Sampaio (U. Pernambuco) Sponsorship Chair: Juergen Dingel (Queens U.) PROGRAM COMMITTEE Jean-Raymond Abrial (ETH Zurich) Alex Aiken (Stanford U.) Keijiro Araki (Kyushu U.) Ralph Back (Abo Akademi) Gilles Barthe (INRIA) David Basin (ETH Zurich) Ed Brinksma (U. Twente) Michael Butler (U. Southampton) Rance Cleaveland (U. Stony Brook) Jorge Cuellar (Siemens) Werner Damm (U. Oldenburg) Frank de Boer (U. Utrecht) Javier Esparza (U. Stuttgart) Jose Fiadeiro (U. Leicester) Susanne Graf (VERIMAG) Ian Hayes (U. Queensland) Gerard Holzmann (JPL) Cliff Jones (U. Newcastle) Gary T. Leavens (Iowa State U.) Rustan Leino (Microsoft) Xavier Leroy (INRIA) Dominique Mery (LORIA) Carroll Morgan (UNSW) David Naumann (Stevens) E.-R. Olderog (U. Oldenburg) Paritosh Pandya (TIFR) Sriram Rajamani (Microsoft) John Rushby (SRI) Steve Schneider (U. Surrey) Vitaly Shmatikov (U. Texas, Austin) Bernhard Steffen (U. Dortmund) P.S. Thiagarajan (NUS) Axel van Lamsweerde (U. Louvain) Martin Wirsing (LMU Munich) Pierre Wolper (U. Liege) LOCAL ORGANIZATION Publicity: Wolfram Kahl, Alan Wassyng, Jeff Zucker Tools, Posters, Book Exhibition: Spencer Smith Social Events: Ridha Khedri Local Arrangements:: William Farmer, Mark Lawford Events Co-ordinator: Ryszard Janicki From levy at !NS! Marrakech.iiia.csic.es Mon May 8 17:35:32 2006 From: levy at !NS! Marrakech.iiia.csic.es (Jordi Levy) Date: Mon, 8 May 2006 18:35:32 +0200 Subject: [Coq-Club]UNIF'06 second call for papers Message-ID: <200605081635.k48GZWL02661@Marrakech.iiia.csic.es> [Apologies if you receive multiple copies] UNIF deadline is near !!!!!! ************************************* * * * UNIF'06 SECOND CALL FOR PAPERS * * * * Deadline: May 29, 2006 * * * ************************************* UNIF'06 20th Int. Workshop on Unification A satellite workshop of RTA'6 and FLoC'06 The Seattle Sheraton Hotel and Towers Seattle, WA, USA August 11, 2006 http://www.iiia.csic.es/~levy/unif06.html UNIF is the main international meeting on unification. Unification is concerned with the problem of identifying given terms, either syntactically or modulo a given logical theory. Syntactic unification is the basic operation of most automated reasoning systems, and unification modulo theories can be used, for instance, to build in special equational theories into theorem provers. The aim of UNIF 2006, as that of the previous meetings, is to to bring together people interested in unification, present recent (even unfinished) work, and discuss new ideas and trends in unification and related fields. This includes scientific presentations, but also descriptions of applications and softwares using unification as a strong component. In 2006, UNIF has been organized as part of the 2006 Federated Logic Conference (FLoC 2006). This workshop is the twentieth in the series: UNIF'87 (Val D'Ajol, France), UNIF'88 (Val D'Ajol, France), UNIF'89 (Lambrecht, Germany), UNIF'90 (Leeds, England), UNIF'91 (Barbizon, France), UNIF'92 (Dagstuhl, Germany), UNIF'93 (Boston, USA), UNIF'94 (Val D'Ajol, France), UNIF'95 (Sitges, Spain), UNIF'96 (Herrsching, Germany), UNIF'97 (Orl%/1€Œiso8859-15éans, France), UNIF'98 (Rome, Italy), UNIF'99 (Frankfurt, Germany), UNIF'00 (Pittsburgh, USA), UNIF'01 (Siena, Italy), UNIF'02 (Copenhagen, Denmark). UNIF'03 (Valencia, Spain). UNIF'04 (Cork, Ireland). UNIF'05 (Nara, Japan). ------------------------------------------------------------------------------- Topics of Interest: The meeting will include invited talks, contributed talks, and social time to discuss current topics of interest, which include (but are not limited to): * Unification o E-unification o Unification Algorithms o Higher-Order Unification o String Unification o Context Unification o Nominal Unification o Combination problems o Disunification o Typed Unification * Related Topics o Constraint Solving o Tree Descriptions o Matching o Narrowing * Applications o Type Checking and Type Inference o Automated Deduction o Rewriting o Functional and Logic Programming o Grammars o Computational Linguistics * Implementations ------------------------------------------------------------------------------- Important Dates: May 29, 2006 Deadline for submission of papers, abstracts and system descriptions June 19, 2006 Notification of acceptance July 17, 2006 Camera-ready papers August 11 , 2006 Workshop ------------------------------------------------------------------------------- Program Committee: Temur Kutsia Research Institute for Symbolic Computation Johannes Kepler University of Linz, Linz, Austria Jordi Levy (chair) Institut d'Investigació en Intel.ligència Artificial (IIIA) Consejo Superior de Investigaciones Científicas (CSIC), Barcelona, Spain Christian Urban Mathematisches Institut der LMU Munchen, Germany Mateu Villaret Dept. Informàtica i Matemàtica Aplicada (IMA) Universitat de Girona (UdG), Girona, Spain ------------------------------------------------------------------------------- Submission: Authors are invited to submit via email an abstract (1-5 pages), a paper (no longer than 15 pages), or a system description (no more than 5 pages) in Postscript or PDF format using the UNIF'06 submission page, handled by the EasyChair conference system: http://www.easychair.org/UNIF06/ Authors have been encouraged to use LaTeX2e and the Springer llncs class files. Publication Informal proceedings of accepted contributions will be available on-line. A hard copy will be distributed at the workshop to registered participants. From coq at !NS! peng.dyndns.org Sun May 21 02:58:31 2006 From: coq at !NS! peng.dyndns.org (Daniel Peng) Date: Sat, 20 May 2006 21:58:31 -0400 Subject: [Coq-Club]Induction schemes for not-quite mutually inductive types Message-ID: Hello, I'm trying to formalize Typed Assembly Language in Coq, and the types look like this: Inductive T : Set := | TInt | TCode: Map T -> T (* the type of a code pointer is a partial map from registers to types *) | TVar : nat -> T (* deBruijn indices *) | TForall : T -> T. I'm having trouble with the induction principle in the TCode case. When I induct over T, the TCode case doesn't provide any induction hypotheses. Essentially, I want Map T and T to be mutually inductive; however, I haven't declared them that way, and I can't seem to get a mutual induction principle over them. I thought I could leverage the standard library by using Map, but perhaps this is the wrong approach. Do I need to give up on Map and somehow make the mutual induction explicit (e.g., below)? Is there a better way to do this? I just started learning Coq a week ago, so I'd appreciate any suggestions and advice. Inductive T : Set := | TInt | TCode: (register -> opt) -> T | TVar : typevariable -> T (* deBruijn indices *) | TForall : T -> T with opt : Set := | SOME : T -> opt | NONE. Scheme T_ind2 := Induction for T Sort Set with TCode_ind2 := Induction for option Sort Set. Thank you, Daniel Peng From Frederic.Blanqui at !NS! loria.fr Mon May 22 09:24:19 2006 From: Frederic.Blanqui at !NS! loria.fr (Frederic Blanqui) Date: Mon, 22 May 2006 10:24:19 +0200 (CEST) Subject: [Coq-Club]Induction schemes for not-quite mutually inductive types In-Reply-To: References: Message-ID: On Sat, 20 May 2006, Daniel Peng wrote: > Inductive T : Set := > | TInt > | TCode: Map T -> T (* the type of a code pointer is a partial map > from registers to types *) > | TVar : nat -> T (* deBruijn indices *) > | TForall : T -> T. > > I'm having trouble with the induction principle in the TCode case. > When I induct over T, the TCode case doesn't provide any induction > hypotheses. Essentially, I want Map T and T to be mutually inductive; > however, I haven't declared them that way, and I can't seem to get a > mutual induction principle over them. coq doesn't recognize (Map T) in the type of TCode as a recursive argument and doesn't generate the correct induction principle. you have to define it yourself. see Term/Varyadic/VTerm.v in the CoLoR library http://color.loria.fr/ for an example with list instead of Map: [...] Inductive term : Set := | Var : variable -> term | Fun : forall f : Sig, list term -> term. Reset term_rect. Section term_rect. Variables (P : term -> Type) (Q : terms -> Type). Hypotheses (H1 : forall x, P (Var x)) (H2 : forall f v, Q v -> P (Fun f v)) (H3 : Q nil) (H4 : forall t v, P t -> Q v -> Q (t :: v)). Fixpoint term_rect t : P t := match t as t return P t with | Var x => H1 x | Fun f v => H2 f ((fix vt_rect (v : terms) : Q v := match v as v return Q v with | nil => H3 | cons t' v' => H4 (term_rect t') (vt_rect v') end) v) end. End term_rect. Definition term_ind (P : term -> Prop) (Q : terms -> Prop) := term_rect P Q. Definition term_rec (P : term -> Set) (Q : terms -> Set) := term_rect P Q. From benjamin.werner at !NS! inria.fr Thu May 25 01:09:56 2006 From: benjamin.werner at !NS! inria.fr (Benjamin Werner) Date: Thu, 25 May 2006 02:09:56 +0200 Subject: [Coq-Club]a type equality question In-Reply-To: References: Message-ID: <22A20053-3093-4E02-8828-5EB63405CA6A@polytechnique.fr> It is a late and short answer, but my strong guess would be 2 is not provable; it is not verified by simple set-theoretic semantics 1 is seems not provable; but I am not sure what a model looks like which verifies 2 (that is falsifies 1) cheers, Benjamin Le 14 avr. 06 à 19:06, Vladimir Voevodsky a écrit : > Are any one of the following two opposite statements provable in > Coq (with or without the boolean assumption): > > 1. there exist types A, B, C such that A->(B->C) is not equal to B-> > (A->C) > 2. for all A, B, C one has A->(B->C) = B->(A->C) > > If neither one is provable can one prove (outside of coq) that both > are not provable? > > Vladimir. > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 dpeng at !NS! eecs.harvard.edu Wed May 24 03:58:37 2006 From: dpeng at !NS! eecs.harvard.edu (Daniel Peng) Date: Tue, 23 May 2006 22:58:37 -0400 Subject: [Coq-Club]Induction schemes for not-quite mutually inductive types In-Reply-To: References: Message-ID: Thanks Frederic. That's exactly what I was looking for. Thank you. Daniel On 5/22/06, Frederic Blanqui wrote: > On Sat, 20 May 2006, Daniel Peng wrote: > > > Inductive T : Set := > > | TInt > > | TCode: Map T -> T (* the type of a code pointer is a partial map > > from registers to types *) > > | TVar : nat -> T (* deBruijn indices *) > > | TForall : T -> T. > > > > I'm having trouble with the induction principle in the TCode case. > > When I induct over T, the TCode case doesn't provide any induction > > hypotheses. Essentially, I want Map T and T to be mutually inductive; > > however, I haven't declared them that way, and I can't seem to get a > > mutual induction principle over them. > > coq doesn't recognize (Map T) in the type of TCode as a recursive argument and > doesn't generate the correct induction principle. you have to define it > yourself. see Term/Varyadic/VTerm.v in the CoLoR library > http://color.loria.fr/ for an example with list instead of Map: > > [...] > > Inductive term : Set := > | Var : variable -> term > | Fun : forall f : Sig, list term -> term. > > Reset term_rect. > > Section term_rect. > > Variables > (P : term -> Type) > (Q : terms -> Type). > > Hypotheses > (H1 : forall x, P (Var x)) > (H2 : forall f v, Q v -> P (Fun f v)) > (H3 : Q nil) > (H4 : forall t v, P t -> Q v -> Q (t :: v)). > > Fixpoint term_rect t : P t := > match t as t return P t with > | Var x => H1 x > | Fun f v => H2 f > ((fix vt_rect (v : terms) : Q v := > match v as v return Q v with > | nil => H3 > | cons t' v' => H4 (term_rect t') (vt_rect v') > end) v) > end. > > End term_rect. > > Definition term_ind (P : term -> Prop) (Q : terms -> Prop) := term_rect P Q. > > Definition term_rec (P : term -> Set) (Q : terms -> Set) := term_rect P Q. > From wanf at !NS! cs.vu.nl Thu May 25 12:08:34 2006 From: wanf at !NS! cs.vu.nl (Wan Fokkink) Date: Thu, 25 May 2006 13:08:34 +0200 (CEST) Subject: [Coq-Club]PhD position on formal verification in Amsterdam Message-ID: PHD POSITION: FORMAL VERIFICATION OF EPIDEMIC PROTOCOLS AND DISTRIBUTED VERIFICATION METHODS ============================================================================================ The Theoretical Computer Science Group at the Vrije Universiteit (VU) in Amsterdam seeks a PhD student for four years on a research project devoted to Formal Verification of Epidemic Protocols and Distributed Verification Methods Starting date of this PhD position: as soon as possible. The project ----------- The aim of the project is to develop techniques and tools for distributed verification, and to apply formal verification techniques in the design and analysis of epidemic protocols. The distributed verification track will focus on parallel algorithms for minimizing state spaces modulo some behavioral equivalence, and model checking. The DAS-3 supercomputer, which will become operational this Summer, will serve as an experimentation platform. Epidemic protocols multicast data in a peer-to-peer network similar to the way a disease spreads. The analysis of epidemic protocols should (1) provide further experience with applying formal verification methods to communication protocols, and with applying such methods in the design process, (2) result in improved versions of epidemic protocols, (3) lead to a systematic approach to analyze epidemic protocols, and (4) provide case studies for the distributed verification track. For more detailed information on the project, see http://www.cs.vu.nl/~wanf/epidis.txt This project is a collaboration between three research groups at the VU: Theoretical Computer Science (Wan Fokkink), Distributed Systems (Maarten van Steen, Andy Tanenbaum), and Parallel Computing (Henri Bal). For more information on the involved research groups, see http://www.cs.vu.nl/~tcs http://www.cs.vu.nl/cs/index-en.html Qualifications -------------- Candidates should have completed their studies in computer science or a closely related area. Experience with distributed systems, a good theoretical background (algorithmics, formal methods), and an open attitude to applications are considered advantages. You should enjoy working in an internationally oriented research environment. Communicative skills and the ability to work in a team are important. Information and application --------------------------- For further information about this position please contact: Prof.dr. Wan Fokkink, wanf@cs.vu.nl, tel. +31 (0)20 5987735 You are invited to send an application by email to the above email address no later than June 29, 2006. Your application should consist of a cover letter, a curriculum vitae (including detailed information regarding your academic degree, and possibly a list of publications), and the names and addresses of two references. From zucker at !NS! cas.mcmaster.ca Thu May 25 21:14:49 2006 From: zucker at !NS! cas.mcmaster.ca (Jeffery Zucker) Date: Thu, 25 May 2006 16:14:49 -0400 (EDT) Subject: [Coq-Club]CERTSOFT'06: Revised CFP Message-ID: <200605252014.k4PKEnnV022116@birkhoff.cas.mcmaster.ca> CERTSOFT'06: AN INTERNATIONAL WORKSHOP ON SOFTWARE CERTIFICATION August 26 & 27, 2006 McMaster University, Hamilton, Ontario, Canada http://fm06.mcmaster.ca/certsoft In conjunction with FORMAL METHODS 2006 http://fm06.mcmaster.ca REVISED CALL FOR PAPERS [Note New Submission Deadline: June 16] GOAL OF THE WORKSHOP ==================== Software is currently used to control medical devices, automobiles, aircraft, manufacturing plants, nuclear generating stations, space exploration systems, elevators, electric motors, automated trains, banking transactions, telecommunications devices and a growing number of devices in industry and in our homes. Software is also mission critical for many organizations, even if the software does not `control' what happens. Clearly, many of these systems have the potential to cause physical harm if they malfunction. Even if they do not cause physical harm, their malfunctions are capable of causing financial and political chaos. Currently there is no consistent regulation of software, and society is starting to demand that software used in critical systems must meet minimum safety, security and reliability standards. Manufacturers of these systems are in the unenviable position of not having any clear guidelines as to what may be regarded as acceptable standards in these situations. Even where the systems are not mission critical, software producers and their customers are becoming interested in methods for assuring quality that may result in software supplied with guarantees. The purpose of the workshop is to discuss issues related to software certification. Possible topics include: - What is software certification, and what is its relation to system certification? - Methods, processes, and tools for developing certified software - Certifying safety-critical applications - Certifying embedded systems - Certifying non-critical but commercially significant applications - Certification of software components - Developing standards based on experimental analysis of methods - Formalization of Regulatory Requirements for Software - Repositories of assured/verified/validated software components - Using the Common Criteria for IT Security Evaluation as a model - Standardization of certification methods used in different industries - Evolutionary and incremental certification INVITED SPEAKERS ================ - David Parnas, University of Limerick - Rance Cleaveland, University of Maryland; Fraunhofer Center; Reactive Systems (Other speakers not yet confirmed) SUBMISSION INFORMATION ====================== Regular submissions should be no more than 15 pages and should be in PS or PDF file format. WE ESPECIALLY INVITE POSITION PAPERS, which should be no more than 10 pages. PROCEEDINGS OF THE WORKSHOP will be published and available at the workshop. If there is interest, and papers are felt to be of sufficient quality, we will seek publication of extended versions in a special issue of an appropriate journal. DEADLINES: Original submission: June 16, 2006 Notification of acceptance: July 3, 2006 Final version submission: July 28, 2006 PROGRAM COMMITTEE ================= Stefania Gnesi, ISTI-CNR, Italy -- Co-Chair Tom Maibaum, McMaster University, Canada -- Co-Chair Rance Cleaveland, University of Maryland, USA Alessandro Fantechi, University of Florence, Italy Jan Friso Groote, Eindhoven University of Technology, The Netherlands Connie Heitmeyer, Naval Research Laboratory, USA Paola Inverardi, University of L'Aquila, Italy Yoshiki Kinoshita, CVS-AIST, Japan Dino Mandrioli, Politecnico di Milano, Italy Jonathan Ostroff, York University, Canada Shankar, SRI International, USA David von Oheimb, Siemens AG, Germany (Additional members not yet confirmed) ORGANIZING COMMITTEE (all at McMaster University, Canada) ==================== Alan Wassyng -- Chair Wolfram Kahl Mark Lawford Jeff Zucker From alexwarth at !NS! gmail.com Wed May 31 01:04:35 2006 From: alexwarth at !NS! gmail.com (Alessandro Warth) Date: Tue, 30 May 2006 17:04:35 -0700 Subject: [Coq-Club]help with simple proof Message-ID: Hello, I'm trying to use Coq to formalize a programming language that I've been working on. Unfortunately, a few days ago I ran into trouble while proving what (I think) should be a very simple lemma. I've spent the past few days banging my head against the wall and have made no progress, so I was hoping someone might be able to give me a few pointers... Here is the simplest formulation of that lemma that I could come up with: Inductive AType : Set := | Red : nat -> AType | Black : nat -> AType. Inductive subtyping : AType -> AType -> Prop := | s_refl : forall T, subtyping T T | s_trans : forall T1 T2 T3, subtyping T1 T2 -> subtyping T2 T3 -> subtyping T1 T3. Lemma l : forall (n:nat) (T:AType), subtyping (Red n) T -> exists m:nat, T = (Red m). This should be easy to prove, but I haven't had any luck so far. Does anybody have any ideas about how I might be able to prove this? Thank you kindly, Alex Warth From Pierre.Letouzey at !NS! pps.jussieu.fr Wed May 31 12:35:54 2006 From: Pierre.Letouzey at !NS! pps.jussieu.fr (Pierre Letouzey) Date: Wed, 31 May 2006 13:35:54 +0200 Subject: [Coq-Club]help with simple proof In-Reply-To: References: Message-ID: <20060531113554.GC30063@uranium.pps.jussieu.fr> On Tue, May 30, 2006 at 05:04:35PM -0700, Alessandro Warth wrote: > Hello, > > Inductive AType : Set := > | Red : nat -> AType > | Black : nat -> AType. > > Inductive subtyping : AType -> AType -> Prop := > | s_refl : forall T, > subtyping T T > | s_trans : forall T1 T2 T3, > subtyping T1 T2 -> > subtyping T2 T3 -> > subtyping T1 T3. > > Lemma l : forall (n:nat) (T:AType), > subtyping (Red n) T -> > exists m:nat, T = (Red m). > You can proceed by induction over the subtyping hypothesis. The pitfall is that you should do it directly, since coq would forget that the first argument of subtyping is of the form (Red n). So you need to store that information: Lemma l' : forall (T0 T:AType), subtyping T0 T -> forall n, T0 = Red n -> exists m:nat, T = (Red m). Proof. induction 1. intros; exists n; auto. intros. destruct (IHsubtyping1 _ H1) as (m,Hm). destruct (IHsubtyping2 _ Hm) as (p,Hp). exists p; auto. Qed. Lemma l : forall (n:nat) (T:AType), subtyping (Red n) T -> exists m:nat, T = (Red m). Proof. intros. destruct (l' (Red n) T H n) as (m,Hm); auto. exists m; auto. Qed. Best regards, Pierre Letouzey From anoun at !NS! labri.fr Wed May 31 12:36:03 2006 From: anoun at !NS! labri.fr (Houda Anoun) Date: Wed, 31 May 2006 13:36:03 +0200 Subject: [Coq-Club]help with simple proof In-Reply-To: References: Message-ID: <20060531133603.sxbb9rz74swg4g4w@webmail.labri.fr> Hello Alessandro, I am not sure that the inductive type 'subtyping' really reflects what you want to express. In fact, we can easily prove the following lemma: Lemma sub_cst: forall T1 T2, subtyping T1 T2 -> T1 = T2. induction 1. auto. rewrite IHsubtyping1; auto. Qed. so this predicate only relates two equal AType, its second constructor (s_trans) is then useless. Concerning your lemma, it can be straightforwardly proved using the lemma above Lemma l : forall (n:nat) (T:AType), subtyping (Red n) T -> exists m:nat, T = (Red m). intros. rewrite <- (sub_cst _ _ H). exists n. auto. Qed. Hope this helps! Regards, Houda > Hello, > > I'm trying to use Coq to formalize a programming language that I've > been working on. Unfortunately, a few days ago I ran into trouble > while proving what (I think) should be a very simple lemma. I've spent > the past few days banging my head against the wall and have made no > progress, so I was hoping someone might be able to give me a few > pointers... > > Here is the simplest formulation of that lemma that I could come up with: > > > Inductive AType : Set := > | Red : nat -> AType > | Black : nat -> AType. > > Inductive subtyping : AType -> AType -> Prop := > | s_refl : forall T, > subtyping T T > | s_trans : forall T1 T2 T3, > subtyping T1 T2 -> > subtyping T2 T3 -> > subtyping T1 T3. > > Lemma l : forall (n:nat) (T:AType), > subtyping (Red n) T -> > exists m:nat, T = (Red m). > > > This should be easy to prove, but I haven't had any luck so far. Does > anybody have any ideas about how I might be able to prove this? > > Thank you kindly, > Alex Warth > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 =============================== Houda Anoun Bordeaux1-LaBRI-Signes phone:05 40 00 35 15 web: www.labri.fr/perso/anoun ++++++++++++++ Electric lamps were not invented by improving candles ================================= ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From pierre.casteran at !NS! labri.fr Wed May 31 12:40:39 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Wed, 31 May 2006 13:40:39 +0200 Subject: [Coq-Club]help with simple proof In-Reply-To: References: Message-ID: <447D80B7.7060300@labri.fr> Hi, Alessandro Warth wrote: > Hello, > > I'm trying to use Coq to formalize a programming language that I've > been working on. Unfortunately, a few days ago I ran into trouble > while proving what (I think) should be a very simple lemma. I've spent > the past few days banging my head against the wall and have made no > progress, so I was hoping someone might be able to give me a few > pointers... > > Here is the simplest formulation of that lemma that I could come up with: > > > Inductive AType : Set := > | Red : nat -> AType > | Black : nat -> AType. > > Inductive subtyping : AType -> AType -> Prop := > | s_refl : forall T, > subtyping T T > | s_trans : forall T1 T2 T3, > subtyping T1 T2 -> > subtyping T2 T3 -> > subtyping T1 T3. The subtyping relation you describe is the least reflexive and transitive relation, hence the identity over AType. Lemma L0 : forall (T T1:AType), subtyping T T1 -> T = T1. Proof. induction 1. auto. transitivity T2;[assumption | symmetry;auto]. Qed. So, your lemma follows directly: Lemma l : forall (n:nat) (T:AType), subtyping (Red n) T -> exists m:nat, T = (Red m). Proof. intros n T; exists n;symmetry;apply L0. assumption. Qed. I guess this is not the relation you meant. You need perhaps the reflexive end transitive closure of some simple relation defined on AType. Am I right ? Hope this helps, Pierre > > Lemma l : forall (n:nat) (T:AType), > subtyping (Red n) T -> > exists m:nat, T = (Red m). > > > This should be easy to prove, but I haven't had any luck so far. Does > anybody have any ideas about how I might be able to prove this? > > Thank you kindly, > Alex Warth > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 alexwarth at !NS! gmail.com Wed May 31 19:52:01 2006 From: alexwarth at !NS! gmail.com (Alessandro Warth) Date: Wed, 31 May 2006 11:52:01 -0700 Subject: [Coq-Club]help with simple proof In-Reply-To: <20060531113554.GC30063@uranium.pps.jussieu.fr> References: <20060531113554.GC30063@uranium.pps.jussieu.fr> Message-ID: ------=_Part_4943_21220160.1149101521415 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks, Pierre - that was exactly what I was looking for. Although I still need to learn more about how things work in Coq, your technique worked beautifully for my proof. Thanks again, this is a big help. Cheers, Alex Warth On 5/31/06, Pierre Letouzey wrote: > > On Tue, May 30, 2006 at 05:04:35PM -0700, Alessandro Warth wrote: > > Hello, > > > > Inductive AType : Set := > > | Red : nat -> AType > > | Black : nat -> AType. > > > > Inductive subtyping : AType -> AType -> Prop := > > | s_refl : forall T, > > subtyping T T > > | s_trans : forall T1 T2 T3, > > subtyping T1 T2 -> > > subtyping T2 T3 -> > > subtyping T1 T3. > > > > Lemma l : forall (n:nat) (T:AType), > > subtyping (Red n) T -> > > exists m:nat, T = (Red m). > > > > You can proceed by induction over the subtyping hypothesis. > The pitfall is that you should do it directly, since coq would > forget that the first argument of subtyping is of the form (Red n). > So you need to store that information: > > Lemma l' : forall (T0 T:AType), > subtyping T0 T -> > forall n, T0 = Red n -> > exists m:nat, T = (Red m). > Proof. > induction 1. > intros; exists n; auto. > intros. > destruct (IHsubtyping1 _ H1) as (m,Hm). > destruct (IHsubtyping2 _ Hm) as (p,Hp). > exists p; auto. > Qed. > > Lemma l : forall (n:nat) (T:AType), > subtyping (Red n) T -> > exists m:nat, T = (Red m). > Proof. > intros. > destruct (l' (Red n) T H n) as (m,Hm); auto. > exists m; auto. > Qed. > > Best regards, > > Pierre Letouzey > ------=_Part_4943_21220160.1149101521415 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks, Pierre - that was exactly what I was looking for. Although I still need to learn more about how things work in Coq, your technique worked beautifully for my proof. Thanks again, this is a big help.

Cheers,
Alex Warth

On 5/31/06, Pierre Letouzey <Pierre.Letouzey@pps.jussieu.fr> wrote:

On Tue, May 30, 2006 at 05:04:35PM -0700, Alessandro Warth wrote:
> Hello,
>
> Inductive AType : Set :=
> | Red : nat -> AType
> | Black : nat -> AType.
>
> Inductive subtyping : AType -> AType -> Prop :=
> | s_refl   : forall T,
>                subtyping T T
> | s_trans  : forall T1 T2 T3,
>                subtyping T1 T2 ->
>                subtyping T2 T3 ->
>                subtyping T1 T3.
>
> Lemma l : forall (n:nat) (T:AType),
>            subtyping (Red n) T ->
>            exists m:nat, T = (Red m).
>

You can proceed by induction over the subtyping hypothesis.
The pitfall is that you should do it directly, since coq would
forget that the first argument of subtyping is of the form (Red n).
So you need to store that information:

Lemma l' : forall (T0 T:AType),
           subtyping T0 T ->
           forall n, T0 = Red n ->
           exists m:nat, T = (Red m).
Proof.
induction 1.
intros; exists n; auto.
intros.
destruct (IHsubtyping1 _ H1) as (m,Hm).
destruct (IHsubtyping2 _ Hm) as (p,Hp).
exists p; auto.
Qed.

Lemma l : forall (n:nat) (T:AType),
           subtyping (Red n) T ->
           exists m:nat, T = (Red m).
Proof.
intros.
destruct (l' (Red n) T H n) as (m,Hm); auto.
exists m; auto.
Qed.

Best regards,

Pierre Letouzey

------=_Part_4943_21220160.1149101521415-- From as at !NS! cynox.ch Tue Jun 6 10:54:52 2006 From: as at !NS! cynox.ch (Alex Suzuki) Date: Tue, 06 Jun 2006 11:54:52 +0200 Subject: [Coq-Club]Mutually dependent types Message-ID: <448550EC.6090003@cynox.ch> Hello list, I'm a CS student at ETH Zurich and I'm using Coq to formalize a translation from Java Bytecode to a guarded command language used for verification. This is probably not the last question regarding Coq from my side. ;-) When a situation arises where we have types that depend on each other, how do you do write this in Coq? Inductive A: Set := | A1 | A2 (x: B). Inductive B: Set := | B1 | B2 (x: A). This will not work as Coq will complain that the reference B was not found in the current environment. Is there some way to "forward declare" type B, or am I doing something very wrong? :) Regards, Alex -- Alex Suzuki | as@cynox.ch | http://n.ethz.ch/student/asuzuki Most people are other people. Their thoughts are someone else's opinions, their lives a mimicry, their passions a quotation. - Oscar Wilde From pierre.casteran at !NS! labri.fr Tue Jun 6 12:42:03 2006 From: pierre.casteran at !NS! labri.fr (Pierre Casteran) Date: Tue, 06 Jun 2006 13:42:03 +0200 Subject: [Coq-Club]Mutually dependent types In-Reply-To: <448550EC.6090003@cynox.ch> References: <448550EC.6090003@cynox.ch> Message-ID: <44856A0B.5020703@labri.fr> Hello Alex, You can use "Inductive ... with " for defining simultaneously two inductive types: Inductive A: Set := a : A | f : B -> A with B : Set := g : A -> B. Similarly you can define mutually recursive functions. Fixpoint size (x:A) : nat := match x with a => 0 | f b => S (sizeB b) end with sizeB (y:B) : nat := match y with g x => S (size x) end. Eval compute in (size (f (g a))). 2 For doing proofs by mutuial induction, use the command Scheme (an example is given in the reference manual (trees and forests)). Pierre Alex Suzuki wrote: > Hello list, > > I'm a CS student at ETH Zurich and I'm using Coq to formalize a > translation from Java Bytecode to a guarded command language used > for verification. This is probably not the last question regarding > Coq from my side. ;-) > > When a situation arises where we have types that depend on each > other, how do you do write this in Coq? > > Inductive A: Set := > | A1 > | A2 (x: B). > > Inductive B: Set := > | B1 > | B2 (x: A). > > This will not work as Coq will complain that the reference B was > not found in the current environment. Is there some way to > "forward declare" type B, or am I doing something very wrong? :) > > Regards, > Alex From lionel at !NS! mamane.lu Tue Jun 6 12:49:53 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Tue, 6 Jun 2006 13:49:53 +0200 Subject: [Coq-Club]Mutually dependent types In-Reply-To: <448550EC.6090003@cynox.ch> References: <448550EC.6090003@cynox.ch> Message-ID: <20060606114953.GA21106@capsaicin.mamane.lu> On Tue, Jun 06, 2006 at 11:54:52AM +0200, Alex Suzuki wrote: > When a situation arises where we have types that depend on each > other, how do you do write this in Coq? These are mutually inductive types and get written as Inductive A: Set := | A1 | A2 (x: B) with B: Set := | B1 | B2 (x: A). -- Lionel From as at !NS! cynox.ch Tue Jun 6 13:40:16 2006 From: as at !NS! cynox.ch (Alex Suzuki) Date: Tue, 06 Jun 2006 14:40:16 +0200 Subject: [Coq-Club]Mutually dependent types In-Reply-To: <44856A0B.5020703@labri.fr> References: <448550EC.6090003@cynox.ch> <44856A0B.5020703@labri.fr> Message-ID: <448577B0.7060807@cynox.ch> Pierre Casteran wrote: > Hello Alex, > > You can use "Inductive ... with " for defining simultaneously two > inductive types: > [...] Thanks alot! This goes for all who replied. :-) Regards, Alex -- Alex Suzuki | as@cynox.ch | http://n.ethz.ch/student/asuzuki Most people are other people. Their thoughts are someone else's opinions, their lives a mimicry, their passions a quotation. - Oscar Wilde From nouvid-coq at !NS! yahoo.fr Wed Jun 7 02:16:07 2006 From: nouvid-coq at !NS! yahoo.fr (Fabrice Lemercier) Date: Wed, 7 Jun 2006 03:16:07 +0200 (CEST) Subject: [Coq-Club]Type system in Coq Message-ID: <20060607011607.48555.qmail@web25904.mail.ukl.yahoo.com> Hello, I am formalizing a language and its type system in Coq. Follow a simple example which is sufficient to exhibit my problem. The syntax of my language (consisting of just one constant) is given by the following inductive definition: Inductive Trm : Set := trm : Trm. There is only one typing rules (stating that my constant is well typed) given by: Inductive Typ : Trm->Set := axiom : Typ trm. Now, I'd like to prove a fundamental property of my type system which is that for each term there is a unique type derivation: Goal forall t:Trm, forall x y:Typ t, x=y. I know that if I put Typ in Prop instead of Set, then I can prove the above statement by using proof irrelevance in classical logic. But I put them in Set because I want them to be extracted. What can I do? Thanks, Fabrice __________________________________________________ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail From lionel at !NS! mamane.lu Wed Jun 7 06:57:11 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Wed, 7 Jun 2006 07:57:11 +0200 Subject: [Coq-Club]Type system in Coq In-Reply-To: <20060607011607.48555.qmail@web25904.mail.ukl.yahoo.com> References: <20060607011607.48555.qmail@web25904.mail.ukl.yahoo.com> Message-ID: <20060607055711.GC27782@capsaicin.mamane.lu> On Wed, Jun 07, 2006 at 03:16:07AM +0200, Fabrice Lemercier wrote: > I am formalizing a language and its type system in > Coq. Follow a simple example which is sufficient to > exhibit my problem. > Inductive Trm : Set := > trm : Trm. > Inductive Typ : Trm->Set := > axiom : Typ trm. > Goal forall t:Trm, forall x y:Typ t, x=y. Definition canon : forall (t:Trm), Typ t. intros []. exact axiom. Defined. Lemma a: forall x:Typ trm, x= (canon trm). intros []. reflexivity. Qed. Lemma b:forall t:Trm, forall x y:Typ t, x=y. intros [] [] y. rewrite (a y). reflexivity. Qed. -- Lionel From nouvid-coq at !NS! yahoo.fr Wed Jun 7 13:09:52 2006 From: nouvid-coq at !NS! yahoo.fr (Fabrice Lemercier) Date: Wed, 7 Jun 2006 14:09:52 +0200 (CEST) Subject: [Coq-Club]Type system in Coq In-Reply-To: <20060607055711.GC27782@capsaicin.mamane.lu> Message-ID: <20060607120952.41595.qmail@web25912.mail.ukl.yahoo.com> Hello, Thank you for the reply. Unfortunately my example was too simplified compare to the original type system I am dealing with. Here is a less simplified version. Can you prove the goal? Inductive Trm : Set := trm : nat->Trm. Inductive Typ : Trm*nat->Set := axiom : forall n, Typ (trm n, n). Goal forall t:Trm, forall n, forall x y:Typ (t,n), x=y. Fabrice P.S. I also found that I can prove the goal in my previous mail by using dependent equality, but it is not enough to prove the above goal. Require Export Eqdep. Inductive Trm : Set := trm : Trm. Inductive Typ : Trm->Set := axiom : Typ trm. Goal forall t:Trm, forall x y:Typ t, x=y. induction t. intros. apply (eq_dep_eq Trm Typ). induction x. induction y. apply eq_dep_intro. __________________________________________________ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail From Roland.Zumkeller at !NS! polytechnique.fr Wed Jun 7 16:50:19 2006 From: Roland.Zumkeller at !NS! polytechnique.fr (Roland Zumkeller) Date: Wed, 7 Jun 2006 17:50:19 +0200 Subject: [Coq-Club]Type system in Coq In-Reply-To: <20060607120952.41595.qmail@web25912.mail.ukl.yahoo.com> References: <20060607120952.41595.qmail@web25912.mail.ukl.yahoo.com> Message-ID: On Jun 7, 2006, at 2:09 PM, Fabrice Lemercier wrote: > Unfortunately my example was > too simplified compare to the original type system I > am dealing with. Here is a less simplified version. > Can you prove the goal? > > Inductive Trm : Set := > trm : nat->Trm. > > Inductive Typ : Trm*nat->Set := > axiom : forall n, Typ (trm n, n). You'll need to provide an elimination predicate. Think of "eq_rec" as a type cast here. To get rid of it one can use Streicher's axiom K, which happens to be verified by types with decidable equality. > Goal forall t:Trm, forall n, forall x y:Typ (t,n), x=y. intros; refine( match x as x0 in Typ tn0, y as y0 in Typ tn1 return forall (H:tn0=tn1), eq_rec _ Typ x0 _ H = y0 with | axiom _, axiom _ => fun H => _ end (refl_equal _)). generalize H. inversion H. Require Import Eqdep_dec. intros; pattern H0; apply K_dec_set. repeat (decide equality). apply refl_equal. Qed. However this is likely to become rather complicated when you try to prove more interesting things. If you tell us a little more about your type system, perhaps someone could suggest a different way to do describe it in Coq. Best, Roland -- http://www.lix.polytechnique.fr/~zumkeller/ From lionel at !NS! mamane.lu Wed Jun 7 17:15:57 2006 From: lionel at !NS! mamane.lu (Lionel Elie Mamane) Date: Wed, 7 Jun 2006 18:15:57 +0200 Subject: [Coq-Club]Type system in Coq In-Reply-To: <20060607120952.41595.qmail@web25912.mail.ukl.yahoo.com> References: <20060607055711.GC27782@capsaicin.mamane.lu> <20060607120952.41595.qmail@web25912.mail.ukl.yahoo.com> Message-ID: <20060607161557.GA31993@capsaicin.mamane.lu> On Wed, Jun 07, 2006 at 02:09:52PM +0200, Fabrice Lemercier wrote: > Thank you for the reply. Unfortunately my example was > too simplified compare to the original type system I > am dealing with. Here is a less simplified version. > Can you prove the goal? I've a solution using Streicher's axiom K, which is a theorem on types whose equality is decidable. I think it is morally the same as Roland's, but then much more verbose and maybe more clumsy. I find it easier to understand, though. dec_eq_dadep is left as an exercise to the reader. Inductive Trm : Set := trm : nat->Trm. Inductive Typ : Trm*nat->Set := axiom : forall n, Typ (trm n, n). Require Import Eqdep_dec. Require Import Peano_dec. Definition cast : forall (p p':Trm*nat), p=p' -> (Typ p) -> Typ p'. intros p p' pp'. rewrite pp'. intros I; exact I. Defined. Lemma dec_eq_dadep:forall p p':Trm*nat, Decidable.decidable (p = p'). Admitted. Lemma a: forall (p:Trm*nat)(x:Typ p)(p':Trm*nat)(y:Typ p')(pp':p=p'), (cast _ _ pp' x) = y. intros p x. dependent inversion x; subst. intros p' y. dependent inversion y; subst. rename n0 into m. intros pp'. inversion pp'; subst. eapply K_dec with (P:=fun pp' => cast _ _ pp' (axiom m) = axiom m). apply dec_eq_dadep. reflexivity. Qed. Goal forall t:Trm, forall n, forall x y:Typ (t,n), x=y. intros. apply a with (pp':=refl_equal (t,n)) (x:=x). Qed. -- Lionel From blanqui at !NS! loria.fr Thu Jun 8 16:48:28 2006 From: blanqui at !NS! loria.fr (Frederic Blanqui) Date: Thu, 8 Jun 2006 17:48:28 +0200 (CEST) Subject: [Coq-Club]Type system in Coq In-Reply-To: <20060607120952.41595.qmail@web25912.mail.ukl.yahoo.com> References: <20060607120952.41595.qmail@web25912.mail.ukl.yahoo.com> Message-ID: you can perhaps find some help by looking at CoLoR, the Coq library on rewriting and termination at http://color.loria.fr/, in Adam Koprowski's formalization of simply-typed lambda-calculus. see in particular the file TermsTyping. From eelis at !NS! eelis.net Sun Jun 4 14:49:36 2006 From: eelis at !NS! eelis.net (Eelis van der Weegen) Date: Sun, 4 Jun 2006 15:49:36 +0200 (CEST) Subject: [Coq-Club]Problems proving equality of proof terms of inductively defined predicate. Message-ID: <37851.213.84.80.149.1149428976.squirrel@webmail.nxs.nl> Greetings. Is the following provable? If it is, how? If it isn't, why not? : Inductive P : nat -> Prop := C0 : P 0 | C1 : P 1. Theorem A: forall (x: P 0), x = C0. As soon as I try to do case analysis or induction on x with the intention to reveal that it can only be C0, I get "Cannot solve a second-order unification problem". Coq Faq item 171 suggests helping Coq using the "pattern" tactic, but I can't find a way to do that here. I've also tried rephrasing the equality using Eqdep, but always seem to end up with the same problem as above. Had P been of type nat -> Set I could have used JMeq: Require Import JMeq. Inductive P : nat -> Set := C0 : P 0 | C1 : P 1. Lemma H: forall (n: nat) (x: P n), n = 0 -> JMeq x C0. Proof. induction x. reflexivity. intro. discriminate. Qed. Theorem B: forall (x: P 0), x = C0. Proof. intro. apply JMeq_eq. apply H. reflexivity. Qed. However, JMeq doesn't seem to work for things in Prop. As a side note, if there's a proof of B that does not rely on JMeq (and its axiom) I'd also be very interested in that. Any help is appreciated. Thanks, Eelis From Charles.Bouillaguet at !NS! crans.org Tue Jun 6 11:59:43 2006 From: Charles.Bouillaguet at !NS! crans.org (Charles Bouillaguet) Date: Tue, 06 Jun 2006 06:59:43 -0400 Subject: [Coq-Club]Mutually dependent types In-Reply-To: <448550EC.6090003@cynox.ch> References: <448550EC.6090003@cynox.ch> Message-ID: <4485601F.9070101@crans.org> Hi, I think that what you want is : Inductive A: Set := | A1 | A2 (x: B) with B: Set := | B1 | B2 (x: A). You may also want to define mutually recursive induction principle. You should probably read the section 10.3, about "Scheme" in the reference manual. You'll find some example there, too. Good luck ! Charles Bouillaguet Alex Suzuki wrote: > Hello list, > > I'm a CS student at ETH Zurich and I'm using Coq to formalize a > translation from Java Bytecode to a guarded command language used > for verification. This is probably not the last question regarding > Coq from my side. ;-) > > When a situation arises where we have types that depend on each > other, how do you do write this in Coq? > > Inductive A: Set := > | A1 > | A2 (x: B). > > Inductive B: Set := > | B1 > | B2 (x: A). > > This will not work as Coq will complain that the reference B was > not found in the current environment. Is there some way to > "forward declare" type B, or am I doing something very wrong? :) > > Regards, > Alex From szanella at !NS! fceia.unr.edu.ar Wed Jun 7 04:49:30 2006 From: szanella at !NS! fceia.unr.edu.ar (=?iso-8859-1?Q?Santiago_Zanella_B=E9guelin?=) Date: Wed, 7 Jun 2006 00:49:30 -0300 Subject: [Coq-Club]Type system in Coq References: <20060607011607.48555.qmail@web25904.mail.ukl.yahoo.com> Message-ID: <001301c689e5$67669510$dc2675c8@A> Fabrice, I think the problem is that the induction principle Coq generates for your definiton of Typ cannot be used to prove your goal: Typ_ind : forall P : forall t : Trm, Typ t -> Prop, P trm axiom -> forall (t : Trm) (t0 : Typ t), P t t0 In order to apply this induction principle in your goal, a predicate of the form (fun (t:Trm)(x:Typ t) => x = axiom) may eventually have to be constructed. Such a predicate cannot be typed because the Coq type system is not able to determine that x must have type Typ trm (although it can be proved). You may either (1) restate your definition of Typ, (2) use dependent equality, or (3) assume an ad hoc induction principle. It seems you should go for (1). (1) Inductive Typ : Trm->Set := axiom : forall t:Trm, Typ t. Goal forall t:Trm, forall x y:Typ t, x=y. destruct x; induction y; trivial. (2) See the Coq.Logic.Eqdep library. Require Import Eqdep. Inductive Trm : Set := trm : Trm. Inductive Typ : Trm->Set := axiom : Typ trm. Lemma dep_eq : forall t:Trm, forall x y:Typ t, eq_dep Trm Typ t x t y. destruct x; destruct y; trivial. Qed. Goal forall t:Trm, forall x y:Typ t, x = y. intros t x y; exact (eq_dep_eq Trm Typ t x y (dep_eq t x y)). (3) Axiom Typ_trm_ind : forall P : Typ trm -> Prop, P axiom -> forall (x : Typ trm), P x. Goal forall t:Trm, forall x y:Typ t, x=y. destruct x; apply Typ_trm_ind; trivial. Hope this helps, -- Santiago Zanella Béguelin ----- Original Message ----- From: "Fabrice Lemercier" To: Sent: Tuesday, June 06, 2006 10:16 PM Subject: [Coq-Club]Type system in Coq > Hello, > > I am formalizing a language and its type system in > Coq. Follow a simple example which is sufficient to > exhibit my problem. > > The syntax of my language (consisting of just one > constant) is given by the following inductive > definition: > > Inductive Trm : Set := > trm : Trm. > > There is only one typing rules (stating that my > constant is well typed) given by: > > Inductive Typ : Trm->Set := > axiom : Typ trm. > > Now, I'd like to prove a fundamental property of my > type system which is that for each term there is a > unique type derivation: > > Goal forall t:Trm, forall x y:Typ t, x=y. > > I know that if I put Typ in Prop instead of Set, then > I can prove the above statement by using proof > irrelevance in classical logic. But I put them in Set > because I want them to be extracted. What can I do? > > Thanks, > > Fabrice > > > > > __________________________________________________ > Do You Yahoo!? > En finir avec le spam? Yahoo! Mail vous offre la meilleure protection > possible contre les messages non sollicités > http://mail.yahoo.fr Yahoo! Mail > > -------------------------------------------------------- > Bug reports: http://coq.inria.fr/bin/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 david.nowak at !NS! aist.go.jp Fri Jun 9 03:13:45 2006 From: david.nowak at !NS! aist.go.jp (David Nowak) Date: Fri, 09 Jun 2006 11:13:45 +0900 Subject: [Coq-Club]Problems proving equality of proof terms of inductively defined predicate. In-Reply-To: <37851.213.84.80.149.1149428976.squirrel@webmail.nxs.nl> References: <37851.213.84.80.149.1149428976.squirrel@webmail.nxs.nl> Message-ID: <4488D959.2000006@aist.go.jp> Hi Eelis, You can prove Abis below which is a bit more general than A and then apply it. eq_rect is used to convince Coq that, because 0=n, C0 in also of type P n. Require Export Eqdep_dec. Inductive P : nat -> Prop := C0 : P 0 | C1 : P 1. Lemma Abis : forall n (x : P n) (p : 0 = n), x = eq_rect 0 P C0 n p. Proof. intros n x. case x. intro. pattern p in |- *. apply K_dec_set. decide equality. reflexivity. intro. absurd (0 = 1). discriminate. assumption. Qed. Theorem A: forall (x: P 0), x = C0. Proof. intro. apply (Abis 0 x (refl_equal 0)). Qed. Eelis van der Weegen a écrit : > Greetings. > > Is the following provable? If it is, how? If it isn't, why not? : > > Inductive P : nat -> Prop := C0 : P 0 | C1 : P 1. > > Theorem A: forall (x: P 0), x = C0. David -- David Nowak http://staff.aist.go.jp/david.nowak/ From Roland.Zumkeller at !NS! polytechnique.fr Thu Jun 8 17:11:21 2006 From: Roland.Zumkeller at !NS! polytechnique.fr (Roland Zumkeller) Date: Thu, 8 Jun 2006 18:11:21 +0200 Subject: [Coq-Club]Problems proving equality of proof terms of inductively defined predicate. In-Reply-To: <37851.213.84.80.149.1149428976.squirrel@webmail.nxs.nl> References: <37851.213.84.80.149.1149428976.squirrel@webmail.nxs.nl> Message-ID: On 04/06/06, Eelis van der Weegen wrote: > Is the following provable? If it is, how? If it isn't, why not? : > > Inductive P : nat -> Prop := C0 : P 0 | C1 : P 1. This is almost the same problem that Fabrice encountered yesterday, so I can copy my code: > Theorem A: forall (x: P 0), x = C0. intros; refine( match x as x0 return forall H, eq_rect _ P x0 _ H = C0 with | C0 => _ | C1 => _ end (refl_equal _)). Require Import Eqdep_dec. intros; pattern H; apply K_dec_set. decide equality. apply refl_equal. intros; discriminate. Qed. Best, Roland -- http://www.lix.polytechnique.fr/~zumkeller/ From ethan.aubin at !NS! gmail.com Sat Jun 10 15:39:59 2006 From: ethan.aubin at !NS! gmail.com (Ethan Aubin) Date: Sat, 10 Jun 2006 10:39:59 -0400 Subject: [Coq-Club]conversion tactics Message-ID: <9760dc1c0606100739i57b0d894s2ffee347bb1cfe8b@mail.gmail.com> Hi, Is it possible to perform a single step of delta/beta/etc reduction via a tactic? Is the evaulation order of the conversion tactics (or CiC) specified? Also, whats the best forum to ask novice questions? Thanks - Ethan From Pierre.Courtieu at !NS! cnam.fr Tue Jun 13 14:40:47 2006 From: Pierre.Courtieu at !NS! cnam.fr (Pierre Courtieu) Date: Tue, 13 Jun 2006 15:40:47 +0200 Subject: [Coq-Club]conversion tactics In-Reply-To: <9760dc1c0606100739i57b0d894s2ffee347bb1cfe8b@mail.gmail.com> References: <9760dc1c0606100739i57b0d894s2ffee347bb1cfe8b@mail.gmail.com> Message-ID: <20060613154047.06d7e4e8@centaur.cnam.fr> On Sat, 10 Jun 2006 10:39:59 -0400 "Ethan Aubin" wrote: > Hi, Is it possible to perform a single step of delta/beta/etc > reduction via a tactic? Is the evaulation order of the conversion > tactics (or CiC) specified? Also, whats the best forum to ask novice > questions? Thanks - Ethan You have cbv and lazy which perform "small" reduction steps, but generally not atomic steps. See the online documentation -> tactic index, look for "cbv". I am not sure there is something closer to what you are looking. You can give arguments to delta to target a particular constant. Hope this helps, Pierre From miculan at !NS! dimi.uniud.it Wed Jun 14 08:15:17 2006 From: miculan at !NS! dimi.uniud.it (Marino Miculan) Date: Wed, 14 Jun 2006 09:15:17 +0200 Subject: [Coq-Club]IFIP WG 2.2 Anniversary Meeting - Call for Participation Message-ID: Please post. -m ======================================================= CALL FOR PARTICIPATION FORMAL DESCRIPTION OF PROGRAMMING CONCEPTS: IFIP WG 2.2 Anniversary Meeting 11-13 September 2006 Udine, Italy http://www.dimi.uniud.it/ifip06/ The IFIP Working Group 2.2 was established in 1965 as one of the first IFIP Working Groups. The primary aim of the WG is to explain programming concepts through the development, examination and comparison of various formal models of these concepts. The WG thus explores the theory and the practice of formal methods for the specification, verification and the design of software and systems. Earliest members of the WG included Dana Scott, Erwin Engeler, Jaco de Bakker, Raymond Abrial, Peter Lauer, Manfred Paul, Erich Neuhold, Maurice Nivat, Ed Blum. Throughout the years, members of the WG shaped various styles of semantics, comprising denotational, operational, algebraic, and logical semantics. The anniversary meeting commemorates the 40-th birthday of WG. In the meeting, a number of keynote speakers and current members of the WG will give tutorial presentations on topics relevant to the WG, focusing on history (of these topics, or of the WG), but also on current outlook and future developments. Keynote speakers: Amir Pnueli, Igor Walukiewicz, and Ernst-Rudiger Olderog (as current WG members), Dana Scott, Manfred Paul, and Hans Langmaack (as founding WG members), Leslie Lamport and Gordon Plotkin (as past WG members) . Registration ~~~~~~~~~~~~ Registration to the meeting is possible at http://www.dimi.uniud.it/ifip06/registration.html The meeting fee is 120 Euros until 31 July 2006. After that date, and until 31 August 2006, the fee will be 150 Euros. After then, no registrations will be accepted. The workshop fee includes lunches, coffee-breaks, the social dinner and the excursion on Sunday afternoon. Preliminary Programme and Speakers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sunday 10 September, afternoon Excursion: San Daniele countryside (and ham) Monday 11 September * 09.00-10.00: Amir Pnueli * 10.00-10.30: coffee break * 10.30-11.30: Hans Langmaack * 11.30-12.00: Maciej Koutny * 12.00-14.00: lunch * 14.00-15.00: Igor Walukiewicz * 15.00-15.30: coffee break * 15.30-16.30: Ugo Montanari * 16.30-17.00: Catuscia Palamidessi * 17.00-17.30: Andrzej Tarlecki * 17.30-18.00: Rocco De Nicola Tuesday 12 September * 09.00-10.00: Gordon Plotkin * 10.00-10.30: coffee break * 10.30-11.30: local speaker * 11.30-12.00: Mariangiola Dezani * 12.00-14.00: lunch * 14.00-15.00: Dana Scott * 15.00-15.30: coffee break * 15.30-16.30: Egon Boerger * 16.30-17.00: Markus Muller-Olm * 20.00- : Social Dinner Wednesday 13 September * 09.00-10.00: Leslie Lamport * 10.00-10.30: coffee break * 10.30-11.00: Manfred Paul * 11.00-11.30: J Strother Moore * 11.30-12.00: Peter Mosses * 12.00-14.00: lunch * 14.00-15.00: Ernst-Rudiger Olderog * 15.00-15.30: coffee break * 15.30-16.30: Shigeru Igarashi * 16.30-17.00: Stephan Merz * 17.00-17.30: Anders P. Ravn * 17.30-18.00: Philippe Darondeau From mulhern at !NS! gmail.com Fri Jun 16 21:13:45 2006 From: mulhern at !NS! gmail.com (mulhern) Date: Fri, 16 Jun 2006 15:13:45 -0500 Subject: [Coq-Club]Equality modulo proofs Message-ID: <54f15b6e0606161313s1e4ab734xda417f601d5d69e7@mail.gmail.com> Hi! I've been using dependent types to specify properties of various things. So, for example, I might use the Inductive type sig and construct inhabitants of that type using the exist constructor. But when checking equality between two inhabitants I want to check only the equality of the witnesses, not equality of the proof that each witness satisfies that property. I find myself forced to define equality in the way I need for every such type that arises. Here is an example below. Inductive equal_mod_sig (B : Set) (P : B -> Prop) (equalB : B -> B -> Prop) : si g P -> sig P -> Prop := | Equal_mod_sig : forall (b b' : B) (p : P b) (p' : P b'), equalB b b' -> equal_mod_sig equalB (exist P b p) (exist P b' p'). Then I prove that if equality between the witnesses is decidable then my equality is decidable. Lemma equal_mod_sig_dec : forall (B : Set) (P : B -> Prop) (equalB : B -> B -> P rop), (forall (b b' : B), {equalB b b'} + {~ (equalB b b')}) -> (forall (s s' : sig P), {equal_mod_sig equalB s s'} + {~ (equal_mod_sig equ alB s s')}). .... Is there a general way to ignore proofs when deciding equality...or is my current approach actually necessary? Note that this arises in multiple other contexts as well, this is just one example. Also, it gets a little more tedious since I want to prove that each equality that I have so defined is in fact an equivalence relation. -mulhern From adamc at !NS! cs.berkeley.edu Fri Jun 16 21:26:32 2006 From: adamc at !NS! cs.berkeley.edu (Adam Chlipala) Date: Fri, 16 Jun 2006 13:26:32 -0700 Subject: [Coq-Club]Equality modulo proofs In-Reply-To: <54f15b6e0606161313s1e4ab734xda417f601d5d69e7@mail.gmail.com> References: <54f15b6e0606161313s1e4ab734xda417f601d5d69e7@mail.gmail.com> Message-ID: <449313F8.7060603@cs.berkeley.edu> mulhern wrote: > Is there a general way to ignore proofs when deciding equality...or is > my current approach actually necessary? If you are willing to tolerate an axiom, then the Eqdep module of the standard library provides proof irrelevance for equality: http://coq.inria.fr/library/Coq.Logic.Eqdep.html That is, its UIP lemma uses the axiom to show that any two proofs of the same equality fact are equal. You can use the lemma in justifying the correctness of equality decision procedures that ignore proof components. From Gilles.Barthe at !NS! sophia.inria.fr Thu Jun 15 10:41:08 2006 From: Gilles.Barthe at !NS! sophia.inria.fr (Gilles Barthe) Date: Thu, 15 Jun 2006 11:41:08 +0200 Subject: [Coq-Club]post-doctoral position in formal security at INRIA Message-ID: <44912B34.2070201@sophia.inria.fr> Applications are invited for a post-doctoral position on formal security within the EVEREST project (http://www-sop.inria.fr/everest/) at INRIA Sophia-Antipolis. The position is initially for 2 years, with the possibility of 1 year extension; the preferred starting date is October 2006. We are looking for candidates with a strong research background in formal security. The team is active in the following areas: - language-based security - program logics for security - proof-carrying code - provable cryptography Applications consisting of a CV with names of three referees to Nathalie.Bellesso@sophia.inria.fr preferably before July, 15st 2006. If you wish to apply after this date, please send an email for enquiring whether the position remains open. Potential candidates are welcome to contact me by email for any informal enquiry concerning the position. Gilles Barthe ===================================================== Everest Team, INRIA Sophia-Antipolis 2004 Route des Lucioles BP 93, 06902 Sophia Antipolis Cedex France Tel: (33) 4 92 38 79 38 Fax: (33) 4 92 38 50 29 http://www-sop.inria.fr/everest/Gilles.Barthe From ccris at !NS! doc.ic.ac.uk Wed Jun 21 10:22:34 2006 From: ccris at !NS! doc.ic.ac.uk (Cristiano Calcagno) Date: Wed, 21 Jun 2006 10:22:34 +0100 Subject: [Coq-Club]research position at Imperial, Smallfoot checker Message-ID: <44990FDA.4000402@doc.ic.ac.uk> Philippa Gardner and I have a three-year postdoctoral research position available at Imperial, to build a static assertion checker for C based on separation logic. This is a joint project with Peter O'Hearn at Queen Mary, comprising one PhD student and one RA at each site. The details are given below. The deadline for application is 28th July 2006. Please send informal enquiries to me. I'd be grateful if you could forward this email to candidates you think might be suitable. Best wishes, Cristiano Calcagno ------------------------ Research Assistant/Associate Department of Computing, Imperial College London Title: Smallfoot: Static Assertion Checking for C programs Salary: £22,870 - £33,330 inclusive of London Allowance per annum Deadline for Applications: 28th July 2006 A postdoctoral Research Fellowship is available in the Department of Computing to work with Cristiano Calcagno and Philippa Gardner on an EPSRC project joint with Peter O'Hearn at Queen Mary. This is a fixed term post of 3 years starting on 1 October 2006 with some flexibility. The aim of the project is to develop a static assertion checker for C based on separation logic, and demonstrate it on systems code such as a memory manager. See http://www.dcs.qmul.ac.uk/research/logic/theory/projects/smallfoot/ for more details. Applicants must hold, or being nearing completion of, a PhD in Computer Science in a relevant subject. Preference will be given to applicants with a proven record in software development or theoretical computer science. Experience in one or more of the following is desirable: logic (especially separation logic), verification, program analysis, model checking. Formal applications should be sent to the address at the end of this message. Please send informal enquiries to Cristiano Calcagno, email: ccris@doc.ic.ac.uk Background of the Project ------------------------- Pointers have long been one of the dark corners of programming languages. Tractable proof and analysis tools are lacking for all but the most simple, shallow, properties of the program heap. A recent theory, separation logic, has shed fresh light on this area, and has generated considerable interest worldwide. It has lead to much simpler by-hand specifications and program proofs than previous formalisms, and it suggests, for the first time, the possibility of scalable analysis methods for expressive heap properties. To date though, separation logic remains mainly a theoretical advance; there are no tools based on separation logic for any real programming languages. We propose to develop a static assertion checker for C based on separation logic. Separation logic works naturally with a low-level RAM model, and thus appears to be well suited to code that must run close to the hardware without an intermediate abstraction of the kind found in the runtimes of high-level languages such as ML or Java. Much fundamental code of this sort is written in the C programming language, and is outside the effective range of current tools. Our tool, Smallfoot, will accept precondition and postcondition assertions written in separation logic, and programs will be checked using a combination of symbolic execution and specialized proof procedures. Abstract interpretation will be used to alleviate the need to state invariants. We will check structural integrity properties of programs -- such as that data structures are in consistent states, or that resource boundaries are respected -- rather than full functional correctness. In this way we hope to keep specifications simple, and to achieve a high degree of automation. As it is aimed at low-level programs, Smallfoot will be complementary to static assertion checkers for higher-level language