The future of lambda delegates

[Sean Kelly]

Walter Bright wrote:
> Mikola Lysenko wrote:
>> Such a translation is possible for any of these examples, albeit quite 
>> tedious.  From what I gather C# applies a similar technique with its 
>> lambda delegates and inner classes.  For a machine code compiler, such 
>> a rewrite is not even necessary, since it could simply overwrite the 
>> frame pointer at the start of the function with a GC allocated block.  
>> This would preserve frame-based addressing for arguments and 
>> variables, requiring no change in any of the internally generated 
>> machine code.  The run time overhead is fairly low, only on the order 
>> of one extra memory allocation per function call.  Practically, such 
>> an implementation would be extremely simple.
>>
>> Any thoughts or comments?
> 
> Yes, I'm aware of this, and want to fix it for D 2.0. The way to fix it 
> is, as you suggest, allocating the frame on the heap rather than on the 
> stack. The drawback with that is that heap allocation is far, far more 
> expensive than stack allocation.

In the general case, yes, but it doesn't have to be.  An allocator with 
per-thread heaps could allocate without the need for a mutex, and 
special cases like this could force an allocation if the heap is full 
instead of triggering a collection.  That said, I agree with your 
motivation here.

> An ideal solution would be if the compiler could statically detect if a 
> nested class reference can 'escape' the stack frame, and only then 
> allocate on the heap. Otherwise, the current (very efficient) method of 
> just passing a frame pointer would be employed.

Agreed.  As well as detect whether the delegates reference any local 
stack data in the first place.  The alternative would be to use a 
separate keyword for these delegates, 'closure' or 'lambda' or some 
such, but that's potentially confusing, and leaves anonymous delegates 
in an odd position.

> Of course, then there's the problem of nested functions within nested 
> functions, that then escape and try to reference multiple nesting levels 
> back on the stack.

I would expect the compiler to just put as much data on the heap as 
necessary, be it for a single nesting level or for multiple levels.  I 
suppose it would be ideal for this to be contiguous, but it wouldn't 
have to be.  I grant that the code generation may be a bit of a pain, 
but it doesn't sound impossible.


Sean