Clipboards + Meaning

[David E. Manifold]

Toogam, I have cc:ed this to the Tunes list because it will interest the
subscribers.  Please feel free to cc: your reply to the tunes list also,
if your reply is suitable for the Tunes list.

[Warning, the following is not paragraphed heavily. -tril]

The Importance and Effects of High-Level Meaning in Tunes

You used the clipboard to demonstrate the example of a metagraphic.  The
clipboard stores the meaning of the graphic, separate from any particular
form (or format).  This feature of the clipboard is what Tunes is trying
to make system-wide.  The storage of data by its meaning makes the data
useful everywhere that understands the meaning, instead of anywhere that
understands the form (format).  You probably would consider it ridiculous
to argue that all the programs should support all the formats.  If the
program can support the clipboard, it doesn't have to support all the
formats.  Now, more formats available will make the program more able to
interface with external programs (ones that can not communicate through
the clipboard, such as remote systems), but within one system the
clipboard eliminates a lot of work for the program, work for the
programmer, and space in the exe (by not having to have all the formats). 
When you're in Tunes you won't need a clipboard because everything will be
already stored by its meaning.  Also, external systems (other systems
running Tunes) will be communicated with by meaning, so there will be no
need for specific formats.  To understand how Tunes stores objects by
meaning, you can reason by common sense how the clipboard stores meaning. 
It finds the common elements of all graphics.  The graphic size (rows and
columns), the fact that it is stored in 2D (rows x columns) in a grid, the
idea of a color palette (just a set of available colors), and the idea of
color depth (the range of colors specified in an individual pixel within
this graphic).  Tunes will operate like this for all objects, not just
graphics.  Also importantly, not just data, but functions will be stored
by meaning as well.  Instead of storing a program as either "ASCII text,
readable by the C compiler," or "Binary code, readable by the Processor,"
a program is stored by its meaning.  A program is stored by the meaning of
its parts.  If you used a procedural language, like C or Pascal, the
program is stored in the system (memory or disk, equivalently) as a set of
functions (one of them being the "main" function).  If you used a simpler
language like batch, the program's representation consists of a list of
commands.  But isn't a function just a list of commands?  If the meanings
are equivalent, they will be treated equivalently in Tunes-- so in actual
use, functions and batch files are the same as each other.  In fact, both
functions and batch files are the same as a 4DOS command consisting of
multiple commands separated by the CommandSep character.  What are the
effects of manipulating programs at the semantic level (or level of
meaning)?  Less errors, because you don't have to translate the meaning
into a specific form (such as the C language, which has strict rules on
syntax)...Less time, because you are practically writing in pseudo-code
and there are less levels of translation required for the human...Less
space, because the computer does not have to store the source code or the
machine code...and finally, because you won't have to re-program things
that other people have already programmed (and you downloaded onto your
computer, in high-level, or semantic meaning form)--You'll just be able to
interface directly, because meaning is equivalent.  This extreme ability
of reuse saves TIME (spent redesigning the wheel every program you make),
SPACE (including duplicate code in every program), and if it does this it
makes YOU happier as a programmer, because you are more productive and
less stressed, and it also makes you happier as a user, because it is
easier to do what you want in a system that understands meaning--very
literally it will do what you mean, not what you say--and this
demonstrates the Usefulness of Tunes.

I know you worry about the response time of such a system--after all, it
has to translate high-level meaning into machine code sometime, to execute
it, whether it compiles or interprets or dynamically compiles as I have
said Tunes will.  But consider-- you're thinking of compiling.  One of the
steps in compiling is not even present in Tunes, and that is the step of
translating ASCII text into meaning.  Meaning is already there.  You said
it would be complicated to translate meaning into machine form.  But
people already know how to do this; that's the design of compilers.

The other issue that often comes up is ease of use.  The system is so easy
to use for programmers, but what about the average user?  In Tunes, this
concern is important to us, but it has been addressed thus:  Using Tunes
is the same as programming Tunes.  You may say that the time taken
compiling doesn't matter, because the user uses the compiled version
anyway.  Not so in Tunes; the user accesses the same meanings as the
programmer did.  That is, high level representation.  Remember, objects of
equivalent meaning are treated equivalently.  Well, what about calling a
function from inside a program, and typing a command on the command line?
They mean the same thing to me.  What is the meaning of what an average
user does on his or her computer every day?  Manipulating documents. 
Replying to e-mail.  Communicating in IRC.  Organizing files.  I propose
that the meanings of these activities are no different from things a
normal program does.  Manipulating documents for a human (Word processing) 
is the same as manipulating documents for a program (configuration files
or other program data).  Replying to e-mail (interpreting a message and
sending one out again) is the same as programs communicating with one
another.  Using IRC is exactly like multiple Warcraft II programs talking
about the game world over the network.  When a user organizes files he or
she is doing the same thing a program could do when sorting directories.
Since the activities are performed by meaning, the compiled form only
needs to be seen by the processor.  That means there is no set "binary
executable" that the user has to go into or go out of.  If the user
doesn't have to go into or out of it, the operating system does not have
to load it up or unload it.  This saves (or practically eliminates) 
loading time, as well as task switching overhead between processes.  In
summary, the system gets work done for the user because information
(including activity) is stored by meaning.  Not only is the computer
easier to use, it is faster.  This allows the user to get work done.

Back to the programmer's perspective, the focus on meaning in Tunes makes
development easier, faster, and more interchangeable.  Not only is the
need for new programs decreased, the availability of new programs
increases-- and these are not duplicate programs, but ones that do
entirely different things that no one would have expected to be seen on a
computer. 

Further complaints resolved: 

* If you are a business you don't have to worry about distributing source
code. You still can distribute the cached binary representation of your
program, or completely lock out the user from accessing the internal
meaning.  (Whether most businesses will continue to desire this is a
separate question.) 
* Storing data and programs by meaning does not mean syntax is not
supported in Tunes.  Tunes will be able to understand any syntax that
someone has told Tunes the design for.  Translating between syntaxes, or
using custom syntaxes, will be trivial. 
* Users don't have to actually manipulate objects; any system specifiable
in objects can be the interface the user sees.  If you find a system
unspecifiable with Tunes objects, we'd like to see it. 
* To transfer by meaning on a high level, you don't require that the other
end have Tunes.  Tunes can translate to a lower level, or to a different
understanding of the higher level. 
* Computers will never take over everything the programmer or human user
does; and Tunes won't restrict people from messing with the low-level
representation if they wish.  In fact, tools for programming and low-level
hacking will be readily available for the Tunes system.

Issues not covered today: Persistence, Reflection, Security, Object model.

If you wonder exactly HOW meaning is stored in Tunes, that is what we are
currently working on (this is the HLL specification I am asking Fare for).
Feel free to contribute ideas or feedback.

David E. Manifold
tril@bespin.ml.org