META-INTERPRETERS ANDMETA-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 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.

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. PREDICATESUSUALLY 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:

25 10 15 30

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).