Having time&knowledge

[Eric W. Biederman]

>>>>> "FR" == Francois-Rene Rideau <fare@tunes.org> writes:

FR> 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.
FR> We'll try to make it "as simple as possible, but no simpler".
FR> The more precise the configuration, the more complex the framework
FR> needed to specify it.
FR> Of course, most of the time, the configuration needs not be overly precise
FR> (i.e. most people don't care about which register was used at which clock
FR> cycle), and a pure and/or encapsulated programming style (see Haskell
FR> or Mercury) can help keep the interfaces simple.

Right.  But even more so is keeping to a single interface for a single
to perform one function.  With this learning to is dramatically
reduced.  One of the reasons I feel drawn towards CORBA (especially
CORBA services).

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

>> About working transparently acros networks etc.
FR> This is given immediately, once we can reify the state of a program
FR> (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.
FR> The core communication protocols are rather an easy problem.
FR> It's just a matter of a standard marshalling protocol, or, better even,
FR> a standard negociation protocol for marshalling purposes.

Grr. There you go, making this unnecessarily complex.
We don't need a negociation protocol, ugly.

We need a protocol for sending a function in the abstract.
We need a protocol for finding which function does which job.
  (This could probably be built upon a CORBA name service,
   and a CORBA search service).

Then we just search out which function is responsible for marshalling
arguments and rewrite it.

But we need some way to talk at first.

>> 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.
FR> The problem is that CORBA only deals with the marshalling,
FR> not with the important part, which is
FR> * having a well-defined, high-level semantics
I'm not sure what you mean, you are speaking very generally.

FR> * being able to fully reify the execution state of a program
There is a standard CORBA protocol/serivice to reify the state of an
object.  This is present.

FR> * having a generic framework for dealing with several "abstraction levels"
FR>  about program execution (source/declared semantics vs
FR>  register-wise execution, virtual vs actual memory/disk, etc)

This is what tunes is about, and yes this is the hard part.

FR> * including in our framework a generic facility for cacheing&invalidation
FR>  of "optimized" versions of the high-level code.

This is as trivial as marshalling.  Someone needs to write the
protocol true.

FR> These come all at once.
Patently false.  I've seen everything but the framework for
"abstraction levels" impelmented.  We need them all at once for tunes
however.


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

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

It's not the marshalling that hard.  It's getting tunes to not be
caught up in the low levels guts of the system, trying to get to the
abstraction layer.


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

I agree.

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

My point is tunes should be primarily a specification for reflection.
Using CORBA we can implement in whatever language we want, and stop
tripping over implementation details.  Once we start real work on the
tunes specification, we can start wondering what a total tune systme
will be, and looking at all of the fun things we can do with programs
that support total reflection with trusted partners.


Here's how my imagination sees tunes using CORBA.
1) For general types of things (like persistence, name services) using CORBA services.
2) For the specific reflection part, the core of tunes,
   writing an idl interface definition.
3) At least one, but probably several eager people in their favorite language
   implementing the tunes specification.

The tunes specification would primarily need to address
A) How to represent code, generically and for a specific machine.
B) How you would select where that code would go.


As far as difficulties with tunes I see 2.
1) Practical: Finding a place to start that is at a high enough level
  meaningful design can be done.
2) Design:    Writing the simple interfaces for reflection.

The actual implementation should be close to trivial once it's clear
what tunes wants.  And once some proof of concept implementations
exists Tunes will snowball into a real thing.

Eric