[e-lang] "implements Selfless" is useful!

[Kevin Reid]

Context:

I'm working on unconfusing the Selfless and Transparent concepts in E- 
on-CL.

What used to be "def ... implements SelflessStamp { to __optUncall()  
{ ... }}" will now be "def ... implements Selfless, TransparentStamp  
{ to __optUncall() { ... }}". TransparentStamp (privileged) declares  
the accuracy of __optUncall(), and Selfless (safe) declares that the  
object should be compared some other way than creation identity.

MarkM and I discussed what should happen when an object with  
TransparentStamp gives a malformed uncall (kill the vat), and what  
should happen when an object does "implements Selfless" but not also  
Transparent (or any other supported means of comparison). We decided  
that such an object should be considered permanently *unsettled* (as  
a representation of "not possible to compare this").

It has just occurred to me that this behavior is actually useful.

Examples:

1. Hiding identity distinctions from clients:

   def make() { return def a() implements Selfless { ... } }
   def a := make()
   def b1() { return a }
   def b2() { return make() }

The clients of b1 and b2 cannot tell which implementation is which by  
sameness of the returned objects; therefore this hides implementation  
details that clients don't need to know.

2. Allowing a compiler to move closures:

It is impossible to tell how many times a Selfless object is created  
(assuming the auditors and their containing slots are DeepFrozen).  
Therefore, the compiler is free to relocate their creation. For  
example, in this (slightly implausible) code, the 'missing' thunk may  
be constructed once outside the loop.

   for key in keys {
     process(map.fetch(key, fn implements Selfless { missing }))
   }

(Incidentally, the relatively heavyweight "implements Selfless" in  
this code could be removed neatly by the proposed feature of lambda- 
args objects being able to supply auditors for the block-functions;  
then we could write something like "sfn () do { missing }" (but with  
better names).)

By itself, this is not much of an optimization, but it might work  
together well with pointer-identity-based memoization tables; it  
might also have useful effects for lambda-args expressions.

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