TUNES: Underneath, Nearly Everything is Source

[Ashley Winters]

On Mon, 22 Jun 1998, David Manifold wrote:

> The following is quite long and not very well organized, but it should
> give you a better idea of how Tunes works, inside.  I welcome your
> comments.

Quite good, yes.

> On Mon, 22 Jun 1998, Ashley Winters wrote:
> 
> > On Sun, 21 Jun 1998, David Manifold wrote:
> > > The entire system can be treated as one big expression.
> > > In fact, this big expression could be written as a string.
> > >
> > > Anything at all that can be done in the system comes down to an edit on
> > > the expression.  (Including programming, word processing, internet, etc)
> > 
> > If you replace 'expression' with 'mass-storage device', which could be 
> > implied by 'this <mass-storage device> could be written as a string',
> > it's not hard to miss the profundity of your description...
> 
> The term 'mass-storage device' loses the meaning of a high-level entity,
> though.  When I think of a mass-storage device, I just think of a large
> number of bits.  An expression can be understood by humans, and also acted
> on by computers.  The important thing is to recognize that abstractions in
> Tunes are multidimensional.  Everything in current systems is somehow
> thought of as linear (streams, arrays, lists) because of habits from
> low-level programming.

And also because that is how humans interact with computers. Humans may
not think in linear terms, but that is how they communicate. With strings
of words or keys on a typewriter. Forming multidimensional thoughts in a
computer requires forethought and planning, whereas linear interaction
requires training and practice.

> People don't naturally think in lines.  Tunes is
> supposed to be easier to use because it mimics the way people really
> think. 

Easier to use? Probably not in the down-to-earth sense. Perhaps it will
be easier to express your desires, therefore making it easier to get
something done. But will it *really* be easier to use than something like 
MacOS?

One of the goals of Tunes, as I understand it, is to promote computing
Freedom, part of which means freeing the world from the computing caste
system that exists today; Users and Programmers. Everyone is a
Programmer in Tunes, and the degrees of experience are all that 
distinguish a user. The product of experience is distributed for the
benefit of all.

Apart from the "You can setup your system however you want" argument, a
question is raised as to how a power-user will setup their system to meet
their needs. Tunes will probably be distributed in a form about as usable
as today's best designed programs. However, that does not provide any
advantage over the current standard.

Tunes will be harder to use in the sense that in order to get the best out
of it, the user will have to do more. With shrink-wrapped Micro$oftware,
the program is as good when you install it as it will ever get. It's
pointless for anyone to discover or understand what makes it work, or how
to make it better, because they can't. That saves time in the short-term.

In the long-term, Tunes will end up being more useful, and easier to use
once it's understood and setup. The "You can set it up however you want"
invites users not to embark up the Tunes learning-curve, instead relying
on a distribution setup in a generic way which they will never modify.

> That means the computer (and therefore, the system programmer) has
> to go out of the way to do a little more work for the user.   
> 
> > > 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.
> > 
> > That last sentence is mind-boggling, let alone the paragraph itself.
> > I tried to think of something better, but just ended up glad that you were
> > able to express your meaning at all. I'll think about it some more.
> 
> Here, I was trying to talk about the system "coming with its complete
> specification."  The system consists of constraints, each of which specify
> some property of some object.  Any property of any object has a
> corresponding constraint.  Anything that is not described by a constraint,
> is not in the system.  Therefore every part of the system has constraints,
> and it is the systems job to implement these constraints.  Implementing
> constraints is really the ONLY thing that is being done in Tunes, at the
> topmost level.  Everything else is just a different kind of constraint.
> More features can be added by providing the system with info on how to
> implement other kinds of constraints.

Constraints are important. For bonus points, define a constraint as it
relates to programming.

> Tying back to the expression idea, the giant expression is made up of many
> many tiny constraints and the relationships between them.  The important
> fact is that every constraint and every relationship is explicitly
> described, so you can manipulate it.  

All the more important to keep the specification as high-level as
possible. Given so much power, the system must be able to determine what
constitutes a healthy change. The Black Box of computing is not only
convenient, profitable, and buggy, it's safe from tampering as well.

> For efficiency, of course, less-frequently-changed constraints will need
> to be optimized.  But, everyone uses their system differently.  All
> data/code being equal, the system can dynamically optimize differently for
> each person.  One of the complaints we have about current systems is the
> staticity of the OS level -- not just that we can't get at the source, but
> that it is optimized for a *specific* use, that may not be the use every
> user needs.

One of the problems of customizing a system to a user is
inter-operability. When you learn Window$ or MS Word on one computer, you
can use that experience on any other computer with that software. When you
start making vast parts of a program easily configurable, you must relearn
a piece of software on each machine. Until the technology comes along to
store and distribute personal preferences to each machine a person uses,
such configurability has a severe inter-operability drawback. Not every
computer can be reached from every other computer all the time.

> > > Since the system is constantly evaluating, an edit on the expression will
> > > cause changes to take place immediately.
> > 
> > What changes? What are the changes doing?
> > 
> > Let see... if programming is equivelant to editing the expression, then a
> > change would be something like pressing Enter on a command-line interface?
> > The immediate change taking place would be the execution of the command?
> 
> Yes.  Also, moving the mouse may update one byte that contains the current
> position of the mouse.  The byte is part of the system expression, so when
> it changes the entire system re-evaluates. 

I assume this means that every object that uses the byte to calculate its
value or generate its side-effect is reevaluted. And that the mechanism to
do this is implementation-dependant.

> If nothing else depends on the
> value (if no program cares where the mouse is), then all that gets changed
> is the byte itself.  With the idea of constantly evaluating, I am trying
> to say that Fare's "active annotations" are just the normal way of doing
> everything.  A "passive annotation" does not exist, it is simply an active
> annotation that isn't changing.  For example, constant integers.  A
> constant integer is just a regular "integer value" that has been specified
> to have no modifier method.  In order to change it, you'd have to first
> change its specification (or, the objects one level above it, the ones
> that describe it).  Remember, specification is done by adding constraints. 
> The big expression IS the specification. 
> 
> The idea is that every part of the system can be treated equivalently (as
> part of a big expression), but the parts of the expression are different
> enough that you can do anything you want within them.  Looking around your
> system is like browsing through an expression viewer.  Using the system
> may take on many forms, depending on what interface you use.  However,
> each of these interfaces (command line, GUI, or whatever) is translated
> into an edit on the system expression.  So, at the topmost level, Tunes is
> a high-level expression editor.
> 
> > > 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.
> > 
> > Would these be programs that are written, but not executed yet?
> 
> Yes, also programs that are not done being written (because we would not
> want to try to execute them); functions that cannot be fully evaluated
> because they would expand into infinite recursion; and other objects that
> wouldn't make sense to execute, such as a database record.

execute, not evaluate? Can't you evaluate a database record? The data
doesn't have meaning until it is evaluated by an object, right?

[ skip ]

> > > 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.)
> > 
> > Uhh... I guess that makes sense, in a circularly logical kinda way.
> 
> What I said looks kind of ridiculous to me now.  In theory, you CAN think
> of every specification of every object as consisting of a list of ALL the
> possible properties available in the system, along with a value saying
> "has it" or "doesn't have it".  However, in practice it wouldn't be very
> useful.  It means the exact same thing to have a list of properties for
> every object that contains only those properties that the object HAS.  So,
> you don't need to say "this object doesn't execute" for every object that
> doesn't execute.  It will be implied that it doesn't execute by the fact
> that it doesn't have a constraint that says it executes.  However, it must
> be remembered that the two scenarios I have compared here are EQUIVALENT. 

Like much of the rest of Tunes, this is all a matter of appearances. You
must be able to retrieve such boolean properties at a high level, but they
can be stored at a low level in whatever way gives accurate results.

> Tunes may use either representation, because it can be proven that it
> doesn't matter which one.  So, in practice, the system could be actually
> designed to have a list of all the possible attributes for each object. 
> Then the system could simplify the specification, ignoring data it knows
> it won't need. Because of the proof system, you can design your programs
> in whatever way makes sense to you. If it is equivalent, it won't matter
> to Tunes. 

Tunes from the User's perspective...

> The idea is to make efficiency not depend on design, either. 
> Programmers should design objects with their purpose in mind.  The
> implementation of optimizations should be independent from the semantics
> of the program.  This is just saying that you should write code without
> worrying about how fast it is going to be.  If people do that, the code
> will make more sense!  Then they can go back later and write essentially a
> DIFFERENT program, that describes how best to optimize or implement their
> earlier code. 

That's important. The semantics are diluted by optimizations, and
optimizations are diluted by semantics. They both are information, but
only the semantics have meaning. The optimizations are connotations
related to the meaning. You lose less information by separating them than
by combining them. Tunes is based on the hope that with enough
information, the system can optimize itself.

> > > 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.
> > > 
> > > Won't someone ask how reflection works??
> > 
> > Probably not, unless I ask. How does reflection work?
> 

[ An agreeable, convincing and helpful argument for reflection snipped ]

[ Everything else also snipped ]

What is stopping me from releasing my left thumb as Tunes 1.0? How would
anyone know that my left thumb isn't Tunes?

What is a Tunes system?
What would it do?
How do you know if you've written it?
What is the shortest path between here and Tunes?
What would a bootstrapped Tunes system consist of?

The high-level descriptions of what Tunes will do are good, but I want to
know what Tunes is. None of the high-level Tunes discussion lends itself
to contemplating an actual implementation. What Tunes does (will do) has
been well-discussed, but what it *is* (will be) still eludes me.

Ashley Winters

> David Manifold <dem@tunes.org>