[e-lang] <import> with cycle breaking is not DeepFrozen

[Kevin Reid]

In the event of mutually recursive emakers,

   a.emaker
     def b := <import:b>
     def a { ... }

   b.emaker
     def a := <import:a>
     def b { ... }

the <import>.get of whichever emaker is not the one first loaded will  
return a promise, to break the cycle.

This behavior means that <import> is not actually DeepFrozen, because  
it returns a value which observably changes (even though it is not  
otherwise mutable).

For example, b.emaker can define:

   def mistake() :any implements DeepFrozen {
     return Ref.isResolved(<import:a>)
   }

This function will return false during construction of b-and-a and  
true afterward, and is therefore not DeepFrozen, yet auditing will  
accept it since it closes over only DeepFrozen references.


Proposal #1:

Remove support for cycle breaking. A cyclic import kills the vat.  
Users can use lazy slots to avoid cycles.

(here 'memoizeDF' is the memoizer discussed in
<http://www.eros-os.org/pipermail/e-lang/2006-May/011270.html>
which caches return values even if they are not selfless)

   /** DeepFrozen-result version */
   def importLazy__uriGetter {
     to get(fqn) :any {
       return memoizeDF(
         def slot implements DeepFrozen { to getValue() { <import> 
[fqn] }})
     }
   }

   /** not-DeepFrozen-result version */
   def importLazy__uriGetter {
     to get(fqn) :any {
       var box := null
       return def slot {
         to getValue() :any {
           if (box == null) { box := [<import>[fqn]] }
           return box[0]
         }
       }
     }
   }

   def &a := <importLazy:a>


Proposal #2:

Make <import> not marked DeepFrozen.

Anything which is to be DeepFrozen would need to not refer to  
<import>. I'm not sure how bad this would be.

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