🚀 go-pugleaf

In article <422@expya.UUCP> jtr@expya.UUCP (Jason Trenouth) writes:
>
>How do we go about building our OOPS? Well, the simplest way is to introduce
>the idea of delegation between modules (theories, objects, frames,...). 

I would expect a problem with this approach: since each object is
implemented as a module, and since each module must be written out
explicitly, the number of objects is fixed when you write your
program.  It is hard to see how you could have two stacks without
having to write two "stack" modules with different names.

>Now suppose that we query the "ehud" module about "limbs". Splat! The solver
>falls flat on its face and comes up with the answer 4. The reason is that it
>evaluates the procedure in the "human" module environment. How can we get
>round this? Somehow we need to tell "limbs" about where the query has come
>from originally.

Doesn't the Quintus module system have a way around this problem?

>With this interpreter, the above example query comes back with the correct
>answer of 3 arms. Like the first it also handles multiple delegations. These
>are searched depth first (like Flavors) by Prolog's backtracking;

The so-called New Flavors (in Genera 7, say) no longer uses a simple
depth-first ordering.  Instead there are constraints such as "A flavor
preceeds its components" and the total order is determined by a
topological sort.

>One question must be: where are the classes and instances? Er,... there just
>aren't any. In Flavors (and Smalltalk) classes contain the methods and some
>data, and act as templates. These are then used to create instances, which
>contain a copy of the data. This is an unnecessary restriction on object
>orientated programming.

Why is it a restriction?  Instances can be created dynamically: how do
you do that in your system?  (See my first papagraph of remarks.)

>The system above (POOPS?) and others (eg CommonOrbit)
>have only one type of object (called a "prototype" in CommonOrbit),
>which can be used more flexibly.

It is true that classes are not strictly necessary.  See various
papers that compare deligation with inheritance.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton