A Locally Nameless Theory of Objects 1.Introduction:  -calculus and De Bruijn notation 2.locally nameless technique 3.formalization in Isabelle and proofs.

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

Agenda Definitions Evolution of Programming Languages and Personal Computers The C Language.
An Abstract Interpretation Framework for Refactoring P. Cousot, NYU, ENS, CNRS, INRIA R. Cousot, ENS, CNRS, INRIA F. Logozzo, M. Barnett, Microsoft Research.
Computational Models The exam. Models of computation. –The Turing machine. –The Von Neumann machine. –The calculus. –The predicate calculus. Turing.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Request Scheduling for Multiactive Objects StudentJustine Rochas SupervisorLudovic Henrio Research lab INRIA-I3S-CNRS-UNS Research teamOASIS Master Thesis.
1 PROPERTIES OF A TYPE ABSTRACT INTERPRETATER. 2 MOTIVATION OF THE EXPERIMENT § a well understood case l type inference in functional programming à la.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
VIDE als voortzetting van Cocktail SET Seminar 11 september 2008 Dr. ir. Michael Franssen.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
Course on Probabilistic Methods in Concurrency (Concurrent Languages for Probabilistic Asynchronous Communication) Lecture 1 The pi-calculus and the asynchronous.
Discovering Affine Equalities Using Random Interpretation Sumit Gulwani George Necula EECS Department University of California, Berkeley.
C. Varela; Adapted w/permission from S. Haridi and P. Van Roy1 Declarative Computation Model Defining practical programming languages Carlos Varela RPI.
The Semantic Web Week 13 Module Website: Lecture: Knowledge Acquisition / Engineering Practical: Getting to know.
Discrete Mathematics Lecture 4 Harper Langston New York University.
Chair of Software Engineering 1 Concurrent Object-Oriented Programming Arnaud Bailly, Bertrand Meyer and Volkan Arslan.
Towards a HOL Framework for the Deductive Analysis of Hybrid Control Systems ADPM’2000 Norbert Völker University of Essex, England.
1 Ivan Lanese Computer Science Department University of Bologna Italy Concurrent and located synchronizations in π-calculus.
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
1 Ivan Lanese Computer Science Department University of Bologna Italy Towards a Unifying Theory for Web Services Composition Manuel Mazzara Faculty of.
Propositional Calculus Math Foundations of Computer Science.
Quantum One: Lecture 7. The General Formalism of Quantum Mechanics.
Lecture 21: Languages and Grammars. Natural Language vs. Formal Language.
High level & Low level language High level programming languages are more structured, are closer to spoken language and are more intuitive than low level.
Safe composition of distributed adaptable components A distributed component model Behavioural specification and verification Ludovic Henrio and Eric Madelaine.
Oct Multi-threaded Active Objects Ludovic Henrio, Fabrice Huet, Zsolt Istvàn June 2013 –
CSE S. Tanimoto Lambda Calculus 1 Lambda Calculus What is the simplest functional language that is still Turing complete? Where do functional languages.
© Kenneth C. Louden, Chapter 11 - Functional Programming, Part III: Theory Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.
Formalism and Platform for Autonomous Distributed Components Bio-inspired Networks and Services A Distributed Component Model Formalisation in Isabelle.
Denis Caromel1 Troisieme partie Cours EJC 2003, AUSSOIS, Denis Caromel OASIS Team INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis.
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
Asynchronous Components with Futures: Semantics, Specification, and Proofs in a Theorem Prover Components (Distributed) Futures Formalisations (and proofs)
A Mechanized Model for CAN Protocols Context and objectives Our mechanized model Results Conclusions and Future Works Francesco Bongiovanni and Ludovic.
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
© Kenneth C. Louden, Chapter 11 - Functional Programming, Part III: Theory Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
Theory of Programming Languages Introduction. What is a Programming Language? John von Neumann (1940’s) –Stored program concept –CPU actions determined.
1 Formal Semantics. 2 Why formalize? ML is tricky, particularly in corner cases generalizable type variables? polymorphic references? exceptions? Some.
ASPfun: A Distributed Object Calculus and its Formalization in Isabelle Work realized in collaboration with Florian Kammüller and Henry Sudhof (Technische.
Implementing a Dependently Typed λ -Calculus Ali Assaf Abbie Desrosiers Alexandre Tomberg.
Mechanizing Metatheory without Typing Contexts TYPES 2011 September 10, 2011 Jonghyun Park, Jeongbong Seo, Sungwoo Park, Gyesik Lee* Pohang University.
Open Incremental Model Checking (OIMC) and the Role of Contracts Model-Based Programming and Verification.
Advanced Formal Methods Lecture 3: Simply Typed Lambda calculus Mads Dam KTH/CSC Course 2D1453, Some material from B. Pierce: TAPL + some from.
A visualisation and debugging tool for multi-active objects Ludovic Henrio, Justine Rochas LAMHA, Nov 2015.
Science and Technology Norwegian University of NTNU Rolv Bræk, January Introduction to Systems Engineering by Rolv Bræk NTNU.
Transparent First-class Futures and Distributed Components Introduction: components, futures, and challenges Statically Representing Futures An Example.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
A Mechanized Model of the Theory of Objects 1.Functional  -calculus in Isabelle 2.Confluence Proof in Isabelle 3.Ongoing Work, Applications, Conclusion.
Distributed Components and Futures: Models and Challenges A Distributed Component Model Distributed Reconfiguration Calculi for Components and Futures.
A Theory of Distributed Objects Toward a Foundation for Component Grid Platforms Ludovic HENRIO l A Theory of Distributed Objects l Components l Perspectives.
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
CS5205Semantics1 CS5205: Foundation in Programming Languages Semantics Static Semantics Dynamic Semantics Operational Semantics Big-step Small-Step Denotational.
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
GoRelations: an Intuitive Query System for DBPedia Lushan Han and Tim Finin 15 November 2011
Interface specifications At the core of each Larch interface language is a model of the state manipulated by the associated programming language. Each.
COMP 412, FALL Type Systems C OMP 412 Rice University Houston, Texas Fall 2000 Copyright 2000, Robert Cartwright, all rights reserved. Students.
ASYNCHRONOUS AND DETERMINISTIC OBJECTS ASP: Asynchronous Sequential Processes l Distributed objects l Asynchronous method calls l Futures and Wait-by-necessity.
Unit – 3 :LAMBDA CALCULUS AND FUNCTIONAL PROGRAMMING
Formal Techniques (CS340 © John C. Knight 2004)
A Verified Compiler for an Impure Functional Language
Corky Cartwright January 18, 2017
Numerical Representation of Strings
B (The language of B-Method )
Quantum One.
Engineering Aspects of Formal Metatheory
CS 611: Lecture 10 More Lambda Calculus September 20, 1999
CSE S. Tanimoto Lambda Calculus
CS 611: Lecture 10 More Lambda Calculus September 20, 1999
Presentation transcript:

A Locally Nameless Theory of Objects 1.Introduction:  -calculus and De Bruijn notation 2.locally nameless technique 3.formalization in Isabelle and proofs Ludovic Henrio, Florian Kammüller, Bianca Lutz, and Henry Sudhof SAFA workshop – Oct 2010

Context Calculi abstract away real programming languages: Proofs made on the calculus allow optimisation and ensure properties on real programs Use of theorem prover to increase confidence in those proofs A general problem is the representation of variables We focus here on a simple object language

Each method is a function with a parameter: “self” Functional  -calculus Syntax Semantics (Abadi - Cardelli) Why functional?  updating a field creates a new object (copy)

An Example

What are De Bruijn Indices? De Bruijn indices avoid having to deal with  -conversion equivalent to Variables are natural numbers depending on the depth of the parameter also represents

Why De Bruijn Indices? Drawbacks: l Terms are “ugly”  We are interested in general properties / not for extracting an interpreter … l Definition of subst and lift: semantics more complex l Proofs of many additional (easy) lemmas Advantages l Established approach l Reuse Nipkow’s framework for confluence of the -calculus Alternative approaches, e.g. locally nameless Unique representation -> avoids dealing with alpha conversion

What is locally nameless technique? Bound variables are represented by their De Bruijn index Free variables are represented by a “usual” variable manipulate only locally closed terms i.e. all indexed variables must be bound and are forbidden

Opening and Closing open and close change between bound and free variables helps maintain the “locally closed” invariant openclose non-LC terms

A method parameter Syntax openclose

Cofinite Quantification When specifying semantics or proving properties, we need to open terms: x cannot be taken randomly, an idea: Typically, proofs by induction, we must prove: Sometimes impossible if t’≠t, similar problem for: We use cofinite quantification:  t’ t x

Semantics with cofinite quantification Reduce inside update (adapted for self+parameter): 

In Isabelle

Properties and Proofs Translated proofs for De Bruijn: Confluence Typing: subject reduction and progress Different lemmas: lifting and manipulation of indices for De Bruijn Translation between free and bound variables for LN Not particularly shorter, but LN more precise Induction scheme more complex due to more complex semantics (cofinite quantification)

Conclusion on LN representation New concepts wrt de Bruijn: o opening and closing o locally closed terms (precondition of many lemmas and semantic rules) o cofinite quantification Better structure, accuracy, and understanding: o Distinction between free and bound variables o Cofinite quantification LN adapted to objects and to multiple parameters Terms can be written in a similar manner as paper version (using closing)

Other techniques? Nominal techniques: Terms are identified as a set bijective to all terms factorised by alpha-equivalence There must be a finite support for a term t Well supported in Isabelle but not adapted to finite maps for the moment Higher Order Abstract Syntax binders represented by binders of the meta-level not very convenient in our case

Confluence Principles Ensures that all computations are equivalent (same result) Generally based on a diamond property: Diamond  confluent: 2 - Confluence a b c d p q r s

Confluence Principles (2) In general we have to introduce a new reduction that verifies the diamond property    confluent and 2 - Confluence a b c d

Confluence of the  -calculus l Based on Nipkow’s framework: Confluence for the -calculus  Useful lemmas: commute, Church-Rosser, diamond  Structure of a confluence proof in Isabelle l Definition of a parallel reduction (verifies diamond)  Like for -calculus, can reduce all sub-terms in parallel  Also includes (semantics of the  -calculus) 2 - Confluence

Number of methods Reducing in Parallel inside Object Subgoal (looks trivial but proof is tricky): Solution: split into several reductions on object fields 2 - Confluence  -calculus confluence proof similar to Nipkow’s framework but: Much less automatic Difference of granularity between lists of terms and objects More cases for diamond (more constructors/rules)

In the Meantime … Objects as finite maps from labels to methods instead of lists of methods  Definition of finite maps and a new induction principle  Closer to original  -calculus (syntax and semantics); new recurrence principle on terms Formalization of the basic type system for the functional  -calculus  Typing rules (Abadi - Cardelli)  Subject reduction, progress (no stuck configuration) 3 - Ongoing Work, Applications, Conclusion

Todo List Remove De Bruijn indices  “nominal techniques”? Introduce methods with a parameter:  (x,y) / a.l(b) Apply to other results on object languages (concurrence, mobility, …)  A base model for Aspect Oriented Programming 3 - Ongoing Work, Applications, Conclusion

Towards Distribution A model for the ASP calculus in Isabelle; ASP formalizes:  Active objects (AO) without shared memory  AO is the entry point and the master object of the activity  Communicating by asynchronous method calls with futures Currently:  Definition of a functional ASP in Isabelle  Proof of well-formedness of the reduction (no creation of reference to non-existing active objects or futures) To do ….  A type system for ASP  Proof of confluence for the functional ASP  Extension of the concurrency in the functional calculus  Case of the imperative ASP calculus … 3 - Ongoing Work, Applications, Conclusion

Conclusion A formalization of the  -calculus in Isabelle A confluence proof for the functional  -calculus  Parallel reduction inside objects A base framework for developments on objects, confluence and concurrency A lot of possible applications (distribution / typing / AOP …) Experiments on Isabelle (few months development)  User-friendly, relatively fast development  Finding the right structure/representation is crucial  Difficulties when modifying / reusing code Ongoing Work, Applications, Conclusion