Re: mailing list

[trb@cs.mu.oz.au]

Hi Urs!

Thank you for putting me on the mailing list. I apologize for the vacant
message body. I expected that the message would be processed automatically
without meeting human eyes. Is there a news group for Self yet ?

I have just ftp'ed the Self system and had a play with it. I have also
read (quickly) some of the relevant papers and manuals. Self is
brilliant!!

The compute servers here have plenty of memory, but the X terminals
run out of memory starting the ui tutorial (I think they only have 8
Mb). Anyway I can run the ui without the tutorial just fine. I don't
have much time to learn at the moment. I am an honours student, and I
am supposed to be doing my research project right now (which concerns
declarative debugging of NUE-Prolog, an extension to our NU-Prolog to
allow the definition of equations (functions)).

Most people here (the University of Melbourne) don't know much about
OO languages. However the department is fairly strong in logic
languages. We even have one staff member (Andrew Davison, formerly of
Imperial College) who is interested in OO-LP languages (*with* mutable
state). I am very interested in this area too. Logic and
object-oriented languages each have powerful features that are lacking
in the other. Of course the difficulty is how to gain the benefits of
mutable state, while preserving declarative semantics. I note with
great interest the SRI research in ACI rewriting logic and MAUDE-LOG.
We have some people here writing a linear logic programming language,
which can express mutable state to some extent.

I have a suggestion regarding Self. I am not sure how much you are
involved with Self, so if this bores you maybe you could pass it on to
someone else.

The main advantages of logic languages are unification and declarative
semantics. It is not easy to see how Self can be given declarative
semantics, but I think there is no reason why it cannot have
unification. I have heard of people embedding Prolog in Smalltalk -
apparently one commercial Smalltalk had an embedded Prolog engine of
some kind. Since Self is so flexible, it should be possible to add
support for unification near the root of the object hierarchy (in
Smalltalk this would be done perhaps by modifying the behaviour of
Object, although I doubt whether Smalltalk is flexible enough to
accommodate such fundamental modification).

We have a group developing a pure logical language (i.e. one with *no*
non-logical features). According to them, Prolog is an imperative
language with unification and backtracking. I think that is strongly
stated, but true.  Therefore logical semantics is not essential to use
of unification (as demonstrated by Prolog).

Last year I was writing C++, having to collect my own garbage, and
wondering about Smalltalk. Passing large objects around in C++ is
hopelessly inefficient without using references supported by garbage
collection (I resorted to reference counting). I had some fun writing
a small template class which could be used to easily create
Smalltalk-like objects from standard types e.g.  obj<int> behaves just
like a standard integer, except that it is really a pointer to an
object on the heap which contains a standard integer and a reference
count. These things supported polymorphism and run-time type-checking.
I noticed that besides getting closer to Smalltalk, I was also getting
closer to Prolog. Each newly created variable, if not initialized at
creation, would contain the Nil object (would point to it).

Instead of initialized read instantiated. Uninitialized variables are
similar to uninstantiated Prolog variables. I envisage a unification
scheme as follows. For the unification of any two slots there are
three possibilities: both are initialized, neither are initialized,
one is initialized and the other is not. In the first case unification
succeeds iff the values are equal, after which both slots refer to the
same object. In the second case the uninitialized slot is made to
refer to the same object that the initialized slot refers to. In the
third case both slots delegate their values to a new object which is
uninitialized. When either slot subsequently becomes initialized,
actually the new object is initialized so that both slots refer to the
same object. Of course the values in the slots could be data or
methods.

Two objects would be unified by unifying all their slots. There are
some interesting questions here, since slots are identified by name
which is impossible in Prolog. The nearest thing Prolog has to objects
is terms, and their components are identified by *position*. Clearly
slots with the same name would have to unify for the whole unification
to succeed, but it is unclear what to do if a named slot is present in
one object but not the other. This could either be interpreted as
failure, or the other object would get a copy of the slot. The latter
produces an interesting kind of inheritance, but it is probably too
permissive - two arbitrary objects will typically have mostly
differently named slots and probably should not unify. Clearly
unification should not be attempted on the names of objects, since
this would always fail.

For logical and efficiency reasons it would be nice if the
representation of values was unique i.e. two slots could have the same
value if and only if they referred to the *same* object. That means it
would be possible to have two different slots with the same value, but
not possible to have that value stored in two different places on the
heap.

Adding unification to Self would not turn it into a logical language,
but it would at least serve as a powerful kind of pattern-matching.

It would be very difficult to add backtracking to Self. When you have
objects spread around, the last thing you want is backtracking. In
fact many parallel logic languages are unable to backtrack (but they
typically don't need to, since logical operations are run in
parallel). If goals could be run in parallel, then possibly Self
methods could contain logical subroutines.

I am not sure how these extensions would be used, but they might be useful.

Tim.