coherent states

[David Manifold]

On Mon, 22 Jun 1998, Jecel Assumpcao Jr wrote:

> David Manifold wrote:
> > The entire system can be treated as one big expression.
> > In fact, this big expression could be written as a string.
> 
> This supposes a single coherent state, which I guess is
> important in a system that is based on proofs.

The state is decentralized.  The way I do this is: each expression is a
specification for the expressions within it.  The meaning of "state"
depends on which expression you are in.  So, no, the state is not
coherent, if coherent means there is any identifiable similarity between
any arbitrary two parts of the system (such would be violation of
genericity).  However, the state IS computable, since the meaning of each
expression is specified by other expressions, and ultimately all
specifications come together.  The place they come together is likely to
be a formal implementation of logic and mathematics.

Someone will wonder how one expression can define all the characteristics
of something in it.  It can't.  That's why every part of an object's
specification is defined in a *different* expression.  Each constraint in
a specification needs to be orthogonal, so it's in a different object
(This is what is meant by "many parents").

> > Anything at all that can be done in the system comes down to an edit on
> > the expression.  (Including programming, word processing, internet, etc)
> 
> The state can be changed, which is pretty normal in the
> computer world. My current thinking sort of takes me in
> a different direction (multiple versions of the state, each
> immutable).

I have in mind a kind of history, where you can set some objects to have
their changes kept track of.  All this would require is a modification to
the evaluator to keep a log of its actions instead of destroying the
expression tree after evaluation is complete.  Then since the log is in
the same representation as the expression, it is just another "version" of
the state.  With the proof system, history could be compressed:
any action proven to be recomputable can be left out of the log.

> > The expression is always being evaluated.   The reason it is always
> > evaluating is that each object has at least one element in its
> > specification, that of "existing".  So the existence of the system is
> > constantly evaluating, as long as the system exists.
> 
> Is it possible for an implementation to optimize this by
> having the system note that an expression, if evalutated,
> will give the same result as in the previous evaluation
> (if it hasn't been edited, it is side-effect free and
> all the inputs as the same) and so reuse the old result
> instead? BTW, you introduce "objects" here. How does editiing
> the global string affect object identity?

Reusing results was discussed in Fare's message of Tue, 16 Sep 1997,
subject: Re: Attributes.  He writes about memoization of functions treated
as attributes.  My position on this is that there can be a process in the
system, observing what happens, and if something happens a certain number
of times, it will be optimized.  Function return values can be
automatically memoized (put in a lookup table) and their arguments hashed
(indexed).  The lookup table would be automatically destroyed, adjusted,
or recomputed if the generating function was changed.  There are two
different elements here (that can be used independently): The proof system
that allows you to substitute one expression for another (by showing their
equivalence), and the optimizer which rewrites underspecified objects
according to resources consumed (observed) and variants specified
(user-given hints for optimization).  Underspecified means the low-level
representation is left out.  Overspecification is when you explicitly
force a certain implementation;  doing so hurts the optimizer. 

When I said the system could be written as a string, I meant that
literally.  It COULD BE, but it might not be very useful.  I'll assume you
meant 'edit the global expression' since that is probably what you meant.

The identity of an object is defined as the combination of its
specifications, also identical to its type, since what an object is
specified as determines what operations can be done on it.  When you
change an object, it doesn't affect its type, because you may only change
it within the constraints of its type (you can't set an integer to be 2.4,
for example).  However, if the object you are changing is a specification
for some other object, the OTHER object's identity may change, but not the
specification object itself-- because a specification object is written in
a language, which is also limited within the constraints placed on it by
higher-order objects.  So, basically, the security of the system protects
the identity of objects under editing.

> > Since the system is constantly evaluating, an edit on the expression will
> > cause changes to take place immediately. 
> 
> Having created an "instant assembler", I know this is harder
> to do than to say. An edit is defined as what? When I type
> in a letter, it changed the expression yet evaluating it
> now will result in a syntax or runtime error. I have to wait
> until I type some more, delete some text, type even more to
> reach another consistent state. The usual solution is to
> clone the string, edit that and then press an "apply" (or
> "cancel") button to update the string atomically to be the
> same as the final edited string. The problem is that breaks
> down your model - during some time there are actually two
> strings and the one that you are seeing on the screen is
> the "fake" one (the Self people would say that it is not
> "counterfactual").

Sure.  I wasn't thinking about evaluating incomplete expressions.  I just
assume that the string doesn't get evaluated AS AN EXPRESSION until you
hit enter.  It will, however, be evaluated as a string at least until the
point when you hit enter.  When and how an object is evaluated is defined
by the specifications for the context you are working in.  So
"immediately" should be "when you say so".  Thanks for pointing that out.

> > Any changes that are not to take
> > place immediately (or subexpressions that are not to be evaluated yet)
> > will simply be specified to not evaluate yet.  The constraint to not
> > evaluate will still be constantly evaluated.  (Until it is changed, at
> > which time the expression it is referring to gets evaluated.)
> 
> You mean like  (car (quote (cdr car cond x))) --> (car '(cdr car cond
> x))?

I'm not sure what you're trying to say here.  Is the subject of the
sentence the translation from 'quote' to (')?  If so, what is being
delayed?  I thought 'quote' and (') were interchangeable, and both delayed
evaluation.  (At least, they have the effect of delaying evaluation, by
placing another layer around the expression.)

> Or like  x>3 ifTrue: [ x := 10 ] ifFalse: [ x := 2 ] ?
> 
> You do need something like that somewhere in the system.

Like what?  Conditionals?  Sorry, I don't understand.

> > I would appreciate comments on this.. I can't make any progress on the
> > system unless there is a discussion of my posts and the ideas get refined
> > so that they are understandable.  Thank you very much.
> 
> It isn't always easy to find the time to reply.

Well, it's ok if replies come after a while.  But when no replies come, I
worry.  It would be nice if someone would just say I am posting complete
gibberish (I think someone did, thank you).

> > Won't someone ask how reflection works?? 
> 
> Reflection is the relation between the "global string" and the
> actual state of the system, right? If so, then no questions.

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.

> > Does anybody have any questions
> > about the practicality of the above model? 
> 
> It is very practical as long as you exclude distributed
> systems. See below.
> 
> > Any specific questions about
> > "how do I do X in Tunes"? 
> 
> 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".  

> > What we need is some vehement anti-tunesers to
> > start flaming the list.  Maybe we should go trolling on the usenet...?
> 
> I can do that ;-) Actually, I couldn't be called an "anti-tuneser"
> since I very much wish to see it succeed. But after talking
> to Fare' about merging it with my own Merlin project I decided
> against it since we had some significant differences. The search
> for an ideal (the "Not Expedient" part) and the emphasis on proofs
> were things I thought were not very good for an "open system". I
> wanted Merlin to span large and dynamic networks of machines and
> the idea of a single coherent state simply doesn't apply anymore.
> I prefer things that work in practice even if they are wrong in
> theory. So I concluded that the best thing was to keep the projects
> separate (but keep in touch) since each would serve a different
> need.

Can you explain what you mean by a single coherent state?
Then we can talk about comparing the network models of Merlin and Tunes :)

> When I hear "Tunes can do anything", I am reminded of a teacher
> at the University of Sao Paulo. He was very forceful and
> convincing. Even though his whole background was in "traction"
> (as in electric trains and stuff like that) he insisted that
> he had beaten the Japanese to the "fifth generation computer"
> (if you don't remember what *that* was about then you should
> study up on it before continuing Tunes!). He thought he had
> eliminated the "Von Neuman bottleneck" between processor and
> memory by eliminating the processor and computing directly with
> the memory. He would take an EPROM, use some address lines as
> inputs, some data lines as outputs and feedback the rest of
> the data lines into the remaining addresses (a classical
> implementation of a state machine, but he thought he had
> invented it). It is true that such a machine can compute in
> *theory* anything that a classical computer can. In *practice*,
> anything beyond the trivial examples he did demonstrate would
> have required many gigabytes for EPROM to work. IBM financed
> a book of his describing this idea and it sold pretty well!!
> Please don't let Tunes fall into this trap. Even the worst
> Win3.1 is better than an OS that can only exist in emails...

I hope to avoid traps because I will listen to criticism and try my best
to meet it.  I am aware that Tunes makes extraordinary claims, but no one
has convinced me it can't be done.  The only evidence so far is that it
hasn't been done yet.  I highly suspect that the main reason it hasn't is
that no one has been patient enough.

David Manifold <dem@tunes.org>