Change Management in Declarative Languages Mihnea Iancu and Florian - - PowerPoint PPT Presentation

▶

Nov 09, 2023 345 likes •824 views

Change Management in Declarative Languages Mihnea Iancu and Florian Rabe Jacobs University Bremen July 13, 2012 1 / 22 Motivation mathematical knowledge grows relentlessly mathematics is intrinsically inter-connected formal mathematical

SLIDE 1

Change Management in Declarative Languages

Mihnea Iancu and Florian Rabe

Jacobs University Bremen

July 13, 2012

1 / 22

SLIDE 2

Motivation

mathematical knowledge grows relentlessly mathematics is intrinsically inter-connected formal mathematical libraries already too large to oversee need for adequate change management solutions

2 / 22

SLIDE 3

Motivation: LATIN Library

LATIN : an atlas of logic formalizations

inter-connected network of ∼1000 modules based on the MMT/LF logical framework highly modular (Little Theories approach)

difficult to keep an overview (modularity helps but is not enough)

which declarations does the symbol s depend on which declarations depend on the symbol s

3 / 22

SLIDE 4

LATIN Library : Modularity

4 / 22

SLIDE 5

Mmt

a Module System for Mathematical Theories generic declarative language

theories, morphisms, declarations, expressions module system

OMDoc/OpenMath-based XML syntax with Scala-based API foundationally independent

no commitment to a particular logic or logical framework both represented as Mmt theories concise and natural representation of a variety of systems e.g. Twelf, Mizar, TPTP, OWL

5 / 22

SLIDE 6

Mmt-based MKM services

Foundation independence → Mmt services carry over to languages represented in Mmt presentation

MKM 2008

interactive browsing

MKM 2009

database

MKM 2010

archival, project management

MKM 2011

querying

Tuesday, MKM 2012

editing (work in progress)

Wednesday, UITP 2012

management of change (MoC)

now, AISC 2012

6 / 22

SLIDE 7

Outline

Management of Change

MoC is not a new topic; usually involves

detect changes see if/how something changed compute affected items maintain some notion of dependency handle/identify conflicts in SE typically re-compile e.g. Eclipse

7 / 22

SLIDE 8

Outline

Management of Change

MoC is not a new topic; usually involves

detect changes see if/how something changed compute affected items maintain some notion of dependency handle/identify conflicts in SE typically re-compile e.g. Eclipse

Outline

semantic differencing fine-grained dependencies impact propagation some form of a validity guarantee

7 / 22

SLIDE 9

Mmt Example

Mmt Notions

theories contain constant declarations constants have components (type and definiens) components represented as Mmt/OpenMath terms URIs for each theory/constant/component Rev1 PL = { bool : type ⇒ : bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) }

8 / 22

SLIDE 10

Mmt Example

Mmt Notions

theories contain constant declarations constants have components (type and definiens) components represented as Mmt/OpenMath terms URIs for each theory/constant/component Rev1 PL = { bool : type ⇒ : bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) }

8 / 22

SLIDE 11

Semantic Differencing

we extend Mmt with a language of changes

add (A) and delete (D) constants update (U) components rename (R) constants

Diff ∆ ::= · | ∆, δ Change δ ::= A(T, c : ω = ω′) | D(T, c : ω = ω′) | U(T, c, o, ω, ω′) | R(T, c, c′) Component

tp | def

9 / 22

SLIDE 12

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) }

10 / 22

SLIDE 13

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form)

10 / 22

SLIDE 14

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form)

10 / 22

SLIDE 15

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form) ∆2 = D(PL, bool : type), A(PL, form : type), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form)

10 / 22

SLIDE 16

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form) ∆2 = D(PL, bool : type), A(PL, form : type), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form)

10 / 22

SLIDE 17

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form) ∆2 = D(PL, bool : type), A(PL, form : type), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆3 = R(PL, bool, form), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form)

10 / 22

SLIDE 18

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form) ∆2 = D(PL, bool : type), A(PL, form : type), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆3 = R(PL, bool, form), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form)

10 / 22

SLIDE 19

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form) ∆2 = D(PL, bool : type), A(PL, form : type), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆3 = R(PL, bool, form), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆4 = D(PL, bool : type), D(PL, x : type)

10 / 22

SLIDE 20

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form) ∆2 = D(PL, bool : type), A(PL, form : type), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆3 = R(PL, bool, form), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆4 = D(PL, bool : type), D(PL, x : type)

10 / 22

SLIDE 21

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form) ∆2 = D(PL, bool : type), A(PL, form : type), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆3 = R(PL, bool, form), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆4 = D(PL, bool : type), D(PL, x : type)

10 / 22

SLIDE 22

Example Revisited

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } Rev2 PL = { form : type ¬ : form → form ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } ∆1 = D(PL, bool : type), A(PL, form : type), A(PL, ¬ : form → form) ∆2 = D(PL, bool : type), A(PL, form : type), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆3 = R(PL, bool, form), D(PL, ⇒: bool → bool → bool), A(PL, ¬ : form → form) ∆4 = D(PL, bool : type), D(PL, x : type)

10 / 22

SLIDE 23

Semantic Differencing: Formal Properties

change detection (G′ − G)

identify differences between two theory graphs

change application (G ≪ ∆)

apply changes to a theory graph

11 / 22

SLIDE 24

Semantic Differencing: Formal Properties

change detection (G′ − G)

identify differences between two theory graphs

change application (G ≪ ∆)

apply changes to a theory graph

G-applicability

∆1 applicable to G iff it can be applied to G

11 / 22

SLIDE 25

Semantic Differencing: Formal Properties

change detection (G′ − G)

identify differences between two theory graphs

change application (G ≪ ∆)

apply changes to a theory graph

G-applicability

∆1 applicable to G iff it can be applied to G

G-equivalence (≡G)

∆1 ≡G ∆2 iff G ≪ ∆1 = G ≪ ∆2

11 / 22

SLIDE 26

Semantic Differencing: Formal Properties

change detection (G′ − G)

identify differences between two theory graphs

change application (G ≪ ∆)

apply changes to a theory graph

G-applicability

∆1 applicable to G iff it can be applied to G

G-equivalence (≡G)

∆1 ≡G ∆2 iff G ≪ ∆1 = G ≪ ∆2

normal diffs

minimal representatives w.r.t. ≡G

11 / 22

SLIDE 27

Semantic Differencing: Formal Properties

change detection (G′ − G)

identify differences between two theory graphs

change application (G ≪ ∆)

apply changes to a theory graph

G-applicability

∆1 applicable to G iff it can be applied to G

G-equivalence (≡G)

∆1 ≡G ∆2 iff G ≪ ∆1 = G ≪ ∆2

normal diffs

minimal representatives w.r.t. ≡G

inversability of diffs

G ≪ ∆ ≪ ∆−1 = G

11 / 22

SLIDE 28

Semantic Differencing: Implementation

Change Detection (G′ − G)

view theory graphs as (nested) URI-indexed tables of declarations. new URIs → adds, old URIs → deletes, preserved URIs → (if changed) updates. refine the resulting diff by replacing add-delete pairs that represent a rename with the corresponding rename

12 / 22

SLIDE 29

Semantic Differencing: Implementation

Change Detection (G′ − G)

view theory graphs as (nested) URI-indexed tables of declarations. new URIs → adds, old URIs → deletes, preserved URIs → (if changed) updates. refine the resulting diff by replacing add-delete pairs that represent a rename with the corresponding rename

Change Application (G ≪ ∆)

follow the intuitive semantics of each change apply (in order) the changes from ∆ to G (if G-applicable)

12 / 22

SLIDE 30

Fine-grained dependencies

in Mmt, validation units are individual components (types and definiens) we distinguish two types of dependencies

syntactic dependencies

declaration level foundation-independent

ccurs-in relation

semantic dependencies

component level foundation-dependent trace lookups during foundational validation

13 / 22

SLIDE 31

Fine-grained dependencies

in Mmt, validation units are individual components (types and definiens) we distinguish two types of dependencies

syntactic dependencies

declaration level foundation-independent

ccurs-in relation

semantic dependencies

component level foundation-dependent trace lookups during foundational validation

dependencies are indexed by MMT and are available at any time

13 / 22

SLIDE 32

Example Revisited - Again

Rev1 PL = { bool : type ⇒: bool → bool → bool ∧ : bool → bool → bool ⇔: bool → bool → bool = λx.λy.(x ⇒ y) ∧ (y ⇒ x) } bool/tp ⇒/tp ∧/tp ⇔/tp ⇔ /def

14 / 22

SLIDE 33

Impact Propagation

key idea : propagation as diff enrichment process impact propagation of a diff ∆ is another diff ∆ that :

marks impacted components by surrounding with OpenMath error terms automatically propagates renames updates in-term references

15 / 22

SLIDE 34

Impact Propagation

key idea : propagation as diff enrichment process impact propagation of a diff ∆ is another diff ∆ that :

marks impacted components by surrounding with OpenMath error terms automatically propagates renames updates in-term references

Theorem

After all error terms are replaced with valid terms in G ≪ ∆ ≪ ∆, the resulting theory graph is valid.

15 / 22

SLIDE 35

Workflow Example (relative to a graph G)

∆ ∆, ∆ G′ G′′ Propagator Diffs Graphs x − G G ≪ x

16 / 22

SLIDE 36

Example Revisited - Yet Again

∆ = U(PL, ⇔, def, λx.λy.(x ⇒ y) ∧ (y ⇒ x), λx.λy.(x ⇒ y) ∧ (y ⇒ x) ), U(PL, ∧, tp, bool →bool →bool, form→form→form), U(PL, ⇔, tp, bool →bool →bool, form→form→form)

PL = { form : type ¬ : form → form ∧ : form → form → form ⇔: form → form → form = λx.λy.(x ⇒ y) ∧ (y ⇒ x)) }

17 / 22

SLIDE 37

Evaluation : LATIN

Dependencies Components (%) 0 − 5 1373 (79) 6 − 10 271 (15.6) 11 − 15 81 (4.7) 16 − 26 13 (0.7) Impacts Components (%) 0 − 5 1504 (86.5) 6 − 10 101 (5.8) 11 − 25 76 (4.4) 26 − 50 31 (1.8) 50 − 449 26 (1.5)

generally low number of impacts

due to modularity

however, high variance of impacts

creates need for detection tools

n average, types have 3 times more impacts than definiens

validates our fine-grained approach

18 / 22

SLIDE 38

Observations

at all steps renames (R) require special treatment

good at the user level more change types means more change semantics bad at the system level more change types means more complex formalization

19 / 22

SLIDE 39

Observations

at all steps renames (R) require special treatment

good at the user level more change types means more change semantics bad at the system level more change types means more complex formalization

underlying problem: conflicting requirements for the change language

simple vs expressive

19 / 22

SLIDE 40

Observations

at all steps renames (R) require special treatment

good at the user level more change types means more change semantics bad at the system level more change types means more complex formalization

underlying problem: conflicting requirements for the change language

simple vs expressive

solution : extensibility

regular and minimal core language add, delete, update enlarge expressivity through refinements rename

19 / 22

SLIDE 41

Observations

at all steps renames (R) require special treatment

good at the user level more change types means more change semantics bad at the system level more change types means more complex formalization

underlying problem: conflicting requirements for the change language

simple vs expressive

solution : extensibility

regular and minimal core language add, delete, update enlarge expressivity through refinements rename, merge

19 / 22

SLIDE 42

Observations

at all steps renames (R) require special treatment

good at the user level more change types means more change semantics bad at the system level more change types means more complex formalization

underlying problem: conflicting requirements for the change language

simple vs expressive

solution : extensibility

regular and minimal core language add, delete, update enlarge expressivity through refinements rename, merge, split

19 / 22

SLIDE 43

Observations

at all steps renames (R) require special treatment

good at the user level more change types means more change semantics bad at the system level more change types means more complex formalization

underlying problem: conflicting requirements for the change language

simple vs expressive

solution : extensibility

regular and minimal core language add, delete, update enlarge expressivity through refinements rename, merge, split, alpha-renaming

19 / 22

SLIDE 44

Observations

at all steps renames (R) require special treatment

good at the user level more change types means more change semantics bad at the system level more change types means more complex formalization

underlying problem: conflicting requirements for the change language

simple vs expressive

solution : extensibility

regular and minimal core language add, delete, update enlarge expressivity through refinements rename, merge, split, alpha-renaming, . . .

19 / 22

SLIDE 45

Workflow Example (relative to a graph G) – Again

∆ ∆, ∆ G′ G′′ Propagator Diffs Graphs x − G G ≪ x

20 / 22

SLIDE 46

Workflow Example (relative to a graph G) – Better

∆ ∆′ ∆′, ∆′ G′ G′′ Propagator Diffs Graphs Refine x − G G ≪ x

21 / 22

SLIDE 47

Conclusion and Future Work

Mmt MoC : a change management solution for Mmt

formal definition, theorems supports transactions and roll-backs uses fine-grained semantic dependencies implemented in the Mmt API

future work (currently in progress)

refinement (add flexibility to the change language) towards an Mmt theory of refactoring integration with user interfaces

22 / 22