Having time&knowledge

[Francois-Rene Rideau]

On Fri, Dec 04, 1998 at 02:28:38PM -0600, Eric W. Biederman wrote:
> As far as I can tell Tunes is primarily about a fundamental
> configuration mechanism, so a user can take a system and by
> configuration make it something vastly different.  But with
> a simple model.
We'll try to make it "as simple as possible, but no simpler".
The more precise the configuration, the more complex the framework
needed to specify it.
Of course, most of the time, the configuration needs not be overly precise
(i.e. most people don't care about which register was used at which clock
cycle), and a pure and/or encapsulated programming style (see Haskell
or Mercury) can help keep the interfaces simple.

> About programs knowing each others guts so they can make sophicatated
> optimizations on each other.
Or rather, about programs declaring each own's guts, so a trusted
metaprogram can co-optimize them.

> About working transparently acros networks etc.
This is given immediately, once we can reify the state of a program
(which we equally need for persistence).

> The key to all of this being the core communications protocols,
> between programs so they can achieve all of theses things.
The core communication protocols are rather an easy problem.
It's just a matter of a standard marshalling protocol, or, better even,
a standard negociation protocol for marshalling purposes.

> What I would suggest at the current time would be to find a CORBA ORB
> you can stand, and start working out the details of what is needed for
> programs to talk to/about each other reflexively.
The problem is that CORBA only deals with the marshalling,
not with the important part, which is
* having a well-defined, high-level semantics
* being able to fully reify the execution state of a program
* having a generic framework for dealing with several "abstraction levels"
 about program execution (source/declared semantics vs
 register-wise execution, virtual vs actual memory/disk, etc)
* including in our framework a generic facility for cacheing&invalidation
 of "optimized" versions of the high-level code.
These come all at once.

> Once the priniciples are firmly understood integration can happen at
> lower, and lower levels of the system.
Yup.

> But what appears to be primarily needed is a standardized
> communication mechanism (which ultimately may be shifted on the fly),
> to allow tunes.
No, what's primarily needed is a standardized reification mecanism.
The marshalling is the easy part of the problem.

> How does that sound as a starting point?
I think your approach is correct, just that you didn't stress the
real difficulty.

Long ago, Andrew Bromage suggested we try Mercury as a basis for TUNES.
Mercury now has capabilities for functional-style programming,
dynamic typing, CORBA mapping, and more, so maybe we might think about it
again. Of course, it still has basically the same problem as RScheme:
it compiles through GCC.

## Faré | VN: Уng-Vû Bân   | Join the TUNES project!  http://www.tunes.org/ ##
## FR: François-René Rideau |    TUNES is a Useful, Not Expedient System     ##
## Reflection&Cybernethics  | Project for a Free Reflective Computing System ##
Atheism is a non-prophet organization.