RFC: TUNES Specification Pre-Pre-Draft

[Armin Rigo]

Hello Brian,

A couple of thoughts about your draft...

First of all thanks for the effort.  It seems to go into the direction of
filling the (huge) gap between the very-high-level ideas that are all that
Tunes has been so far, and concrete implementation.  Although you want it to
remain very abstract I would encourage more and more concrete sections to be
appened (with proper warnings in each section that these are just one possible
way to implement the ideas of the previous section).  Unlike the CL specs we
have no concrete implementation(s) in mind to guide us.  I feel we need a more
bidirectional process between concrete and abstract.  For example, all the
"big picture" operations of section 3 could be elaborated on in section 4, and
some implementation hints given in section 5.

I'm very positive about the Overall requirements section.  The only point not
completely clear to me is "Self-Extensible"; can you elaborate?

Let's focus on the High-Level aspect (which I'm most interested in).  As you
point out there is some confusion between Types and Terms, but eventually all
these Terms could be explicit Types in the system as well, so I wouldn't worry
too much about it.

The Context and Meta-Object types need some elaboration.  I am not sure I
clearly know what you encompass under each concept.  You tell that a Context
captures all of the implicit meaning of an object.  Practical examples tend to
show me that the role of a Context is rather to give some meaning to a
previously-existing object.  The same object may exist in a lot of different
Contexts and have completely different meanings in each one.  This is however
based on an implementational point of view on objects: for example, an
execution Context of an imperative language gives meaning to a linguistic
Symbol object by storing the current value of the corresponding variable.  
The same Symbol object can be considered outside any execution Context too.  
Is that your point of view, or do you consider each object to live in a single
well-defined Context?

About Meta-Objects.  Maybe you were deliberately vague about them in this
section 3; if so, consider the following as a question about how you plan to
develop this idea "later on".  Do you adhere to the view that each object is
defined by a single Meta-Object, recursively, and that the "infinite
meta-tower problem" should be solved with a Root object that is its own
Meta-Object?  I can think about two worthwhile deviations from this classical
image.  Firstly, a Meta-Object could define only some aspect of the semantics
and/or implementation of an object, allowing for some more dynamic, forking,
lazy version of the "tower".  Secondly, the Meta-Object relationship could be
related more explicitely to the notion of implementation, so that the
Meta-Object is more concrete (lower-level) than the object; on a PC the
hardware is the ultimate Meta-Object (unless you consider it is itself defined
within the Real World Meta-Object).

I would suggest that we need some emphasis on the Unified requirement.  What
are the relationships between these various ways of relating objects between
two contexts C1 and C2:

 * creating in C2 an opaque reference of an object in C1 that can be used to
pass the object back to C1 later;

 * "casting" an object (in the implementational sense above) by considering it
no longer inside C1 but in C2 --- which changes its meaning (e.g. when
creating an execution context upon function invocation, the symbols in the
code take a new meaning);

 * migrating an object from C1 to C2, keeping intact its original meaning (or
at least specific aspects of it).

Abstractedly, general migration seems to be about decompiling an object from a
source context to an intermediate context with less implicit meaning (Reify or
Slice in the draft), and then recompiling it from this common intermediate
context to the target context (Absorb or Install).  I would decouple these two
operations which are at the core of Faré's notion of implementation from the
Communicate or Send operation which is specific to Distributed contexts.  
Essentially, because the reification of the implicit meaning of an object of
the source context gives a more verbose translation of the object in another
context, the "decompilation" operations are what *define* the source context.


I hope all this makes sense to people here.  I also hope it can be of some
use.


A bientôt,

Armin