1 / 47

Encoding formal systems, logics and calculi in CTT

FORMALWARE Engineering CISM Udine (Italy), September 24-28, 2001. Encoding formal systems, logics and calculi in CTT. Furio Honsell Professor of Foundations of Informatics Universit à di Udine, Italy honsell@dimi.uniud.it. The protocols.

ghada
Download Presentation

Encoding formal systems, logics and calculi in CTT

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. FORMALWARE Engineering CISM Udine (Italy), September 24-28, 2001 Encoding formal systems, logics and calculi in CTT Furio Honsell Professor of Foundations of Informatics Università di Udine, Italyhonsell@dimi.uniud.it

  2. The protocols 3 paradigms for encoding formal systems, program logics and calculi in Logical Frameworks (LF), based on Constructive Type Theory • Higher Order Abstract Syntax (HOAS) • Higher Order Natural Deduction • Theory of Contexts (stemming from an axiomatic viewpoint)

  3. Examples • FOL • Hoare’s Logic • l-calculus • p-calculus • Pick your choice …

  4. Logical Frameworks • Use higher order (co-inductive) type theories i.e. higher order, dependent typed l-calculus • as specification languages for representing • Syntax • h.o. (co)inductive dependent types • Operational semantics & Inferentail machinery • Proof Theory • h.o. (impredicative) type of propositions • of formal/logical systems • provide a setting for formal development of the METATHEORY of formal logics and calculi • possibly using suitable non-logical axioms

  5. Higher order recursive types • We want to capitalize on (co)-inductive types for • syntax datatypes • Proof theory predicates Higher order(impredicative) quantification on propositions is probably enough for defining (co)-inductively predicates (Relation induction) • We need precise correspondence statements between objects and encodings Adequacy Theorems

  6. General computational paradigm • judgements as types • hypothetical jdg. as h.o.types • general jdg. As h.o.types • proofs as l-terms • object systems as signatures

  7. Basic encoding principles I • Syntactic categories of the object logic are represented by (inductive) sets • Judgements of the object logics are rendered as predicates over the sets • Rules and axioms are encoded as constructors for the predicates

  8. Basic encoding principles II • A metalanguage variable of type A plays the role of a generic object of type A • hence • a metalanguage object of type io plays the role of a context of type o over i • HIGHER ORDER ABSTRACT SYNTAX (HOAS) (Church,Martin- Löf, Plotkin, Honsell,Miculan,…) • this allows for 2 imporant techniques • HIGHER ORDER NATURAL DEDUCTION (Gentzen, Martin-Löf, Shröder-Heister,…)

  9. Higher Order Abstract Syntax • Provides algebraic account of context sensitive features of languages which manipulate • variables • names • Identifiers • All the above are conflated to metalanguage variables • Languages with binders, restriction operators, “new name” operators, assignment are treated on a par with languages with only variable, name, identifier-free expressions

  10. HOAS (cntd.) • Schemata (contexts) are represented as higher order objects • Substitution/instantiation is encoded by b–reduction • hence HOAS sets a standard for • a-conversion • capture avoiding substitution • both are delegated to the metalanguage

  11. Higher Order Natural Deduction • The Consequence relation connecting hypotheses to conclusions in an object logical system is modeled by the arrow type constructor of the metalanguage types structural rules such as • weakening • contraction • substitutivity • are inherited from the metalanguage

  12. Further features • Both at syntax and judgement level one can • DELEGATE to the FRAMEWORK the mechanisms for keeping track of scope dependencies, • DISTRIBUTE over the FRAMEWORK context object system (run-time) data structures which behave according to a stack discipline: e.g. environments

  13. The Calculus of Inductive Constructions CIC • Notation • E: (environments) sequence of constants with type • G: (context) sequence of variables with type • Two mutually defined judgements • WF(E[G])G is a well-formed context in the environment E • E[G]|- M:TM has type T in the context E and environment G

  14. The Calculus of Inductive Constructions • CIC is a conservative extension of lC. • Sorts: S={Set,Prop,Type(i)}, i integer • Set is the type of specifications, i.e. terms with a computational content: programs, datatypes such as booleans, naturals, lists etc. • Prop is the type of logical propositions. A term m belonging to M witnesses the fact that M is true. • Set,Prop:Type(0) and Type(i):Type(i+1). • Indexes are dropped: from the user point of view: Prop:Type and Type:Type.

  15. CIC: some rules E[G] |- T : s1E[G::(x:T)] |- U : s2s1Î{Prop, Set} or  s2Î{Prop, Set} E[G] |- (x:T)U : s2 E[G] |- (x:T)U : sE[G::(x:T)] |- t : U E[G] |- [x:T]t : (x:T)U E[G] |- t : (x:U)TE[G] |- u : U E[G] |- (tu) : T{x/u} E[G] |- t : TcÏEÈG WF(E;Def(G)(c:=t:T))[G] Prod Abs App Def

  16. Coq Languages:Gallina and the Vernacular • Specification language: Gallina • representation of l-terms of CIC with structured data types, recursive functions, inductive predicates, … • Command language: the Vernacular • Definitions of terms, parameters, functions, predicates, axioms, rules, lemmata • Interactive proof development (tactics) • State management (loading of libraries, reset…)

  17. Some Gallina • Abstraction: lx:A.t is noted [x:A]t • Application: (M N) is noted (M N) • Universal quantification: Px:A.B is noted (x:A)B When x does not occur (free) in B, it can be also written as A->B

  18. More Gallina • Definition by case analysis <A>Cases M of p1 => t1 | … | pn => tnend • Recursive and corecursive terms, possibly mutual Fix F {F : A = M}CoFix F {F : A = M} • Only well-typed terms are accepted.The conditions in the typing rules ensure soundness of the system

  19. Inductive Definitions • Inductive Sets (datatypes) (possibly mutual). Inductive nat : Set := O : nat | S : nat -> nat. Elimination schemata (induction and recursion principles) are automatically generated and proved. Nat_ind : (P:nat->Prop)(P O)->((n:nat)(P n)->(P (S n)))->(n:nat)(P n)

  20. Mutual Inductive definitions • CIC allows for mutual inductive definitions: Mutual Inductive tree : Set := node : forest -> tree with forest : Set :=emptyf : forest|consf : tree -> forest -> forest. • In order to preserve soundness of CIC, not all inductive definitions are allowed. E.g., the following is not allowedInductive D : Set := (D->D)->D.

  21. Destructing inductive objects by case analysis • A term inhabiting an inductive type can be used for defining terms in other types, by so-called case analysis. E.g.: Definition iszero : nat->Prop :=[n:nat]Cases n of O => True (S m) => Falseend. • Then, (iszero O)i-reduces to True.

  22. Destructing inductive objects by fixed point • Objects of inductive types are built by fixpointdefinitions. E.g., for the inductive set Inductive listn : Set :=nil : listn |cons : nat -> listn -> listn.lgth = Fix lgth  {lgth [l:(listn)] : nat :=     Cases l of       nil => O     | (cons _ l') => (S (lgth l'))     end}     : listn->nat

  23. Logical connectives • All logical connectives but forall and implication are defined as inductive predicates. EgInductive and [A:Prop; B:Prop]: Prop := conj : A->B->(and A B).From the induction principles one obtains the logical rules of the connective • Also the constant False is inductive:Inductive False : Prop := .The case analysis yields the usual absurdity ruleQ:Prop p:False<Q>(Case p of end) : Q

  24. Coinductive Types (1) • Objects inhabiting coinductive types may be non well-founded. Canonical example:CoInductive Stream := cons : nat -> Stream -> Stream. • Inductive principles do not hold anymore • Definition of coinductive objects: by giving a (non-ending) method of constructionCoFixpoint zeros : Stream := (cons O zeros).represents (O,O,O,O,…)

  25. Coinductive Types (2) • Destruction: Only by case analysisCases s of (cons n s’) => … end. • Coinductive objects are unfolded only when appear as the argument of a Cases • For instance:Definition hd : Stream -> A := [x:Stream] Cases x of (cons a _) => a end.Definition tl : Stream -> Stream:= [x:Stream] Cases x of (cons _ y) => y end.

  26. Coinductive Types (3) • Not all coinductive definitions are allowed, in order to avoid non converging terms • Guardedness condition: In CoFixpoint definitions, any recursive call in the definition must be protected – i.e, be an argument of – some constructor • Some non valid definitions:CoFixpoint foo : Stream := foo.CoFixpoint bar : Stream := Case bar of (cons x s) => s end.

  27. Coinductive Types (4) • Also proofs can be non well-founded objects (coinductive proofs). Most typical proofs are bisimulation proofs. • This allows for reasoning over processes, protocols and evolving systems • Coinductive features of Coq have been used for verifications of protocols (ABP), processes (CCS, p-calculus), … • Still, the issue is not completely satisfactory (guardedness condition is too strong)

  28. Induction Principles and Recursion • Any inductive type induces a Recursor and an Induction Principle over it for P:nat Prop. • The general type of a Recursor, Natrec:PP:nat  Set. (P0)(Pn:nat.P (n) P(S(n)) (Pn:nat.P (n)) is the induction principle (over Set)

  29. (Co)inductively defined predicates (relations) • Relation induction is essentially built in the higher-order impredicative definition T: (A AProp)  (A AProp) m R.T(R) (x) = P: (A AProp). (TP P)P(x) n R.T(R) (x) = P: (A AProp). (P TP)&P(x)

  30. Representing binding operators How to represent binding operators (e.g, the l of l-calculus)? • First-order syntax (explicit names): Lam : var -> term -> term. High representation overhead: one must deal with a-equivalence, capture-avoiding substitution, generation of fresh names, …

  31. Representing binding operators • Higher Order Abstract Syntax App: term -> term -> term Lam: (term -> term) -> term • lx.t is represented by (Lam [x:term]t) • Variables of the language = variables of the metalanguage • Bound variable = bound variable • a-equivalent terms have automagically the same representation!

  32. Representing binding operators • Capture avoiding substitution can be obtained for free from the metalanguage: eval : term -> term -> Prop Beta : (M:term->term)(N:term)(eval (App (Lam M) N) (M N)) • Very low overhead: no need to worry about explicit variables, substitutions, a-equivalence…

  33. Using Coq as a LF for specifing First Order Logic (1) • Two syntactic sorts Inductive i : Set := zero : i | one : i|sum : i -> i -> i. Inductive o : Set := equ : i -> i -> o|imp : i -> i -> i|forall : (i -> o) -> i. • One judgement (“truth” or “derivability”)Parameter T : o -> Prop.

  34. Using Coq as a LF for specifing First Order Logic (2) • Four rules for deriving the judgement Axiom impI : (A,B:o)((T A) -> (T B)) -> (T (imp A B)). Axiom impE : (A,B:o)(T A) -> (T (imp A B)) -> (T B). Axiom forallI : (A:i->o)((x:i)(T (A x)))->(T (forall A)). Axiom forallE : (A:i->o)(t:i)(T (forall A)) -> (T (A t)).

  35. HOAS and Inductive Types • HOAS cannot be directly used in Coq in combination with inductive definitions: Inductive L : Set := App : L -> L -> L| Lam : (L -> L) -> L. is not accepted by CIC typing rules, due to the occurrence of L in negative position • Shall we lose either HOAS or induction principles?

  36. HOAS and Inductive Types:delegating only a-equivalence HOAS with a separate set of (unstructured) objects, variables (names) Parameter var : Set. Inductive L : Set := Var : var -> L | App : L -> L -> L| Lam : (var -> L) -> L. • lx.t is represented by Lam [x:var]t • delegates only a-equivalence and substitution of names for names

  37. HOAS and Inductive Types: delegating only a-equivalence • Substitution (of terms for variables) is no more delegated to the metalanguage Inductive subst [N:L] : (var->L)->L := subst_Var : (subst N Var N)|subst_void:(y:var)(subst N [_:var]y y)| subst_App : …| subst_Lam : (M:var->var->L)(N:var->L) ((y:var)(subst (M y) (N y))) -> (subst [x:var](Lam [y:var](M y x)) (Lam N)).

  38. HOAS and Inductive Types:Exotic Terms • Var can be declared as an inductive set. • Substitution and properties over contexts derive from induction and recursion principles • But we get exotic terms: terms which do not correspond to any object language term Definition var = nat.Definition weird = Lam [x:var](Case x of O => (Var O) | (S n) => (App (Var n) (Var n)) end).

  39. HOAS and Inductive Types:Ruling out Exotic Terms • Exotic term are dangerous when reasoning over the object logic (e.g., by structural induction on the terms) • They can be ruled out by extra judgements of well-formedness Valid : L -> Prop. • Innatural encoding (extra judgement everywhere) and higher overhead on the user

  40. HOAS and Inductive Types:Avoiding Exotic Terms • Our proposal: we can leave Var unspecified: Parameter Var : Set. • No more exotic terms! • BUT No more metalogical properties over context, either! • Solution: add only those axioms we need for dealing with names and contexts, and prove separately their soundness

  41. HOAS and Inductive Types:A Theory of Contexts • Inductively define the predicate notin : var -> L -> Prop • Three axioms (schemata) to add • Unsat: (t:L)(Ex [x:var](notin x t)) • Expan: (t:L)(x:var)(Ex [s:var->L] (t=(s x))/\(notin x s))) • Ext: (t1,t2:L)(x:var)(notin x t1) -> (notin x t2) ->(t1 x)=(t2 x) -> t1=t2.

  42. HOAS and Inductive Types:A Theory of Contexts • These axioms are quite expressive: we have used them for metareasoning over many logics and calculi for concurrent and mobile systems • p-calculus • l-calculus • First Order Logic • Spi-calculus • … • Soundness of the axioms has been proved recently by building a model of presheaves.

  43. Nominal algebras • A names set is an infinite set of different atomic objects with a decidible equality • A nominal algebra N is a triple (V, I, C) where • V is a finite set of names sets • I is a set of basic types • C is a set of constructors, which are typed constants ca where a is a constructor arity: a type of the form t1…tn i, where n0 and for i = 1 … n, the type ti is either in V or it is of the form u1…um i’. (Notice that only types of names may occur in negative position).If m 0, then c is said to be a binding constructor, or simply a binder.

  44. Nominal algebras: examples • Untyped l-calculus: Nl = ({u}, {L}, {varuL, appLLL, lam(uL)L}) • p-calculus: Np = ({u}, {i}, {0i, |iii, tii, =uuii, n(ui)i, inu(uL)L, outuuii}) • Also: FOL, ambient calculus, n-calculus, CCS, simply typed l-calculus, … • But: languages with polyadic binders escape the class of nominal algebras.

  45. Encoding p-calculus I • Parameter name:Set • Inductive Proc : Set:= nil :proc tau :proc nu :(nameproc)proc In :name(nameproc)proc Out :namenameprocproc • Mutual Inductive ftrans :procf_actprocProp:=… btrans :procb_act(nameproc)Prop:=…

  46. Encoding p-calculus II Suitable constructors for the judgement ftrans • fRES: (p1,p2:nameproc)(a:f_act)(L:Nlist) ((y:name)(notin y (nu p1||nu p2)) (Nlist_notin y L)(f_act_notin y a) (ftrans (p1 y) a (p2 y)))  (ftrans (nu p1) a (nu p2)) • etc.

  47. Developing the metatheory of p-calculus • Using the “theory of contexts” the development of the metatheory of p-calculus in Milner,Parrow,Walker 1992, was formally derived in Honsell,Miculan,Scagnetto2001 • E.g. Lemma 6 (p,q:nameProc)(z:name)(notin z (nu p || nu q)) (Stbisim (p z) (q z)) (w:name)(notin w (nu p || nu q)) (Stbisim (p w) (q w))

More Related