[e-lang] Idea: How to do <import>.optUncall for emakers

Kevin Reid kpreid at mac.com
Thu Mar 22 16:34:45 CDT 2007


On Mar 21, 2007, at 16:06, Kevin Reid wrote:

> 1. <import> maintains a weak-key hash table mapping objects to import
> names (FQNs).
>
> 2. If <import>.optUncall does not find an entry in that table, it
> inserts an entry in the table mapping the object to a failure marker.
>
> 3. Any object returned by an emaker which is cached by <import> (i.e.
> DeepFrozen) and Selfish is inserted in the table, unless there is
> already an entry, in which case there is no effect.
>
> These rules ensure that <import>.optUncall can never change its
> answer for any particular object.

MarkM and I discussed this yesterday, and he pointed out that this  
allows determination of the load order of emakers in some situations:

A.emaker: def foo {}; [foo]

B.emaker: <import:A>[0]

C.emaker: <import:A>[0]

<import>.optUncall(<import:A>[0]) depends on which of B or C is  
imported first. This is arguably an information leak, though of only  
one bit per vat.

This can be avoided by using a separate mechanism to ensure that the  
object has been created by the evaluation of that particular emaker,  
and thus disallow B and C from claiming it:

4. In the scope in which the emaker expression is evaluated, a  
stamping auditor, unique to this loading operation, is placed.

5. If the object returned by the expression has the stamp of that  
auditor, then it must have been created by that evaluation, and it  
gets an entry in the previously-described table; otherwise, it does not.

We have not yet decided on an appropriate name for the auditor.  
Suggestions welcome.

Besides hiding the load order bug, this also allows emaker products  
to choose not to get an automatic uncall.

While this is moderately complex to implement, the only user-visible  
quirk is that if an emaker does <import>.optUncall(value-it-will- 
return) in its evaluation (before it has returned that result), the  
answer will be null forever.

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




More information about the e-lang mailing list