Transparent Selfless status/howto (was: Number comparison gotcha)

On Feb 2, 2011, at 23:22, Bill Frantz wrote:

> Since my Date object could be selfless
> <http://www.erights.org/elang/same-ref.html>, but that web page
> indicates that the selfless system hasn't been implemented yet,
> getting <=> to work seems like the next reasonable step.


Selfless is tricky to audit for, but I have a draft system in E-on-CL  
(unfortunately unpublished; as it happens I'm currently working on  
moving to git so that it's more practical to publish draft work, and  
have already done so for E-on-Java). It isn't committed yet primarily  
because I have low confidence in the correctness of the auditor; it  
has so many individual checks that it is plausible I missed or  
misimplemented one.

There is actually more than one kind of Selfless. (The taxonomy has  
been revised somewhat since that page was written.)

   * Atomic Selfless: objects like numbers and strings which have no
     parts.

   * Transparent Selfless: The kind you're thinking of.

   * Opaque Selfless: Like Transparent Selfless, but with the uncall not
     available to all clients. SturdyRefs are the prominent example.


One of the complexities is that the Transparent property (the object  
may be reconstructed from its components) is not just a constraint on  
the object itself (its __optUncall method) but also the object's maker  
(which must construct an identical object given the arguments  
mentioned in __optUncall). Therefore it must be an audit of some  
object including both the object definition and the maker.

This fact makes the interface particularly complex; here's what it  
looks like currently.

Transparent.authorize(
   def makeDateAuthor(TransparentStamp)
       implements Transparent.Author() {
     def makeDate(foo, bar) {
       return def date implements Selfless, TransparentStamp {
         ...
         to __optUncall() {
           return [makeDate, "run", [foo, bar]]
         }
       }
     })
   }
)

Transparent.authorize gives the passed function (makeDateAuthor) the  
unrestricted TransparentStamp iff Transparent.Author()'s audit shows  
that the stamp is not misused within the body of that function.

Among the restrictions in the current implementation are:

   * makeDate.run must have a result guard of any (or implicit any)
   * So must date.__optUncall
   * All of the auditors of date must be DeepFrozen.
   * The uncall must have a recipient of makeDate (the object containing
     def date {}) and a matching verb.
   * The uncall args must be exactly the same nouns as in makeDate.
   * makeDate's parameters must be unguarded.
   * def date must be directly inside makeDate with no intervening code.

It's been a while since I looked at this, so I don't recall exactly  
how much is necessary vs. convenience.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>