GAPT + Scala: Design Considerations and Examples - Theory and

GAPT + Scala: Design Considerations andExamples

Tomer Lı́bal

Amadeus Project on Proof Compression

May 29th, 2012

Introduction

I Several different projects related to proof theory

I All need implementations

I Decision→ design a general framework

I Programming language - Scala

I Many design decisions

1 / 44

Outline

GAPT - Aims

Scala

GAPT + Scala

From Theory to PracticeLanguages SupportAutomated Prover

2 / 44

Outline

GAPT - Aims

Scala

GAPT + Scala


3 / 44

Generality

I Different languages: λ-calculus First-order logic, etc.

I Different calculi: LK Resolution, etc.

I General algorithms: Unification, Cut-elimination, etc.

I General applications: Theorem provers, user interfaces, etc.

4 / 44

Flexibility

I Time constraints→ basic implementations

I Optimization of certain aspects later

I Several implementations for the same tasks

5 / 44

Community

I Developers with varying programming experience

I Skills in varying programming languages

I Varied theoretical background

6 / 44

Program

I Relatively bug-free

I Elegant and intuitive code

I Easy to read and well-documented code

I Algorithms at the frontier of research

I Rigorous and tested

7 / 44

Not among the aims

I Efficiency, although it should be supported if required

8 / 44

Outline

GAPT - Aims

Scala

GAPT + Scala


9 / 44

Quick overview

I Runs on Java Virtual Machine and is compatible with Java

I Support both Functional and OOP programming paradigms

I Although features set contains that of Java, it is more concise andelegant

I Strongly and statically typed

I Unlike Java, has type inference

10 / 44

The functional programming paradigm -some characteristics

I Computation is done via evaluation of mathematical functions

I No side-effects are allowed

I Immutable data-structures

I Higher-order functions

I Algebraic datatypes

11 / 44

The functional programming paradigm -benefits

I Reduced number of bugs

I Closer to (logic) specifications

I Fast development of algorithms

I Code is intuitive and many times self-explanatory

12 / 44

The OOP programming paradigm - somecharacteristics

I Abstraction - a concept or idea not associated with any specificinstance

I Encapsulation - hiding the objects inner state, which can beaccessed via methods

I Polymorphism - an instance may have several types (classes,traits, etc.)

I Inheritence - creation of subtypes and code reuse

13 / 44

The OOP programming paradigm - benefits

I Decoupling of implementation from specification (interfaces/traits)

I Complex (static) typing of objects using classes (traits) is possible

I Modularity - each element implementation is decoupled from otherelements

I Modifiability and Extensibility - easy to change or extend the code

I Re-usability - elements can be easily re-used

I Design patterns - common coding habits are identified andoptimized

14 / 44

Multi-paradigms and Scala benefits

I OOP→ Functional - Extractors in order to expose the data asalgebraic and allow pattern matching on it

I Functional→ OOP - Functions are objects

I Strong and Static type system→ more bugs are detected incompile time

15 / 44

Outline

GAPT - Aims

Scala

GAPT + Scala


16 / 44

Putting in together

GAPT ScalaGenerality

17 / 44

Generality

I Different languages: λ-calculus First-order logic, etc.

I Different calculi: LK Resolution, etc.

I General algorithms: Unification, Cut-elimination, etc.

I General applications: Theorem provers, user interfaces, etc.

18 / 44

Putting in together

GAPT ScalaGenerality OOPFlexibility

19 / 44

Flexibility

I Time constraints→ basic implementations

I Optimization of certain aspects later

I Several implementations for the same tasks

20 / 44

Putting in together

GAPT ScalaGenerality OOPFlexibility OOPCommunity

21 / 44

Community

I Developers with varying programming experience

I Skills in varying programming languages

I Varied theoretical background

22 / 44

Putting in together

GAPT ScalaGenerality OOPFlexibility OOPCommunity OOP+FunctionalProgram

23 / 44

Program

I Relatively bug-free

I Elegant and intuitive code

I Easy to read and well-documented code

I Algorithms at the frontier of research

I Rigorous and tested

24 / 44

Putting in together

GAPT ScalaGenerality OOPFlexibility OOPCommunity OOP+FunctionalProgram Functional

I In general:I Data structures→ OOPI Algorithms→ Functional

25 / 44

Outline

GAPT - Aims

Scala

GAPT + Scala


26 / 44

Outline

GAPT - Aims

Scala

GAPT + Scala


27 / 44

Languages hierarchy

λ-calculus

Higher-order logic

First-order logic Schema

28 / 44

lambda.Var

t r a i t LambdaExpression extendsLambdaFactoryProvider w i thOrdered [ LambdaExpression ] {def exptype : TA. . .

}

c lass Var ( va l name : SymbolA , va l exptype : TA)extends LambdaExpression { . . . }

29 / 44

hol.Var

t r a i t HOLExpression extendsLambdaExpression wi th HOL

case ob jec t AndC extendsVar ( AndSymbol , ” ( o −> ( o −> o ) ) ” ) w i thConst w i th HOLExpression

I We distinguish higher-order variables and constans by havingdistinct symbols sets

I Const→ OOP: Abstraction and Polymorphism→ extra static typing

30 / 44

Factories

I The Abstract factory design pattern

31 / 44

Factories

t r a i t LambdaFactoryA {def createVar ( name : SymbolA ,

exptype : TA) : Vardef createAbs ( v a r i a b l e : Var ,

exp : LambdaExpression ) : Absdef createApp ( fun : LambdaExpression ,

arg : LambdaExpression ) : App}

I Each language DS has as a member and is created from a factory

32 / 44

Implementing a factory I

ob jec t LambdaFactory extends LambdaFactoryA {def createVar ( . . ) = new Var ( . . )def createAbs ( . . ) : Abs = new Abs ( . . )def createApp ( . . ) = new App ( f . . )

}

I The factory gives to each created element a reference to itself, forfuture creation of objects.

33 / 44

Implementing a factory II

ob jec t HOLFactory extends LambdaFactoryA {def createVar ( name : SymbolA , . . ) : Var =

name match {case a : ConstantSymbolA => . .case a : VariableSymbolA => . .

}def createApp ( . . ) : App =

. .}

I Pattern matching is a feature of functionl programming ..

34 / 44

From OOP to Functional - expose the ob-jects

ob jec t Var {def unapply ( expression : LambdaExpression ) =

expression match {case a : Var => Some( ( a . name, a . exptype ) )case => None

}}. .ob jec t App {

def unapply ( expression : LambdaExpression ) =expression match {

case a : App => Some( ( a . func t i on , a . argument ) )case => None

}}

35 / 44

Write functional-style code

def betaReduce ( expression : LambdaExpression ) :LambdaExpression => expression match {

case App ( abs : Abs , arg ) => . .case Var ( . . ) => . .case Abs ( . . ) => . .case App ( . . ) => . .}

}

I Beta-reduce can also be applied to HOL objects, etc. and willreturn HOL objects

36 / 44

Outline

GAPT - Aims

Scala

GAPT + Scala


37 / 44

ATP - aims

I Can be applied to any calculus over any languageI Can be interactive, automated or semi-automatedI Can be easily extended and modifiedI

I Is not optimized or particulary efficient

38 / 44

ATP - infrastructure

t r a i t Con f i gu ra t i on [S ] {def r e s u l t : Option [S ]

}

abs t r ac t c lass NDStream [S /∗ r e s u l t type ∗ / ] (va l i n i t i a l : Con f i gu ra t i on [S ] ,va l myFun :

Con f i gu ra t i on [S ] => I t e r a b l e [ Con f i gu ra t i on [S ] ]) extends SearchAlgor i thm {

va l r e s u l t s : Queue [S ]def next : Option [S ]. . .

}

39 / 44

The prover

t r a i t Prover {def r e f u t e (commands : Stream [Command ] ) :

NDStream [ Reso lu t ionProof ] = {new NDStream (new MyConf igurat ion (

new State ( ) , commands , ( )) , myFun) w i th BFSAlgorithm

}

def myFun( c : Con f i gu ra t i on [ Reso lu t ionProof ] ) :I t e r a b l e [ Con f i gu ra t i on [ Reso lu t ionProof ] ] = {. . .conf . commands . head match {

case com: Ini t ia lCommand => . . .case com: DataCommand =>

com( conf . s ta te , conf . data ) . map ( . . . )case com: ResultCommand => . . .

}40 / 44

The commands

I Commands are functions from (State,Data) to Iterable[(State,Data)]I Data is specific to each commandI For example:

case c lass ResolveCommand (a lg : U n i f i c a t i o n A l g o r i t h m )extends DataCommand [ Clause ] {def apply ( s t a t e : State , data : Any ) = {

/ / data i s a p a i r o f c lauses/ / r e s u l t i s a l l reso lvan ts ,/ / one f o r each u n i f i e r

}}

41 / 44

An example of a simple interactive prover

42 / 44

Replaying

I Since there is no focus on efficiency, third-party theorem proverscan be used

I Given an inference, the prover tries to infer the conclusion from thepremises via forward resolution

I The prover is initialized with a stream of finitely many groups (foreach inference) of inifintely many commands

I Since the third-party provers used are sound, the runs over eachgroup of commands terminate

I The obtained conclusion is added to the global clauses setI The final refutation contains only Robinson’s calculus rules and

para-modulation and includes all applied substitutionsI Forward resolution poses more difficulties than refutational

resolution and it is still an on-going work to solve all of them

43 / 44

I Thank you.

44 / 44

GAPT + Scala: Design Considerations and Examples - Theory and

Documents

Transcript of GAPT + Scala: Design Considerations and Examples - Theory and