A "few" questions about Tunes

[David E. Manifold]

On Mon, 1 Dec 1997, Ales Hvezda wrote:

> 	I've been thinking about doing something similar to O'TOP, but I'm 
> curious as to what and how this manifest itself.   How does the user or
> programmer interact with Tunes?  Most of my OS experience comes from using 
> UNIX for a while now, and when I think of UNIX I think of it's API, user
> model, IPC, filesystem etc...  These characteristics define UNIX.  What I'm
> struggling to comprehend is how this is all laid out in Tunes (what/how the
> analogous concepts are implemented in Tunes).  I also look at things
> the Forth way with "objects/words" (fine grain objects) as the building 
> blocks for everything.

Everything is an object. That means you can interact with the computer by
manipulating objects.  There is no difference between the user and the
programmer in this sense; anyone can manipulate objects directly.  The way
you access objects depends on the user interface you desire.  Tunes will
include familiar methods, the text-based "command line", and the
graphical-based "gui", but both will be self-extensible.  The user
interface won't depend on the program.  Programs simply provide
capabilities; the functionality is equivalent and you can do the same
things in CLI or GUI.    This means there is no such thing as a
"graphical" program or a "text-based" program.

In addition, the user doesn't have to interact with objects, but can
interact with the system in any way implemented by the objects.

Programs don't have to leave out details of user interface, but details
such as window/button arrangement or menu organization are independent
from the ability to use features in the program.  This means you can strip
out these details and use your locally configured defaults if you wish.

The focus of Tunes user/programmer interface is that the user is in
control.  Every feature, ability, or setting is easily changeable by the
standard user.  Because the system is fine-grained and reflective, these
changes don't require rebooting (even ones relating to system-level
activities).

When programming in Tunes, the most difficult part is designing your
specification.  You enter your specification, consisting of how objects
relate to one another, what they do, and how it is done.  The system takes
care of the rest, as far as it can.  That means it automatically
translates your specifications as far as it can.  If your specifications
are in terms of other objects existing, then you don't have to write
anything else.  In practice this means your ideas are visible in front of
you as soon as you enter them.  In the programming sense, your programs
are dynamically compiled while you are programming them, and you can
manipulate them while they are running.  Graphically, this is a dynamic
flow chart.  Linguistically, it eliminates the edit-compile-debug cycle,
as Fare calls it.  Tunes is neither interpreted nor compiled, but a
mixture of both.  I call it dynamically compiled.  This isn't slow because
it is fine grained and doesn't take much resources to compile a single
object at a time. (The compiler itself is small, too, because all it
consists of is the information necessary to translate an object to
low-level representation.  This is not a static path, like traditional
compilers, but the path depends on the individual object and only goes
through required steps.  Unnecessary transformations are automatically
simplified as soon as they are recognized.) 

The U in Tunes is for Useful.  Tunes is designed to get things done.  As a
user of Tunes, you can expect your computer to be helpful and do what you
want it.  You shouldn't be locked into doing something the way someone
else does.  Your computer should adapt to you, so you don't have to waste
time adapting to it.  Flexibility and ease of use are not opposite.

The OS kernel, library functions, device drivers, programs, and commands
are all treated equivalently in the system.  If you're telling the system
something to remember (programming it), there is no arbitrary distinction
of what is "the system" and what is "in the system."

As for API, user model, IPC, filesystem, etc, Tunes will not be defined by
a static API, user model, or filesystem, but by the ability to dynamically
define new APIs, user models, and interfaces (or to import and use old
ones).  There is no filesystem.  In Tunes, there is no loading/saving
because objects exist in the system and are automatically migrated to the
appropriate medium (based on constraints defined by the user).  Objects
are saved to disk at regular intervals (in case of a crash) and loaded
when they are individually needed.  The user does not see a "file" or a
"program loading", the user just sees objects.  At different times the
user sees different objects :)  The ones that aren't being looked at will
probably be put on disk and out of memory. 

The "kernel" is the set of objects required for basic system operation. 
This can vary depending on what requirements you have in your system.  It
can also be edited in real time in Tunes.  The Kernel in Tunes is actually
the language, or the definition of what an object is and how objects
interact.  This is what we have to implement first.  We really just call
it the "base system".  It is only different from other parts of the system
in that they depend on it.

As for API, there is none.  If you download a program (we call it a
module, which is just a way of organizing objects), you don't install it,
and later run it. You add it to the system, and perhaps later you will use
the objects in it.  If it is a tool, it instantly becomes available
system-wide.  The API to use the tool is just the semantics of it (the
tool's self-description of how the outside world is to access it).  We try
to keep the system as flat as possible.  By this I mean not having layers
of dependencies; not having dependency is called orthogonal, and Fare said
we should have as much orthogonality as possible. 

IPC?  Well, there are no processes.  Objects interact in parallel.  Any
object can interact with any other one, as long as a rule has been defined
for what the result will be ("as long as there exist meta-objects that
agree").  As for proofs (programs) in parallel, this can be determined by
future-values and dependency tracking.  Scaling problems for multiple
processors requires nonlinear problem solving.  Nonlinear problems, as far
as I can tell, can be easily modeled by objects.  This is not an issue in
Tunes, because it isn't designed around a single processor, like all
existing systems.  In fact I hope with Fare that Tunes will allow cheap,
parallel hardware to be usable by the average user.

David E. Manifold
tril@bespin.ml.org