RFC: TUNES Specification Pre-Pre-Draft

[Armin Rigo]

Hello Brian,

On Mon, Mar 31, 2003 at 05:06:44PM -0800, Brian T Rice wrote:
> In my workstation's draft, I have a section 4 called Elements, and this is
> supposed to go through the types of things step by step, giving some
> abstract specification in detail. Does this title sound fine? Does anyone
> have suggestions for the structure?

'Elements' is okay. For the structure, sticking with the same subsection 
numbers as in the previous section could be sufficient (e.g. what is outlined 
in 3.2.1 is specified in 4.2.1).

> "Implementation hints" itself doesn't seem useful enough to communicate
> what we'd be suggesting. Also, this would be a place to cite all sorts of
> information that we've collected onto the CLiki; the citations will really
> be the most important part of explaining to people how things could be
> done, really.

Yes, and I also think that conversely the draft itself will trigger the
creation of new CLiki nodes for the "implementation hints". (...that name
doesn't fit too well but I couldn't either figure out a better one)

> ...
> </elaboration>

Thanks !

> You're using some notions from natural linguistics which I don't believe
> apply in this case. (...)
>
> I suppose that I do, in the end, see an object's creation point as its
> sole context, and other contexts which use it are just using (sometimes
> incredibly trivial) copies or proxies of some sort. Neither of those terms
> "proxy" or "copy" denote the correct idea specifically, but they are good
> approximations for modern programming practice.

Ok, thanks for the precision. I will stick to that point of view for contexts
and objects.

> > 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:
> 
> I found this part of your mail very confusing, and I don't understand the
> relevance, but here are some attempted replies:

I wanted to know how you intend to comply with the Unified requirement as you
stated it. You say that we should be able to somehow represent any object from
any context inside of any other context. If you place no limit on the
"compatibility" that might have to exist between the two contexts then I don't
see how you can do better than being prepared to have to put the object into a
black box for the destination context. Of course it is not the most useful
solution, and there are cases where we can do much better. My purpose was to
review these cases.

> >  * creating in C2 an opaque reference of an object in C1 that can be used to
> > pass the object back to C1 later;
> 
> To pass the reference back or the object? I thought we had agreed within
> TUNES pages that opaque references are Considered Harmful. Try explaining
> which concept you mean, keeping http://cliki.tunes.org/Reference in mind.

This was intended to be the most general and less useful "black box"  
concept: an expression of the other context's object on which the only
available operation is to send the expressed object back into its source
context. I can imagine that data structures like simple lists could store
their elements as black boxes. My choice of term Reference was probably poor.

> >  * "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);
> 
> What implementational sense above?

The one you ruled out with the object/context paragraphs. This point is no
longer relevant. It seems that a system with general migration complies with
the Unified requirement if we can view blackboxing as an extreme form of
migration in which the black box is the same abstract object as the original
object but the new context possesses almost no operation to act on it. Does 
this make more sense or am I still off-target?

> > 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 don't understand what you mean by decoupling, since the three phases are
> already marked as separate. Furthermore, I don't think that the
> characterization of Send as "specific to distributed contexts" is a useful
> one: I may implement several memory regions within the same address space,
> and have some marshalling mechanism for transport across them, totally
> independent of any difference in semantics the objects transported may
> require in order to retain the proper meaning in the target context.

I believe that the Send operation works at a lower level than the Reify/Absorb
migration mechanisms. Maybe my point of view is not useful, but Send can
always be represented as a Reification-followed-by-Absorption operation. For
example, marshalling data between two memory regions is valid iff there is a
third, more abstract context in which both the original and the copied object
are the same object. This tends to make me view reification and absorption as
fundamental relationships whereas communication is (just) an operation.

-
Armin