coherent states

[David Manifold]

Sorry I took so long.  I'll leave most of the quotes intact for context,
since the original message was over a month ago.

On Wed, 24 Jun 1998, Jecel Assumpcao Jr wrote:

> David Manifold wrote:
> Ok - this confirms that graphs are possible. So let's explore
> "decentralized".  Can I extend this to "distributed"? That is
> where I have problems. Suppose I have a machine running Tunes
> and you have another computer running it too. Would each
> machine have a full copy of everything in the system (a
> fully overlapped state)? Would we each get half of the
> state (totally disjoint partition)? This last option isn't
> practical unless you have an ideal communication system. We
> might each a copy of some common part of the state plus some
> local state that is not shared (partial overlap). In any case,
> if I edit my copy of the common state then it will be different
> from what you are using. You can make other changes which will
> then make it impossible for us to merge our edits into a single
> coherent state.

See _Shared minds: the new technologies of collaboration_, by Michael
Schrage.  There are a lot of tools for current systems that give you a
shared whiteboard type of paradigm.  I intend for TUNES to support the
"shared context" as a fundamental feature.  For example, the keyboard
buffer is defined as a queue, and it is shared by the hardware driver
writing one end of the queue and some current application reading the
other end.  More complicated spaces, like documents, or any data type, can
be shared by just allowing access to read/write from another object
(Allowing access is done by providing a function). 

The problems that you foresee with distribution should be the same ones
that will occur with parallel threads accessing the same objects on a
single system.  These problems are locking, synchronization, and
propagation of changes, race conditions, resource conflicts, etc., which I
believe are the primary responsibility of an OS.  An OS, in its most
general sense, manages resources, and that is all.  So what I'm saying is
that once the system works standalone, it should be easy (almost fully
automatic) to extend to distributed systems, because a single system is
"distributed" already. So let me translate your question into the equivalent
in local terms:

Would objects A and B, who are both sharing object C, both have a full
copy of object C?  Would A and B each get half of C?  This last option 
isn't practical unless you decide beforehand what A and B's roles are going 
to be.  A and B might each get a copy of some common part of C plus some other
part of C that is not shared.  In any case, if A changes its part of C then
when do these changes propagate to any other objects that may be looking at C?
What if A and B simultaneously try to do conflicting things to C?

I can't answer these questions without more specific detail, since there
are so many different possibilities.

> But can't you have several objects of the same type? I
> can see that an interesting system can be built where
> each object is unique, but from the paragraph below that
> doesn't seem to be the case. If so, several objects of
> the same type may need separate identities.
> 
> How do objects refer to one another? If you can change the
> specification (object) for some object A, what happens to
> all other objects that referred to A in some way?

There's two ways to have multiple objects of the same type.  (You can
probably think of more)

1. B's specification says one thing: "the spec of A".  In this case,
whenever A changes, B will change simultaneously (since a specification is
an active context, set to evaluate immediately on any changes).  The
system could use the knowledge that A and B are identical to save some
memory in the implementations of the two objects. 

2. B's specification was created by copying everything from the
specification of A.  The two specs can be changed independently, but they
started out the same.  The system can make use of the knowledge that they
are identical (as long as they remain unchanged since the duplication) to
treat this case exactly the same as case (1).  It would just have to be
watching for a change in either specification to split the
implementations, instead of just waiting for a change in A, as in the
first case (since in the first case, if B changes, it doesn't affect A,
assuming A's specification does not refer to B in any way).

On another topic, if the objects refer to each other in their
specifications, we have a recursive definition.  The system should be able
to detect this and prevent infinite loops by disallowing full evaluation--
only evaluating to a certain number of steps.  Since most of mathematics
is inductively defined (numbers are inductively defined from an increment
operation), this restriction will be a pretty common practice.

[you meant:]
> > > You mean like  (car (quote (cdr car cond x))) or (car '(cdr car cond
> > > x))?

What exactly does this change in the order of evaluation?  Let me
guess...if (cdr car cond x) evalutes to '(a b c d), the above expression
will evaluate to (car '(a b c d)).  Right?  It won't evaluate to 'cdr,
will it?

> > OK, I admit it.  There is a global string.  It's called the IMAGE FILE.
> > Like Squeak, initial implementations of Tunes will store all their state
> > in a file on the disk.  I don't think this has anything to do with
> > reflection, though; the image file is a way to implement persistence.
> 
> Exactly - it is persistance. But if the system allows you
> to examine this thing in a user friendly way and reflects
> any changes you make to this representation back to the
> state/string/image file *then* you have reflection (obviously!).
> When was the last time to got to muck around in a .EXE file?

I think reflection requires a little more: The routines to
manipulate the system need to be included in the system,
so they can manipulate themself.

> > > If I want to add a little something to Tunes, where in
> > > this global expression do I put it? This is a question
> > > that doesn't make much sense in Smalltalk, Self or even
> > > C, but is important in Beta, Scheme or Oberon. The
> > > difference: lexical scoping (or not).
> > 
> > Where do you put it?  Inside expressions that give you the features you
> > want.  Putting something somewhere is the same as specifying it, since the
> > system is the specification, the specification is a tree, and objects are
> > "in" the branches of the tree that specify them... I don't think you can
> > get lexical scoping as precise as Tunes, anywhere-- there is complete
> > orgthogonality for EVERY feature.  For EACH feature of an object, the
> > object is identified in a distinct location in the system tree.  Take away
> > the feature means taking the object out of that location.  "Location" =
> > "Set of objects with a property".
> 
> I can live with that (though "tree" popped up again!) since
> in Cecil, multimethods don't live in any objects or live in
> several at once, depending on how you look at it. I guess I
> was back to identities again, but this time on the namespace
> front. If I create a simple tic-tac-toe game in Tunes, how
> do you find it to play it?

The netwide unified module workspace that comes installed
on every tunes system, of course.  When you decide to start 
making a tic-tac-toe game, look under games to see if anyone is already
making one, and if not, make a new project, and start putting objects
together.  If it is a short-term project, your system doesn't need
to distribute it until you're done; if it is a long-term project,
you can distribute the development tree incomplete, allowing others to
contribute.  I use the term 'distribute' here with both senses:
1. give out copies, 2. shared database, because sense (1) is accomplished
using sense (2).

> > Can you explain what you mean by a single coherent state?
> > Then we can talk about comparing the network models of Merlin and Tunes :)
> 
> There are many computers in the world. If Tunes runs on
> more than one of them, there are several options. Each
> one can be a totally separate entity with very limited
> (or no) communication between them. This is how Squeak,
> Self 4.0, Lisp Machines, Windows and so on work.
> 
> An alternative is to imagine a global state that is the
> sum of pieces stored on each machine. Examples would be
> DNS and the WWW. In theory, these would be totally disjoint
> partitions (as I defined above) but you need caching to
> make it work in practice. This means that this single, global
> state is not coherent.
>
> A problem with these systems is that they tie identity
> to location, and so are a little rigid. Another global
> system that has a different model is the usenet (NNTP).
> Each object (message) gets a unique ID when it is created
> and it doesn't matter where it ends up being moved. I
> would say this is the closest to what I am trying to do
> in Merlin.
> 
> Other options are no doubt possible, but I can't come
> up with any examples. TAOS (now Elate)? Helios? Why do
> I keep thinking of OSes for the Transputer ;-) ?

Just think of the internet as one giant hard drive.  When you
install tunes, you get a window onto it.  

When you make a web page, which search engine do you submit it to?
Which subject index do you add it to?  You find the most popular
one.  Why are there competing searches/indices?  I think it is
because no single machine is powerful enough or has time enough
to index everything.  But if every machine on the net indexed
itself, or if neighborhood hubs indexed a few machines near them,
the load of time/memory would be balanced.  You need to decouple 
the resource from the machine.

TUNES is a response not only to the lousy state of computer OSes and
languages, but also the lousy state of internet search engines and
distribution methods.

Think of fractals; self-similar at every scale.  TUNES will allow
fractal *algorithms*.  In a neural network, each node performs a
similar function on a different set of data depending on its place in the 
network.  In a fractal network, each group of nodes performs a similar
function on a different amount of data depending on its order of
magnitude in the system.  Combine with self-replication, and the fact that
a process no longer has to be attached to an individual CPU, but can
divide among many CPUs as well as migrate to different CPUs, and I think
your idea of "single coherent state" can probably be emulated by the
result.

David Manifold <dem@tunes.org>