coherent states

[Jecel Assumpcao Jr]

> > [how can state be decentralized (distributed)?]
> 
> 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).

Here you are using sharing in the sense of resource protection.
I agree that a design can make this linked to distribution
(this is one of the really new things in Merlin) but it is
normally a separate issue.

> 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.

This is true in theory. But you must remember that when
quantative differences become great enough they become
qualitative differences. You can't replace instant
communication (shared memory) with a low bandwidth
alternative (modems) and expect the same design to keep
on working. It will, in a sense: I have used X Windows
over a 1200 bps connection. Each mouse click took over
a minute to produce results. I used this for two days.
But few other people in the world would put up with
something like that.

> 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.

Ok. What I am asking is: will the system choose one of
these possibilities? Will there be some toolkit to
support them all? Knowing Tunes, I am sure that the
answer is the latter. So I am interested in what building
blocks make up this toolkit. I think this must be detailed
before the first line of Tunes code can be written.

> 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.

In Self we would make B a clone of the A prototype.

> 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).

You can't do this in Self, but NewtonScript handles this
pretty well.

> 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.

Objects that refer to themselves in the their specifications are
very useful too. The same technique you described could handle
this case.

> [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?

The above expression will return the symbol 'cdr. If you eliminated
the quote then you would get 'a (though (cdr car cond x) isn't a
valid Lisp expression, so it couldn't really evaluate to '(a b c d)).

> 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.

Right, but as we were talking about self contained systems like
Smalltalk, LISP and Tunes this was implied.

> > [where do I put tic-tac-toe in Tunes?]
> 
> 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).

Great - the module system! A very good idea, though it isn't
always as simple as it sounds. The best I've seen so far was
in Oberon (I never did see the details on Dylan, which seemed
to be moving in this direction). The Java people didn't quite
get this right, but I think the new Jini thing might improve
things.

> > [various models of coherent state, including WWW and NNTP]
> 
> Just think of the internet as one giant hard drive.  When you
> install tunes, you get a window onto it.

Good, solid start. I am interested in the case where your window
into the "global string" is read/write and you make a modification.

> When you make a web page, which search engine do you submit it to?

I don't. They find me on their own.

> 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. 

True. I like to use Ask Jeeves (www.aj.com) since it consults
all the popular search engines at once and I get to compare
how their results differ.

> 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.

The is the idea behind the DNS. It works well, but had to
be extensively tweaked with cache and things to really get
the job done.

> 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.

The web simply wasn't designed to be used this way. It is
about hyperlinks, not indexes. If you want something different,
it is better to start with a new design.

> 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.

When I started working on Merlin, some 15 years ago, I had to
choose between three exciting programming styles: OO, Logic and
Functional Programming. I looked around me and saw great OO
systems that had actually been built and were being used, but no
real logic or functional systems (this hasn't changed a bit,
as far as I know). So I abandoned the more attractive alternatives
(you don't have to worry about emulating a single coherent state
if you can exclude the notion of time, for example) and went with
objects. Though Merlin doesn't exist right now, it did in the
past (three systems were build, but never sold) and I can say that
objects haven't let me down. I've learned that nothing really
scales very well - the large insects of horror movies could never
exist, for example (strutural strength scales with are (square
of length) while weight scales with mass (cube of length)). I'd
hate to have Tunes built around ideas that are wonderful in small
experiments but which can't be built up into an NT replacement.

-- Jecel