Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!pacbell!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!agate!eos!labrea!csli!johnson
From: johnson@csli.STANFORD.EDU (Mark Johnson)
Newsgroups: comp.lang.prolog
Subject: Re: oops
Message-ID: <4154@csli.STANFORD.EDU>
Date: 2 Jun 88 19:47:05 GMT
Article-I.D.: csli.4154
References: <422@expya.UUCP>
Reply-To: markj@cogito.mit.edu (Mark Johnson)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 117


/*

I saw a message on the bboard a while ago about object-oriented
programming in Prolog.  After a few minutes thought, it struck me
that the main question about OOPS is inheritance; specifically,
who inherits what from whom.  

Anyway, below is a fragment which in which the object hierachy
is represented by an is_a graph.  Inheritance is defined
with respect to specific properties; it is assumed that
a daughter inherits a property from its mother unless explicitly
marked as not doing so.  Tweety inherits all the properties
of birds except that of flying, for example.

As it's built, using the system involves first finding an
ancestor from who a given node can inherit the relevant
property, and then calling the property on the ancestor.  However,
it would be easy to combine the two steps using meta-level
operations or (better) input preprocessing, I think.

This system differs from standard OOPS in two ways. First, *all*
accessible superordinate nodes are considered, rather than the 
"first" one reached via some particular search strategy. Second,
inheritance is not "blocked" just because a predicate is defined
for a particular object.

Even though it would be simple to build a system with the
"standard OOPS" behaviour, it's not clear to me that one
should.  I suspect that the major reason that "standard OOPS"
have the behaviour that they do is because they are based on
functional rather than relational programming systems in which
there is no sensible way to compose "properties" inherited
from different ancestors.

Anyway, this is only a first pass on the subject.  I'd like
to hear any reactions you might have,

Mark Johnson
markj@cogito.mit.edu

*/

/*  A toy object-oriented system */

:- ensure_loaded(library(not)).
:- no_style_check(discontiguous).

:- op( 100, xfx, is_a ).
:- op( 100, xfx, doesnt_inherit ).

/*  object's definitions */

tweety is_a bird.		% tweety's defs
tweety doesnt_inherit walking.	%  tweety's gotta walk
tweety doesnt_inherit flying.	%  'cause he can't fly!
walks(tweety).

polly is_a bird.		% polly's defs

bird is_a animal.		% bird's defs
bird doesnt_inherit flying.
bird doesnt_inherit walking.	%  why walk when
flies(bird).			%  you can fly?
eats( bird, seeds ).

lion is_a animal.		% lion's defs
lion doesnt_inherit food.	%  lion food is special!
eats( lion, meat ).

walks(animal).			% animal's defs
eats( animal, vegetables).	%  Most animals eat vegetables

/*  inherits(Obj,Prop,Super) iff Obj inherits Prop from Super. */

inherits(Obj, _, Obj).	% All objects inherit from themselves.
inherits(Obj, Prop, Super ) :-
	not Obj doesnt_inherit Prop,
	is_a( Obj, Parent),
	inherits( Parent, Prop, Super ).

can_fly(X) :-
	inherits( X, flying, Super),
	flies( Super ).

can_walk(X) :-
	inherits( X, walking, Super),
	walks( Super ).

can_eat(X,Food) :-
	inherits( X, food, Super),
	eats( Super, Food).

/*  Sample run.

| ?- can_walk(polly).

no
| ?- can_fly(tweety).

no
| ?- can_eat(polly,Food).

Food = seeds ;

Food = vegetables ;

no
| ?- can_walk(lion).

yes
| ?- can_eat(lion,Food).

Food = meat ;

no
*/