Object-accessibility and meta-level (was: HLL Primitives)

Brian T Rice water@tunes.org
Fri Feb 7 03:08:02 2003

Yay! Real discussion! :)

On Fri, 7 Feb 2003, Massimo Dentico wrote:

> Brian T Rice wrote:
> > Francois-Rene Rideau wrote:
> > [..]
> >>As for a conceptual model for attributes, etc. - in Tunes,
> >>I think that what I had in my mind when I wrote this page
> >>was that the "state" of the system at any moment could be seen as a set
> >>of (attribute, object(s), value(s)) tuples that are known to hold.
> I don't understand what these "(attribute, object(s), value(s)) tuples"
> without an explanation are supposed to be, but anyway ...

(Hopefully my more specific branched thread covered this decently.)

> > Alright. As for formalization, that's the task I'm attempting to
> > undertake. For example, your triples are "attributions" by lexical
> > derivative of the object-attribute concept. Unfortunately, "known to hold"
> > isn't absolute. You say yourself under the Safety and Security sections
> > that object-accessibility through capabilities or some enhanced notion
> > determines visibility itself in a perspective-based way. If we had a
> > single reflective tower, the simple answer would be that "the meta-level
> > knows", but this is not the case.

[Snipped explanation and URL for Capabilities.]

> Now back to object-accessibility and meta-level.
> 1) Let be O' an object which belongs to a meta-object MO' and
>     owns a capability C'.
> 2) Let be O" an object which belongs to a meta-object MO".
> 3) Let O', MO', C', O", MO" live in the current context CC.

Okay, keeping in mind here that the O'-MO' relationship, if you mean it to
be significant instead of "just any old meta-object of O'" will have to be
a holistic kind of meta-object: one that encompasses some entire aspect of
the object, like a representation/mirror. There are two distinct uses of
the term in Reflection as a field, so it's worth clarifying.

> A question immediately arises:
> 4) who is responsible for the "interpretation" of a capability (C')?
>     The current context (CC) or the meta-obect (MO') which the capability
>     owner (O') belongs?

Well, if you're assuming the "holistic" MO type, then technically, the CC
is accessed through the MO, so the problem may not be as difficult as it
seems. Don't forget to re-read the definition of Context in the CTO:
as well as on the HLL pages:

Basically, if both are holistic (the MO reifying all aspects of the object
and the context describing all of the evaluator state and semantics at
once), then there's not enough distinction to quibble over. I'm sure
there's still an argument here, but we'd need to re-read the E/Elibs
documents a bit, and probably ask Mark Miller as well, because E as is
doesn't address everything about capability security. I'm on the new
Squeak-E mailing list currently, and issues are arising because of just
Smalltalk's reflective nature that require him to push the envelope of the
model a bit. These discussions are pretty rough to deal with as well; I
don't think there'll be a definite answer soon.

However, I don't think capabilities are the whole answer. There has to be
some Tunes-style proofs and such. That is, specifying that a group of
objects hold to some set of equations or something. Anyway, I have no
answer for you right now.

> In what follow I assume that:
> 5) the answer to 4) is MO';
> 6) MO' and MO" use different capability mechanisms.

This seems the likely conclusion for now at least.

> Now if O' wants to grant C' to O" then musts exist a "translator" T
> of C' into a capability C", that MO" can interpret:

> 7) T(C') -> C"

Erm, sort of... for an object to grant another object its own capability
is probably not the right idea. But I can see how differing meta-objects
require translation of capability objects, in theory. In practice, I have
no idea how a capability object would need to be translated. My guess is
that it'd be another case of Migration where some declarative
specification of the two capability systems needs to be available, and
some reify/absorption mechanisms available to both.

> Another possibility is that, for 6) to hold, 3) musts be false
> (MO' and MO" live in different contexts). Probably this is the
> correct interpretation of "different reflective towers".


> Brian, are these the kind of problems to which you refer?

Yes, to some extent. The problem is that the reflective tower itself in
Tunes isn't the only way to look at it. You may need all sorts of
different meta-objects collaborating to get a picture of the "holistic"
meta-object. I was also reflecting one of Fare's ideas back at him, which
is that context helps determine visibility. Context is holistic, but
different contexts may react differently to a meta-object (non-holistic)
of a given object. It's a case of dispatch.

> Does this formulation make sense to you?

Pretty much. My reservation is that we don't really have the "meta-object"
term nailed down to my satisfaction yet, so it's not like we can answer
clear questions about them concisely.

Brian T. Rice
LOGOS Research and Development