META-INTERPRETERS AND META-PROGRAMMING Ivan Bratko Faculty of Computer and Info. Sc. Univ. of Ljubljana

BASIC META-INTERPRETER % The basic Prolog meta-interpreter prove( true). prove( ( Goal1, Goal2)) :- prove( Goal1), prove( Goal2). prove( Goal) :- clause( Goal, Body), prove( Body).

SIMPLE TRACING META-INTERPRETER prove( true) :- !. prove( ( Goal1, Goal2)) :- !, prove( Goal1), prove( Goal2). prove( Goal) :- write( 'Call: '), write( Goal), nl, clause( Goal, Body), prove( Body), write( 'Exit: '), write( Goal), nl.

TRACING META-INTERPRETER prove( true) :- !. prove( ( Goal1, Goal2)) :- !, prove( Goal1), prove( Goal2). prove( Goal) :- write( 'Call: '), write( Goal), nl, clause( Goal, Body), prove( Body), write( 'Exit: '), write( Goal), nl.

TRACING META-INTERPRETER WITH RETRY % trace( Goal): execute Prolog goal Goal displaying trace information trace( Goal) :- trace( Goal, 0). trace( true, Depth) :- !. % Red cut; Dept = depth of call trace( ( Goal1, Goal2), Depth) :- !, % Red cut trace( Goal1, Depth), trace( Goal2, Depth).

trace( Goal, Depth) :- display( 'Call: ', Goal, Depth), clause( Goal, Body), Depth1 is Depth + 1, trace( Body, Depth1), display( 'Exit: ', Goal, Depth), display_redo( Goal, Depth). trace( Goal, Depth) :- % All alternatives exhausted display( 'Fail: ', Goal, Depth), fail.

display( Message, Goal, Depth) :- tab( Depth), write( Message), write( Goal), nl. display_redo( Goal, Depth) :- true % First succeed simply ; display( 'Redo: ', Goal, Depth), % Then announce backtracking fail. % Force backtracking

METAINTERPRETER FOR PROLOG WITH CONSTRAINTS solve( Goal) :- solve( Goal, [ ], Constr). % Start with empty constr. % solve( Goal, InputConstraints, OutputConstraints) solve( true, Constr0, Constr0). solve( (G1, G2), Constr0, Constr) :- solve( G1, Constr0, Constr1), solve( G2, Constr1, Constr).

METAINTERPRETER CTD. solve( G, Constr0, Constr) :- prolog_goal( G), % G a Prolog goal clause( G, Body), % A clause about G solve( Body, Constr0, Constr). solve( G, Constr0, Constr) :- constraint_goal( G), % G a constraint merge_constraints( Constr0, G, Constr).

MERGE CONSTRAINTS  Predicate merge_constraints: constraint-specific problem solver, merges old and new constraints, tries to satisfy or simplify them  For example, two constraints X  3 and X  2 are simplified into constraint X  2.

GENERATING PROOF TREES % Prolog meta-interpreter that generates a proof tree :- op( 500, xfy, <== ). % prove( Goal, ProofTree) prove( true, true) :- !. prove( ( Goal1, Goal2), (Proof1, Proof2)) :- !, prove( Goal1, Proof1), prove( Goal2, Proof2). prove( Goal, Goal <== Proof) :- clause( Goal, Body), prove( Body, Proof ).

EXPLANATION-BASED GENERALISATION  EBG = Machine learning from one example only!  Lack of examples compensated by domain theory  Given:  Domain theory (can answer any question)  Operationality criteria  Training example  Find:  Generalisation of training example +  Operational definition of target concept (in terms of operational predicates)  Note: EBG can be viewed as a program compilation technique  Inefficient program (domain theory)  Efficient specialised program

A DOMAIN THEORY ABOUT GIFTS % Figure 23.3 Two problem definitions for explanation-based generalization. % For compatibility with some Prologs the following predicates % are defined as dynamic: :- dynamic gives/3, would_please/2, would_comfort/2, feels_sorry_for/2, likes/2, needs/2, sad/1, go/3, move/2, move_list/2.

% A domain theory: about gifts gives( Person1, Person2, Gift) :- likes( Person1, Person2), would_please( Gift, Person2). gives( Person1, Person2, Gift) :- feels_sorry_for( Person1, Person2), would_comfort( Gift, Person2).

would_please( Gift, Person) :- needs( Person, Gift). would_comfort( Gift, Person) :- likes( Person, Gift). feels_sorry_for( Person1, Person2) :- likes( Person1, Person2), sad( Person2). feels_sorry_for( Person, Person) :- sad( Person).

% Operational predicates operational( likes( _, _)). operational( needs( _, _)). operational( sad( _)). % An example situation likes( john, annie). likes( annie, john). likes( john, chocolate). needs( annie, tennis_racket). sad( john).

THEORY ABOUT LIFTS % Another domain theory: about lift movement % go( Level, GoalLevel, Moves) if % list of moves Moves brings lift from Level to GoalLevel go( Level, GoalLevel, Moves) :- move_list( Moves, Distance), % A move list and distance travelled Distance =:= GoalLevel - Level. move_list( [], 0). move_list( [Move1 | Moves], Distance + Distance1) :- move_list( Moves, Distance), move( Move1, Distance1). move( up, 1). move( down, -1). operational( A =:= B).

LIFTS % Another domain theory: about lift movement % go( Level, GoalLevel, Moves) if % list of moves Moves brings lift from Level to GoalLevel go( Level, GoalLevel, Moves) :- move_list( Moves, Distance), % A move list and distance travelled Distance =:= GoalLevel - Level. move_list( [], 0). move_list( [Move1 | Moves], Distance + Distance1) :- move_list( Moves, Distance), move( Move1, Distance1). move( up, 1). move( down, -1). operational( A =:= B).

GIFTS THEORY gives( P1, P2, G) likes(P1,P2) would_please(G,P2) feels_sorry_for(P1,P2) would_comfort(G,P2) P1=P2 needs( P2, G) likes(P1,P2) sad(P2) sad(P1) likes(P,G)

Training example gives( P1, P2, G) likes(P1,P2) would_please(G,P2) feels_sorry_for(P1,P2) would_comfort(G,P2) P1=P2 needs( P2, G) likes(P1,P2) sad(P2) sad(P1) likes(P,G) gives(john,john,chocolate)

EBG AS PROLOG META-INTERPRETER % ebg( Goal, GeneralizedGoal, SufficientCondition) if % SufficientCondition in terms of operational predicates % guarantees that generalization of Goal, GeneralizedGoal, is true. % GeneralizedGoal must not be a variable

ebg( true, true, true) :- !. ebg( Goal, GenGoal, GenGoal) :- operational( GenGoal), call( Goal). ebg( (Goal1,Goal2), (Gen1,Gen2), Cond) :- !, ebg( Goal1, Gen1, Cond1), ebg( Goal2, Gen2, Cond2), and( Cond1, Cond2, Cond). % Cond = (Cond1,Cond2) simplified ebg( Goal, GenGoal, Cond) :- not operational( Goal), clause( GenGoal, GenBody), copy_term( (GenGoal,GenBody), (Goal,Body)), % Fresh copy of % (GenGoal,GenBody) ebg( Body, GenBody, Cond). EBG, CTD.

% and( Cond1, Cond2, Cond) if % Cond is (possibly simplified) conjunction of Cond1 and Cond2 and( true, Cond, Cond) :- !. % (true and Cond) Cond and( Cond, true, Cond) :- !. % (Cond and true) Cond and( Cond1, Cond2, ( Cond1, Cond2)).

WHY: copy_term( (GenGoal,GenBody), (Goal,Body))  Proofs of Goal and GenGoal follow the same structure  They both must use the same program clause: GenGoal :- GenBody.  This is checked by matching: (Goal :- Body) = (GenGoal :- GenBody)  But, this check must be done without changing GenBody  Therefore: copy_term( (GG,GB),...) produces a copy (GG’,GB’), and this is matched: (GG’,GB’) = (Goal,Body)

EXPLANATION-BASED GENERALISATION  What is the logical relation between generalised goal GENGOAL and derived operational condition COND?  What is the role of the example in EBG?  What is the difference between EBG and goal unfolding?

ABDUCTIVE REASONING  Types of logical reasoning:  deduction  induction  abduction  Abduction useful for explanation, construction, planning, e.g.:  patient’s symptoms  systems failures  Disease D causes symptom S; patient P has symptom S;  So, infer that P has D  Abduction considered as unsound rule of inference

FORMALLY  Given a Theory and an Observation  Find an Explanation, such that Theory & Explanation |== Observation  Compare with definition of ILP: given BK and Examples, find Hypothesis such that: BK & Hypothesis |-- Examples  Discuss differences between abductive and inductive reasoning

% An example from Missiaen, Bruynooghe, Denecker 92 :- dynamic faulty/1, lamp/1, current_break/1. % Needed in SICStus by clause/2 faulty( L) :- % Device L faulty - doesn't work lamp( L), % Device is a lamp broken( L). % Lamp broken faulty( L) :- lamp( L), current_break( L). % No electric current in lamp current_break( L) :- fuse( L, F), % Fuse F connected to lamp L melted( F). % Fuse F is melted current_break( L) :- general_power_failure. lamp( a). lamp( b). abducible( broken( Device)). abducible( fuse( Device, Fuse)). abducible( melted( Fuse)). abducible( general_power_failure).

ABDUCING METAINTERPRETER % abduce( Goal, Delta): Delta is a list of abduced literals abduce( Goal, Delta) :- abduce( Goal, [ ], Delta). % abduce( Goal, Delta0, Delta): % Delta 0 is "accumulator" variable with Delta as its final value abduce( true, Delta, Delta) :- !. abduce( ( Goal1, Goal2), Delta0, Delta) :- !, abduce( Goal1, Delta0, Delta1), abduce( Goal2, Delta1, Delta). abduce( Goal, Delta0, Delta) :- clause( Goal, Body), abduce( Body, Delta0, Delta).

ABDUCING METAINTERPRETER, CTD. % Now abduction reasoning steps: abduce( Goal, Delta, Delta) :- member( Goal, Delta). % Already abduced abduce( Goal, Delta, [Goal | Delta]) :- abducible( Goal), retract( index( I)), !, % Lowest free index for new constants numbervars( Goal, I, J), % Replace variables by Skolem constants asserta( index( J)). % Next free index

ABDUCTION, AUX. PREDICATES :- dynamic index/1. index( 1). member( X, [X | L]). member( X, [Y | L]) :- member( X, L).

ABDUCTION, AUX. PREDICATES USUALLY PROLOG BUILT-IN numbervars( Term, N0, N) :- var( Term), !, Term = var/N0, N is N0 + 1 ; atomic( Term), !, N = N0 ; Term =.. [Fun | Args], numberargs( Args, N0, N). numberargs( [], N, N). numberargs( [ Arg | Args], N0, N) :- numbervars( Arg, N0, N1), numberargs( Args, N1, N).

PATTERN-DIRECTED SYSTEMS  Set of program modules executed in parallel  Module’s execution triggered by patterns in their data environment  Similar to Blackboard Systems Data environment

EXAMPLE  Greatest common divisor D of A and B: while A and B not equal, do if A > B replace A := A - B else replace B := B - A D = A (or B)  Pattern directed modules ConditionPart ---> ActionPart [ Cond1, Cond2,...] ---> [ Action1, Action2,...]

PATTERN-DIRECTED PROGRAM FOR GCD :- op( 800, xfx, --->). :- op( 300, fx, num). [ num X, num Y, X > Y ] ---> [ NewX is X - Y, replace( num X, num NewX) ]. [ num X] ---> [ write( X), stop ]. % An initial database num 25. num 10. num 15. num 30.

TRACE OF THIS PROGRAM  Data environment initially contains:  Program works for any number of numbers! Trace execution here

% A small interpreter for pattern-directed programs % The system's database is manipulated through assert/retract :- op( 800, xfx, --->). % run: execute production rules of the form % Condition ---> Action until action `stop' is triggered run :- Condition ---> Action, % A production rule test( Condition), % Precondition satisfied? execute( Action).

% test( [ Condition1, Condition2,...]) if all conditions true test( []). % Empty condition test( [First|Rest]) :- % Test conjunctive condition call( First), test( Rest). % execute( [ Action1, Action2,...]): execute list of actions execute( [ stop]) :- !. % Stop execution execute( []) :- % Empty action (execution cycle completed) run. % Continue with next execution cycle execute( [First | Rest]) :- call( First), execute( Rest). replace( A, B) :- % Replace A with B in database retract( A), !, % Retract once only assert( B).