Cross-Paradigm Learning Re: Modifying Software

[Jack Waugh]

> >So in Self,
> >and in the actual practice of typical
> >Self programmers, and with the
> >support of typical Self programming
> >environments, is there any way to
> >modify software so that many existing
> >objects change their behavior to
> >reflect the modification?

> Most of the objects in the system
> inherit their behaviours off a group 
> of objects that are linked from the
> Traits object. Modifying these 
> Traits' objects immediately changes
> the behaviours of all such objects.

The above is the straightforward answer to my question.  Yes, Self
does support the feature I asked about:  The change in behavior of the
many objects comes about through the _inheritance_ from object to
object that characterizes Self.  Thank you.

Now I'll reveal why I ask it.

I'm interested in ToonTalk and other concurrent constraint languages
(this feeds into my interest in lazy functional languages supporting
nondeterminism, and that in turn feeds into my ultimate interests in
tranparent persistency and in respect for the temporal priorities of
human beings in contact with computers).  ToonTalk's semantics in
action is currently reachable only through an animated syntax.  I
imagine substituting a textual syntax.  More to the point, ToonTalk
(TT) is probably still too low-level a language in which to engineer
industrial solutions to industrial problems.  So I think of some
higher-level variant with the software engineering advantages of Self
or Smalltalk while retaining the temporal model of ToonTalk and its
relatives.

ToonTalk's basic unit of code, somewhat analogous to a method, is the
_robot_.  A robot is kind of a Horn clause, that is, it has a pattern
for a head, and when the pattern matches to the presented data, the
body is executed atomically.

Self and Smalltalk show ways to organize code in a body of software,
and, at least for sequential code using shared memory
(Hoarism/Dijkstraism), Self and Smalltalk show (in different ways from
each other) how modifications to code can affect a running system with
test data in it or real data.  What I'm interested in with this
question is how to apply these lessons from Self or Smalltalk, over in
the concurrent-constraint world.

ToonTalk doesn't inherently suggest any distinguished scheme of
organization for keeping track of programmed robots and what purposes
they were programmed for.  The programmer currently has to cobble up
her own organization, or stay disorganized.  Robots can be passed
around like numbers, text, and other arguments.  Robots (and other
value carriers) can be put on the pages of a "notebook" and other
robots can be trained to turn to the appropriate pages and copy off
the robots from the notebook and invoke them as needed or pass them in
data structures so someone will eventually invoke them.  These passed
robots are copies, not references.

The only reference mechanism in ToonTalk is a "bird", which can carry
messages to its "nest".  The nest may be in a context where whatever
has been placed in it by the bird will figure in a pattern match,
resulting in the firing of a matching Horn clause (robot).  Thus,
messages can be received, recognized, interpreted, and replied to.

Info on ToonTalk -- http://groups.yahoo.com/group/ToonTalk/links

A higher-level variant of ToonTalk, one more oriented to the needs of
software engineering, might organize the robots somehow and provide
some kind of inheritance so that the behavior of processes updates as
soon as they find out about software changes.  One way to approach
this is to say that the robots actually engaged in application to
data, or we could say actually engaged in processes, stop being copies
as in today's ToonTalk, and in such a variant of the language, become
references of some kind.  Another conceivable way to approach it is to
say that most invocations of code from the body of software happen via
requests sent via birds.  Such an approach would preserve the basic
ToonTalk constraint that the only reference mechanism should be the
bird/nest regime.

Any thoughts from those steeped in Self but willing to consider how to
apply Self's lessons on how a language can support good software
engineering, in a different world, a world where generally we want to
avoid shared access to mutable memory except via a very structured
message mechanism (the bird or its variants in other concurrent
constraint or actor languages), would interest me.

In solidarity for IT's service to humanity,
Jack Waugh