towards certifiable implementation of graph
play

Towards Certifiable Implementation of Graph Transformation via - PowerPoint PPT Presentation

Towards Certifiable Implementation of Graph Transformation via Relation Categories Wolfram Kahl McMaster University Hamilton, Ontario, Canada 17 September 2012 RAMiCS 13 Cambridge, UK This research is supported by the National


  1. Towards Certifiable Implementation of Graph Transformation via Relation Categories Wolfram Kahl McMaster University Hamilton, Ontario, Canada 17 September 2012 — RAMiCS 13 — Cambridge, UK This research is supported by the National Science and Engineering Research Council of Canada, NSERC.

  2. The Categoric Approach to Graph Transformation There are various approaches to graph transformation/grammars: Node-label controlled Programmed Hyperedge replacement Categoric approach Double pushout-approach (DPO) Single pushout-approach Single/double pullback-approach . . . Relation-algebraic approach “Double pullout-approach” . . . Graphs can be considered as unary algebras: “Algebraic Approach” Currently fashionable framework: “adhesive HLR categories”

  3. Double-Pushout Transformations ✲ R G L Φ L Φ R ✛ M E N ✲ B A ❄ H ❄ ❄ Ψ L Ψ R ✛ Given a rule L Φ L G Φ R ✲ R ✛ and a matching M into an application graph A ✲ H Ψ L E construct pushout complement ✲ ✲ B Ψ R N construct pushout ✛ B is the result graph How do we implement all that? How do we go about implementing transformation mechanisms like that?

  4. How to Implement Categoric Graph Transformation? Requirement 1 — Graph Category: Represent graphs and graph homomorphisms as data, and implement pushouts and other categoric operations. Graphs structure categories are categories of unary algebras, or of diagrams Base category pushouts produce diagram category pushouts Design Decision 1: Implement graph structure categories abstractly on top of a base category

  5. Diagram Pushouts from Base Pushouts DiagMorPushout ∶ HasPushouts compOp → { A B C ∶ Diagram } ( F ∶ DiagMor A B ) ( G ∶ DiagMor A C ) → Pushout DiagMorCompOp F G R 1 � V ′ ≈ P 1 � eZ ∶ R 1 � V ′ ≈ P 1 � eZ where DiagMorPushout HP { A } { B } { C } FF GG = record R 1 � V ′ ≈ P 1 � eZ = ≈ -begin open Diagram { obj = mkDiagram ( record open DiagMor R 1 � eD � trU n 2 { mapN = PN.D 0 open HasPushouts compOp HP ≈ ⟨ � -cong 1 & 21 eDcommute-R ⟩ ; mapE = PE.eD -- open Pushout compOp eB � R 2 � trU n 2 ; congE = λ { n 1 } { n 2 } { e 1 } { e 2 } e 1 ≈ e 2 → let open PE in ≈ -sym ( eDunique e 1 module PN ( n ∶ Node ) where ≈ ⟨ � -cong 2 ( U-left n 2 ) ⟩ ( eDcommute-R e 2 ⟨ ≈≈ ˘ ⟩ � -cong 1 ( DMor-cong B e 1 ≈ e 2 )) F = transform FF n eB � P 2 ( eDcommute-S e 2 ⟨ ≈≈ ˘ ⟩ � -cong 1 ( DMor-cong C e 1 ≈ e 2 ))) G = transform GG n ≈ ˘ ⟨ commute P e ⟩ }) PO ∶ Pushout compOp F G P 1 � eZ ; left = record { transform = PN.R ; commute = PE.eDcommute-R } PO = pushout F G � ; right = record { transform = PN.S ; commute = PE.eDcommute-S } module PO = Pushout compOp PO S 1 � V ′ ≈ Q 1 � eZ ∶ S 1 � V ′ ≈ Q 1 � eZ ; prf = record open PO public using ( commutes ) renaming S 1 � V ′ ≈ Q 1 � eZ = ≈ -begin { commutes = PN.commutes ( obj to D 0 ; left to R ; right to S ; universal to PO-universal ) S 1 � eD � trU n 2 ; universal = λ { Z } { P } { Q } F � P ≈ G � Q → let module PE { n 1 n 2 ∶ Node } ( e ∶ Edge n 1 n 2 ) where ≈ ⟨ � -cong 1 & 21 eDcommute-S ⟩ open PN open PN n 1 public using () renaming eC � S 2 � trU n 2 trU = λ n → PO.univMor n ( F � P ≈ G � Q n ) ( F to F 1 ; G to G 1 ; R to R 1 ; S to S 1 ≈ ⟨ � -cong 2 ( U-right n 2 ) ⟩ U-left ∶ ( n ∶ Node ) → R n � trU n ≈ transform P n ; PO-universal to PO 1 -universal ) eC � Q 2 U-left n = PO.univMor-factors-left n ( F � P ≈ G � Q n ) open PN n 2 public using () renaming ( commutes to commutes 2 ≈ ˘ ⟨ commute Q e ⟩ U-right ∶ ( n ∶ Node ) → S n � trU n ≈ transform Q n ; F to F 2 ; G to G 2 ; R to R 2 ; S to S 2 ; D 0 to D 2 ) Q 1 � eZ U-right n = PO.univMor-factors-right n ( F � P ≈ G � Q n ) eB = DMor B e U = record { transform = trU � eC = DMor C e ; commute = λ { n 1 } { n 2 } e → let eZ-commutes ∶ F n 1 � P 1 � eZ ≈ G n 1 � Q 1 � eZ R ′ = eB � R 2 P 1 = transform P n 1 eZ-commutes = � -cong 1 & 21 ( F � P ≈ G � Q n 1 ) S ′ = eC � S 2 Q 1 = transform Q n 1 F � R ′ ≈ G � S ′ ∶ F 1 � R ′ ≈ G 1 � S ′ ∃ !U ′ ∶ PushoutUniv compOp ( F n 1 ) ( G n 1 ) R 1 S 1 eZ-commutes P 2 = transform P n 2 F � R ′ ≈ G � S ′ = ≈ -begin Q 2 = transform Q n 2 ∃ !U ′ = PO.universal n 1 eZ-commutes F 1 � DMor B e � R 2 open PE e V ≈ U ′ = PushoutUniv.univMor-unique compOp eZ = DMor Z e ≈ ⟨ � -cong 1 & 21 ( commute FF e ) ⟩ ∃ !U ′ R 1 � V ≈ P 1 � eZ S 1 � V ≈ Q 1 � eZ DMor A e � F 2 � R 2 V = trU n 1 � eZ R 1 � V ≈ P 1 � eZ ∶ R 1 � V ≈ P 1 � eZ V ′ ≈ U ′ = PushoutUniv.univMor-unique compOp ≈ ⟨ � -cong 2 commutes 2 ⟩ DMor A e � ( G 2 � S 2 ) R 1 � V ≈ P 1 � eZ = � -assocL ⟨ ≈≈ ⟩ � -cong 1 ( U-left n 1 ) ∃ !U ′ R 1 � V ′ ≈ P 1 � eZ S 1 � V ′ ≈ Q 1 � eZ S 1 � V ≈ Q 1 � eZ ∶ S 1 � V ≈ Q 1 � eZ ≈ ˘ ⟨ � -cong 1 & 21 ( commute GG e ) ⟩ in V ≈ U ′ ⟨ ≈≈ ˘ ⟩ V ′ ≈ U ′ G 1 � DMor C e � S 2 S 1 � V ≈ Q 1 � eZ = � -assocL ⟨ ≈≈ ⟩ � -cong 1 ( U-right n 1 ) } V ′ = eD � trU n 2 � in record eU ∶ PushoutUniv compOp F 1 G 1 R 1 S 1 F � R ′ ≈ G � S ′ { univMor = U eU = PO 1 -universal { D 2 } { R ′ } { S ′ } F � R ′ ≈ G � S ′ ; univMor-factors-left = U-left eD = PushoutUniv.univMor compOp eU ; univMor-factors-right = U-right eDcommute-R ∶ R 1 � eD ≈ R ′ ; univMor-unique = λ { V } R � V ≈ P S � V ≈ Q n → eDcommute-R = PushoutUniv.univMor-factors-left compOp eU PushoutUniv.univMor-unique compOp ( PO.universal n ( F � P ≈ G � Q n )) eDcommute-S ∶ S 1 � eD ≈ S ′ { transform V n } ( R � V ≈ P n ) ( S � V ≈ Q n ) eDcommute-S = PushoutUniv.univMor-factors-right compOp eU } eDunique ∶ ∀ { V } → R 1 � V ≈ R ′ → S 1 � V ≈ S ′ → V ≈ eD } eDunique = PushoutUniv.univMor-unique compOp eU } DiagMorHasPushouts ∶ HasPushouts compOp → HasPushouts DiagMorCompOp DiagMorHasPushouts HP = record { pushout = DiagMorPushout HP }

  6. My Choice for Formalisation and Implementation: Agda Agda is a dependently typed functional programming language Agda is a proof assistant based on Per Martin-Löf’s intuitionistic type theory Syntactically and “culturally” close to Haskell Different semantics: strongly normalising, no � values Dependently typed: No distinction between terms, types, and kinds “Just a mechanised mathematical notation” that lets me write the mathematics in a natural way Normalisation provides execution: � ⇒ Programming inside mathematics

Recommend


More recommend