RFC: TUNES Specification Pre-Pre-Draft

[Brian T Rice]

The only reason I delayed this reply is to make sure I gave everything the
proper thought it deserved.

On Sun, 30 Mar 2003, Armin Rigo wrote:

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

Great, so what do we call them?

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?

Also, what kind of implementation hints would help people out interests
me. I for one have ideas on how to do some interesting things in Slate to
get some frameworks into demonstration mode. Even an extension of Common
Lisp or Maude would be better for the language aspects in some ways. But
for now, some kind of document title and framework is needed.
"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.

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

Quoted from the spec:
>> The means of expression must be available within the system to abstract
>> some (any?) issue in a system-wide scope.

An attempt to elaborate:

There must be a sufficient collection/system of abstractions available
(but not necessarily imposed) in every area of the system for a
meta-system transition in some (any?) manner to be possible based on them.
A simple example is basic syntactic quotation or even escaping mechanisms.
More complex examples include quotienting in arbitrary directions of
abstraction, or some kind of quotient inversion, where a simple domain is
carved out of a complex domain by adding some required constraints which
they do not all satisfy. This latter example corresponds roughly to a
comprehension, of which various sorts exist.

As with any element of these requirements, this kind of capability has to
be available in any domain within the system or across multiple systems.

</elaboration>

"Meta-system transition" is vague (the TUNES Glossary's definition is too
verbose for this), but it is definitely distinguished from implementating
an interpreter for a feature and using it explicitly. There should be some
capability of absorbing this different-level protocol into the original
system.

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

Of course you wouldn't: that's my job. My worry is how to turn those terms
into types at some point. My doubt is that this won't happen and we'll
need a glossary. If there were a glossary, then we could eventually host
it inside of TUNES and link the terms to some key instantiations and use
those links programmatically.

> 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 Cont=
ext
> captures all of the implicit meaning of an object.  Practical examples te=
nd 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 differ=
ent
> Contexts and have completely different meanings in each one.  This is how=
ever
> 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 to=
o.
> Is that your point of view, or do you consider each object to live in a s=
ingle
> well-defined Context?

You're using some notions from natural linguistics which I don't believe
apply in this case. The bit about Context's role to give meaning to
previously-existing objects only makes sense if you are talking about
/analysis/, which means after-the-fact, or if I may be so bold, META with
respect to the original object. :-)

So basically, I would describe your viewpoint as being that of someone
reconstructing a context after the thing happened. This is not really
supported by the way we suggest that TUNES could work, although there is
an analogy (which I will explain in a second). In our case, we can
formally describe a language in advance: part of this is the syntax/
grammar that encodes the expressions entered, and the other part consists
of the possible changes in state of the evaluator, and these combine to
form the notion of context.

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.

> About Meta-Objects.  Maybe you were deliberately vague about them in this
[Snipped a question similar to Jecel's.]

I addressed this in my reply to Jecel. If it still raises questions,
include them in a follow-up to that, please.

> I would suggest that we need some emphasis on the Unified requirement.  W=
hat
> are the relationships between these various ways of relating objects betw=
een
> 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:

>  * 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.

>  * "casting" an object (in the implementational sense above) by consideri=
ng 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 th=
e
> code take a new meaning);

What implementational sense above? In Slate, I write another method if I
want another conversion, so it's the result of a program, not a language
feature. Implicit casting should not be a language feature in TUNES by
default (although of course there are many reasons to make it transparent
in specific contexts); I can't think of a single reason how this follows
from our principles.

The example of function invocation seems to be totally confused.

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

If I could tell what the previous two items signified, I could compare.

> Abstractedly, general migration seems to be about decompiling an object f=
rom a
> source context to an intermediate context with less implicit meaning (Rei=
fy or
> Slice in the draft), and then recompiling it from this common intermediat=
e
> context to the target context (Absorb or Install).  I would decouple thes=
e two
> operations which are at the core of Far=E9's notion of implementation fro=
m 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 anot=
her
> context, the "decompilation" operations are what *define* the source cont=
ext.

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.
Obviously the simplest case is indeed trivial, where a memory-manager just
rearranges the positions of objects in one space, but this doesn't
restrict the concept's domain.

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