Const-only capture/closure #563

Activity

1. dcodeIO commented on Mar 28, 2019

   

   dcodeIO

   on Mar 28, 2019

   Last edited by dcodeIO

   Member

   More actions

   Yeah, this has been discussed a while ago. To make this work, a function enclosing a variable would have to take it as an additional argument. To give a bit of background for others wondering:

   WASM does not have nested functions as one is used to in JS, so

   // TS
   function foo(): i32 {
     var a = 1;
     function bar(): i32 {
       return a;
     }
     return bar();
   }

   would have to compile to something like

   // WASM
   function foo(): i32 {
     var a = 1;
     return foo_bar(a);
   }
   
   function foo_bar(__closure_a: i32): i32 {
     return __closure_a;
   }

   which obviously detaches the enclosed variable, leaving it technically mutable, but not propagating changes back to the closure, but is still a ok-ish placeholder until there's something better.

   A proper implementation that allows mutating the variable would need to allocate a closure on the heap that contains a and redirect all accesses in both foo and bar to the closure. Issue here is lifetime because a function isn't represented by a heap object itself, making it necessary to find another way to free the closure's memory once the lifetime of all functions referencing it ends. This problem can be illustrated in

   function foo(): () => i32 {
     var a = 1;
     function bar(): i32 {
       return a;
     }
     return bar;
   }

   where the lifetime of the reference to bar returned by foo is the reference for the closure's lifetime. Also note that foo could be called multiple times, returning multiple closures that must become collected somehow.
2. singpolyma-shopify commented on Mar 28, 2019

   

   singpolyma-shopify

   on Mar 28, 2019

   ContributorAuthor

   More actions

   I'm working around it by using a Closure class for now, but it makes me feel like an old-timey Java dev ;)
3. MaxGraey commented on Mar 28, 2019

   

   MaxGraey

   on Mar 28, 2019

   Last edited by MaxGraey

   Member

   More actions

   We already discussed about closures and I think it definitely could implement before function references proposal. One main question is how handle closure's lifetime without GC/RC
4. dcodeIO commented on Mar 28, 2019

   

   dcodeIO

   on Mar 28, 2019

   Last edited by dcodeIO

   Member

   More actions

   Thinking about this a bit more: One first step to solve the GC issue could be to wrap a function table index in a heap object and returning a pointer to that instead of just a bare function index, of the form

   class Closure {
     functionIndex: u32;
     data: ClosureData | null
   }

   where ClosureData is just a blob of data with no static type information. Instead, static type information goes into compiled functions in the form of loads and their offsets (if that's possible, still thinking). Now, whenever a function is called indirectly, the function index is loaded and data appended to the call. The reference to a function then becomes a reference to the closure (indexes aren't collected anyway), making the closure itself and its data collectible once not referenced anymore.

   One missing building block for this is that the compiler must evaluate the conditions leading to a closure in a pre-pass, so it can replace accesses to locals before it sees the closure using them. That's the hard part (because the compiler is single-pass currently) :)
5. stale commented on Apr 27, 2019

   

   staleBot

   on Apr 27, 2019

   More actions

   This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
6. stale

   added

   stale

   on Apr 27, 2019
7. stale

   closed this as completedon May 4, 2019