[e-lang] What's a SturdyRef (or TraversalKey, String, ...), anyway?

[Kevin Reid]

On Aug 8, 2007, at 17:35, David Hopwood wrote:
> Kevin Reid wrote:
>> On Aug 7, 2007, at 12:02, David Hopwood wrote:
>>> I thought that such objects should be considered Selfless but not
>>> Transparent?
>>>
>>> (see Figure 3 of <http://www.erights.org/elang/kernel/auditors/>)
>>> ...
>>> "Do not reveal [all of] their components" is absence of an
>>> auditable property. So I am not sure that this category needs a
>>> specific name. Why is "Selfless && !Transparent" not sufficient?
>>
>> I'm starting to think that this may be the right answer; especially
>> as I've thought of two categories of S&!T objects:
>>
>>    - those compared in some primitive way (e.g. integers).
>
> These should be considered Transparent. Otherwise, objects with
> primitive fields cannot be DeepTransparent (if DeepTransparent just
> means 'transitively Transparent').

I don't like this. I think there is value in having a simple name for  
"those objects which uncall accurately", and little value in having  
DeepTransparent.

>>    - those compared, like S&T, by an uncall (portrayal), but not one
>> revealed to all clients.
>
> These are called "selectively transparent" in
> <http://www.erights.org/javadoc/org/erights/e/elib/prim/ 
> MirandaMethods.html#__optUncall(java.lang.Object)>.

Okay, that's fine.

> <http://www.erights.org/elang/kernel/auditors/>:
>
> # OpenSource: Ensure the existence of a standard method whose  
> implementation
> # invokes a special language keyword for returning the abstract  
> syntax tree
> # of the object expression.
> # OpenState: Ensure the existence of a standard method that  
> generates and
> # returns a mapping containing the names and values of all the  
> variables
> # accessed in the object expression.
> # Transparent: Check that the object passes both the OpenSource  
> auditor and
> # the OpenState auditor.
>
> But this appears to be out of date (as is
> <http://www.erights.org/elang/same-ref.html>).

It does appear to be out of date: there is no current plan that I  
know of to make use of "openState" and "openSource" objects.

In modern terms, the type of Selfless object being described there is  
a "mobile code" object, and its "openState" and "openSource" methods  
would be combined into an __optUncall method (which returns a a  
portrayal of an "eval" operation).

> Is the following documentation what I should be looking at instead?
>
> <http://www.erights.org/javadoc/org/erights/e/elib/prim/ 
> MirandaMethods.html#__optUncall(java.lang.Object)>
>
> # Scalars (ints, float64s, chars, boolean, null) and bare Strings are
> # atomic. __optUncall on an atomic object[] return[s] null, but atomic
> # objects are still considered transparent. Objects which return  
> non-null
> # are non-atomic and transparent.
>
> So according to this, any object that (always?) returns non-null from
> __optUncall is transparent, whether or not the returned portrayal is
> accurate.

This does seem to be consistent with the terminology in the auditors  
document.

> I am a little confused: whether __optUncall always returns non-null is
> undecidable in general. Auditable properties should be stable (i.e. if
> an object ever has a property, it should always have it), so it is not
> sufficient to just call __optUncall once and test whether the  
> result is
> non-null, since the object may not be deterministic.

It is not especially useful to audit for "returns non-null", as there  
are innumerable ways an uncall could be otherwise bogus. When  
auditing for an uncall being *accurate*, the auditor of course will  
recognize only a few possible ways to write the method.

> It would make more sense to test whether the __optUncall method has  
> been
> overridden (or remove it from the Miranda methods, and test whether  
> the
> method exists). Alternatively it would be possible to test whether it
> exists and has an appropriate return guard that excludes null.

I don't think there's any reason to make this change. Especially,  
having __optUncall in the miranda methods reserves the name universally.

> Continuing the quote from the Miranda methods page:
>
> # Non-atomic objects that return null are opaque. Opaque objects  
> may be
> # selectively transparent to certain clients by using
> # __optSealedDispatch(java.lang.Object,  
> org.erights.e.elib.sealing.Brand)
> # as described there.
> #
> # When a transpa[r]ent non-atomic object is Selfless, then the  
> result of
> # __optUncall is guaranteed to be accurate: It describes a call  
> that, when
> # performed, must result in this very same object, according to E's  
> "=="
> # operation. The Selfless auditor ensures that all Selfless objects  
> are
> # accurately self-describing in this way.
>
> Hmm. This is self-consistent, but:
>
>  - the terminology does not convey the right intutitions, I think  
> -- it is
>    not obvious that the portrayal of a Transparent object is  
> guaranteed to
>    be accurate only if it is also Selfless.
>
>  - why is it the Selfless auditor that is responsible for enforcing
>    accurate portrayal? Logically, "accurately portrayed" is a subtype
>    of "portrayed", independent of Selfless (and independently useful).

I also find this to be a rather unuseful definition. The one I'm  
proposing instead is:

   * A Transparent object is one whose __optUncall produces an  
accurate portrayal.

   * A selectively transparent object (which is not a kind of  
Transparent) is one which provides an accurate uncall via sealed  
dispatch.

   * A Selfless object is one which is immutable and compared by some  
means defined by the object; that being either Transparent or  
selectively transparent.

(Note that primitive comparisons of e.g. integers are observably  
indistinguishable from selective transparency, if you don't have the  
unsealer.)

> Arguably "Transparent" is misnamed, since:
>
>  - a non-Selfless object has an opaque identity, and in that sense it
>    is not transparent.
>  - "returns non-null from __optUncall" does not guarantee transparency
>    in any intuitive sense: an object with an inaccurate portrayal is
>    not intuitively transparent.

I agree with the second point, and I propose (see above) that  
Transparent be redefined to mean "returns an accurate portrayal". As  
to the first, I'm uncertain.

> It might be useful to be able to perform cacheing or memoization in
> a way that can be recognized by the auditing mechanism. (This would  
> also
> have the advantage of not preventing an object from being  
> DeepFrozen or
> Functional.) However, that's something that can be discussed  
> separately.

E-on-CL already has something like this: There is a memoization  
module which is approved DeepFrozen by stamp (and designed to be  
observably immutable). Therefore, anything can use it while passing  
DeepFrozen itself.

> ====
> Here is a suggested clean-up, illustrated in the attached diagram:
>
>  - remove __optUncall from the Miranda methods (consider also renaming
>    it to __optPortray);
>  - call any object that is either primitive or has an
>    __optUncall method "Portrayed";
>  - call a Portrayed object that is guaranteed to have an accurate
>    portrayal (because its __optUncall method has a standard form?)
>    "WellPortrayed";
>  - call any WellPortrayed and Selfless object "Transparent" (this is
>    an incompatible change to the meaning of "Transparent", but I think
>    it fits the name better).
>  - objects with an __optSealedDispatch(brand) method that can return a
>    sealed portrayal would be called "selectively portrayed".

I probably haven't considered it fairly, but I don't especially like  
this: it introduces many new names, and they don't feel right.

Having said that, what do you think of my proposal? :)

> Going back to something in your original post:
>> [...] our discussion last Wednesday assumed (!) that any Selfish  
>> object
>> has the property that once finalizers are invoked on it, that  
>> identity
>> cannot reoccur.
>
> This property would be true, if objects such as SturdyRef,  
> TraversalKey
> etc. are Selfless.

Yes, this is why I asked my original questions: I wanted to create a  
solid definition of what these objects being Selfless means.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>