RFC: TUNES Specification Pre-Pre-Draft

[Brian T Rice]

On Thu, 3 Apr 2003, Armin Rigo wrote:

> 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 anyo=
ne
> > 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 outl=
ined
> in 3.2.1 is specified in 4.2.1).

Yes, I'll try to do that, although I'm hoping that if we can't keep
document units self-contained, that there'd be some sufficient linking
capability built in. I may have to write a document processor at some
point to link all formally-defined terms and types to their definitions.
Does anyone know of a LaTeX package which does this sort of thing?

> > You're using some notions from natural linguistics which I don't believ=
e
> > 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 cont=
exts
> and objects.

Well, I could also be dead wrong (in terms of this being the most
beneficial definition for TUNES of context). But that's the best concept I
could derive from what Fare wrote and has stated in conversations with
him, and it's a good working definition until we decide that a more
general one is needed.

> > > 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 t=
he
> > 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.

Oh, I see. Well, now that you put it that way, I'm fairly dissatisfied
with the description as it is. What I mostly meant was that contexts
should not have a systemic restriction on what can be expressed in them,
unless the context is created within a restricted subset of TUNES
semantics (which are made for a specific reason). So there should be a
means of expressing any object from any other context within a given one,
unless that expression is explicitly restricted by specifying a subset.

Does this sound fine? I'll try to work in some correction based on this
into the document in the Unified section.

> > >  * 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 p=
oor.

This choice seems like one best left to a higher-level policy, say for
security purposes or maybe about scoping. If it's a high-level choice like
that, then presumably both of our perspectives on this could be expressed
without contradiction. However, I'll still have to think about it.

> 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?

Migration handles it to some extent, sure. The problem is that migration
only part of the story, since there's also the question of how much
linguistic components or semantics the contexts have in common; if there's
not enough, we'd need to invoke the meta-translator framework and have the
user involved in the process where there isn't an obvious solution.

The "blackbox" concept strikes me as a specific example of some more
general choice, though. Not that I have a specific definition of that,
only a vague idea at the moment, unfortunately. :P

> > > 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=E9'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 use=
ful
> > one: I may implement several memory regions within the same address spa=
ce,
> > 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/A=
bsorb
> 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 i=
s a
> third, more abstract context in which both the original and the copied ob=
ject
> are the same object. This tends to make me view reification and absorptio=
n as
> fundamental relationships whereas communication is (just) an operation.

Okay, this seems to make some sense. To rephrase to verify, we would have
two phases consisting of Reify and Absorb at a top level, which rely on
some lower-level or administrative functionality which renders what is
sliced and re-constructs it in the receiving context.

--=20
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/