[e-lang] Idea: generic makers for PBC

[Kevin Reid]

All currently possible PassByCopy objects are not mobile code;  
rather, they depend on the receiving vat already having a similar  
maker with which to construct a similar object.

In the absence of other evidence, I believe that we will continue to  
want the properties of such makers, even when mobile code becomes  
possible.

The obvious means of adding such objects is to add emaker files  
containing such makers. However, <import> is PassByProxy, and so

def makeFoo {
   to __optUncall() { return [<import>, "run", ["makeFoo"]] }
   to run(...
}

will not have the desired effect.

Making <import> PassByConstruction is an obvious answer, but I think  
this is undesirable since <import> will often vary significantly  
between vats, and there is another behavior that might be useful:

Consider three objects in independent vats,

   A --> B --> C

where B is a proxy of some variety for C. It would be desirable for B  
to be able to pass on PassByConstruction objects to C without B's vat  
knowing about every non-mobile-code PBC object maker that might come by.

I therefore propose a separate loader; I have no name for it at the  
moment. This loader might or might not use the same source/namespace  
as <import>. Its distinguishing properties are:

   - It is PassByCopy by way of being an exit (in Data-E terms).
   - It will return a maker for any name requested.

If asked for a FQN it doesn't know, it will return a 'generic' object.

def makeGeneric(uncall) {
   def generic implements pbc {
     to __optUncall() { return uncall }
     match [verb, args] { makeGeneric([generic, verb, args]) }
   }
}

This allows any PassByConstruction object to be created as a minimal  
structure at B, which will unserialize to the intended object at C.

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