1 / 29

ASPfun: A Distributed Object Calculus and its Formalization in Isabelle

ASPfun: A Distributed Object Calculus and its Formalization in Isabelle. Ludovic HENRIO. Work realized in collaboration with Florian Kamm üller and Henry Sudhof ( Technische Universität Berlin ). Montevideo, Nov 2007. Context . -calculus : A Theory of Objects (Abadi,Cardelli)

Download Presentation

ASPfun: A Distributed Object Calculus and its Formalization in Isabelle

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ASPfun: A Distributed Object Calculus and its Formalization in Isabelle Ludovic HENRIO Work realized in collaboration with Florian Kammüller and Henry Sudhof (Technische Universität Berlin) Montevideo, Nov 2007

  2. Context • -calculus: A Theory of Objects (Abadi,Cardelli) • Formalizes objects and typing • Several calculi: a functional and an imperative one • ASP: Asynchronous Sequential Processes (Caromel, Henrio) • Based on imp-calculus • Distributed active object calculus • Asynchronous method calls (requests), futures • Properties of confluence/determinism, e.g. execution insensitive to the order of replies Objective Provide a framework for (mechanically) proving properties on distributed object-oriented languages and programs  typing, confluence, …

  3. 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)

  4. Contribution • ASPfun calculus • Based on functional -calculus • Distributed with active objects and futures • Good representation of functional distributed programs (workflows, services) • A type system for ASPfun: • Typing active objects and futures • Proof of subject-reduction and progress  no dead-lock • A Formalization in Isabelle/HOL • Calculus and semantics • Type-system • Proofs ASPfun is simpler Easier to formalize in Isabelle/HOL A lot of interesting properties (no dead-lock) BUT further from a “real life” complete programming language

  5. Agenda 1 - ASPfun: syntax, semantics and properties 2 - A type system for ASPfun 3 - Formalization in Isabelle/HOL

  6. ASPfun Syntax (static) • One new construct: Active 1 - ASPfun: syntax, semantics and properties

  7. ASPfun Syntax (dynamic) • Configurations are sets of activities, each activity has: • A name • An active object • A list of requests being treated Requests map terms to future identifiers Add reference to futures (result of requests) and activities   f0 f2 f1 f3 1 - ASPfun: syntax, semantics and properties

  8. ASPfun Semantics (1/5): Local reduction f0 Reduced according to -calculus semantics f1 1 - ASPfun: syntax, semantics and properties

  9. ASPfun Semantics (2/5): Activity creation  f0 a is “self contained”  f1  1 - ASPfun: syntax, semantics and properties

  10. ASPfun Semantics (3/5):Remote Method Invocation  f0 f2 f1 f2 fresh  f2 1 - ASPfun: syntax, semantics and properties

  11. ASPfun Semantics (4/5): Reply  f0 … … f2 f1  f2 1 - ASPfun: syntax, semantics and properties

  12. ASPfun Semantics (5/5): Field update on an active object  f0 is “self contained” f1   f2 1 - ASPfun: syntax, semantics and properties

  13. A Basic Property • A configuration is well-formed if it only refers to existing activities and futures • Reduction preserves well-formedness • Initial configuration: 1 - ASPfun: syntax, semantics and properties

  14. Agenda 1 - ASPfun: syntax, semantics and properties 2 - A type system for ASPfun 3 - Formalization in Isabelle/HOL

  15. Static Terms • Re-uses typing for -calculus • Syntax: • Typing judgement • Basic idea: the type of an active object is the type of the contained object Typing environment (mapping from variables to types) How to type active object and future references? 2 - A type system for ASPfun

  16. f0 f1 Typing Configurations • The type of a configuration is two mappings: • From activity to types • From futures to types • A configuration is well-typed if: • Futures and activities defined in C and are the same • All the active objects of C are well-typed • All the requests of C are well-typed • Then, typing terms: • -calculus terms and Active are typed as usual • Future and active object references are typed using the environment 2 - A type system for ASPfun

  17. Typing Properties • Each term has a unique type • Subject-reduction (reduction preserves typing) • Progress: • C is well-typed  C can be reduced or all its requests are values • Where a value is an object or a reference to an activity  Absence of dead-locks 2 - A type system for ASPfun

  18. Agenda 1 - ASPfun: syntax, semantics and properties 2 - A type system for ASPfun 3 - Formalization in Isabelle/HOL

  19. Syntax Finite mapping • Syntax is mostly trivial,e.g.: • Relies on deBruijn indices (represent variables by natural numbers -- depth) • Configurations are mappings 3 - A Formalization in Isabelle/HOL

  20. Semantics • Almost direct translation, e.g.: • Like on paper, reduction relies on reduction contexts (expression with a hole: the reduction occurs in the single hole) 3 - A Formalization in Isabelle/HOL

  21. Properties and Proofs • deBruijn indices induce a lot of (easy) additional lemmas • Reduction preserves well-formedness (long) • Typing relatively easy to define • Proofs (subject-reduction, progress, …) relatively long but not difficult (>1000 lines each) • Main difficulties: • Long repetitive proofs • A lot of design choices (e.g. define reduction contexts) • Finite maps, and associated recurrence • Two axioms remaining (fresh futures and activities exist)  requires configurations as finite maps of an unbounded length 3 - A Formalization in Isabelle/HOL

  22. Future Works / Todo list • Introduce methods with a parameter: (x,y) / a.l(b) (ongoing) • Prove confluence of ASPfun • Define a parallel reduction (reducing severl terms in parallel) • ASPfun as it is specified is not confluent • Introduce new rules for merging/garbage collecting activities • Or reduce the conditions of reduction (!! progress) • Remove De Bruijn indices  “nominal techniques”?

  23. Conclusion • A new distributed calculus and its formalization in Isabelle • A Type system: • Progress  no dead-lock • A base framework for developments on objects, confluence and distribution • A lot of possible applications (distribution / typing / AOP …) Experiments on Isabelle (a few months development) • User-friendly, relatively fast development • Finding the right structure/representation is crucial • Proofs are long repetitive and unstructured • Difficulties when modifying / reusing code http://www.cs.tu-berlin.de/~flokam/isabelle/sigma/

  24. THANK YOU !!!If you prefer the Greek version …

  25. AppendixTyping Rules • Configuration • ASP

  26. An Example 1 - Functional -calculus in Isabelle

  27. An Example 1 - Functional -calculus in Isabelle

  28. What are De Bruijn Indices? • De Bruijn indices avoid having to deal with -conversion • Variables are natural numbers depending on the depth of the parameter 1 - Functional -calculus in Isabelle

  29. Why De Bruijn Indices? • Drawbacks: • Terms are “ugly”  We are interested ingeneral properties / not for extracting an interpreter … • Lot of additional definitions/lemmas are necessary: • Definition of subst and lift: semantics more complex • Proofs of several additional (easy) lemmas • Advantages • Established approach • Reuse Nipkow’s framework for confluence of the -calculus • Alternative approaches, e.g. nominal techniques  probably better on the long term De Bruijn indices are perhaps not the best solution but allowed a fast implementation 1 - Functional -calculus in Isabelle

More Related