Tunes

[Francois-Rene Rideau]

> Hello. I recently stumbled across the Tunes Project and was wondering if 
> you were still actively involved in it?
   I admit I've been silent lately, but I'm still very involved in the
project. Real-life administrative problems are slowing me currently.


> I've gone over many of the
> documents and messages in the list archive and would like to see them 
> realized.
   How do *I* !

> Philosophically, I am in almost complete agreement with your 
> ideas on the OS although I can't see, yet, how they could be achieved 
> technically.
   I admit I don't know how exactly everything will fit together. However,
I see no great theoretical difficulty of any sort in any immediate part of
the project: building a language with all the HLL requirements, over a LLL
with all the features we promise is nothing more than has been separately
done in many distinct existing software. Tunes would just be a unification
of all those techniques. What the project lacks currently is a lot of hard
work and try (including and particularly from my behalf).
   Actually, there's a place where lots of difficulties lie, but we can only
reach it when enough of the base system is settled: how the human will
interface and manage what I called migration in a way not too much inefficient
from both the human and machine view, yet with as clean semantics as can be.
   For instance, if someone publishes an object,
other people may want to "watch" it, so they can update objects based on it.
Now "watching" spends resources; whose resources will that be ? How can these
be efficiently, yet safely and securely distributed ?
   Another example: we avoid overhead and produce efficient code by
producing specialized versions of objects. Now, we still want to be able to
change values objects were specialized for (e.g. a real-time animation/game
was specialized for fast drawing on the current screen or window settings, but
we'd like those settings to be modifiable so that the user can tweak his
configuration or even change machines and continue the animation/game/whatever
from where he left exactly). So how can we do it and still respect our
efficiency and timing constraints ?
   And when we export an object, what set of annotations should we export
together ? How to manage these annotations in a way such that it won't become
completely chaotic even though many different users and sub-users
customize it with complex dependencies inside those customizations (not to
talk about several versions of the "same" objects in different computer or
human languages).
   More generally, when we want to extract an object from its "specialized"
context, how can we adequately distinguish what is the object, what is the
specialized context ? What implementation techniques are involved so that
this process (including tracking dependencies on all objects abstracted
from the context) is not too costly ?
   The exact policies for such things is very important as for the system's
response and resource hit, but can only be determined by fiddling on real
data.

> I'd be willing to participate in the project in any way I
> can if you're still interested.
   There's a lot to do about 1) bootstrapping the HLL, 2) giving it a clean
syntax, 3) making it clear how it differs from existing object systems
(particularly, say, those from Lisp CLOS' MOP, or Icon, Sather, Python, Perl,
and Caml/sl object modules).
   The HLL (together with the whole development system) should allow a clear
distinction yet co-development of object specifications and implementations.
I should be able to give a pure functional description of a counter i, and use
a barrel-shift register as an optimized implementation for it when (1<<i) is
the depending value used. The counter could stay virtual and not be actually
implemented if it were not exported to human visibility (e.g. for debugging)
and optimized computations would better skip its calculation.

> I'm looking forward to hearing from you.

> Merry Christmas.
   Merry Christmas to you, and all the Tunes project.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --