The future of lambda delegates

[Bruno Medeiros]

Mikola Lysenko wrote:
> "Walter Bright" <newshound at digitalmars.com> wrote in message 
> news:ebvl5s$2k03$1 at digitaldaemon.com...
>> 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.
>>
> 
> Well, in general it is not decidable if a given nested function escapes. 
> Here is a trivial example:
> 
> void delegate() func(void delegate() F)
> {
>     F();
>     return { F(); };
> }
> 
> This function will only return a delegate when F halts. One conservative 

I do not understand why or how this is undecidable. It seems clear that 
a delegate escapes (the literal delegate).

> strategy is to simply look for any nested function declarations in the 
> function's lexical extent.  If such a declaration exists, then that function 
> must be heap allocated.  I suspect that this is how C# handles the problem.
> 

Yes, that's idea that should be effective enough, if one wants language 
auto-detection of heaped functions.

> Another possibility is to add a special attribute modifier to the 
> declaration of the initial function.  This places the burden of determining 
> 'escapism' on the programmer instead of the compiler, and is probably the 
> simplest to implement.
> 
> Perhaps the most flexible solution would be a combination of both 
> approaches.  By default, any function containing a nested function 
> declaration gets marked as heap allocated - unless it is declared by the 
> programmer to be stack-based.  For this purpose, we could recycle the 
> deprecated 'volatile' keyword.  Here is an example:
> 
> volatile void listBATFiles(char[][] files)
> {
>     foreach(char[] filename; filter(files,  (char[] fname)  { return 
> fname[$-3..$] == "BAT"; })
>         writefln("%s", filename);
> }
> 
> In this case, we know that the anonymous delegate will never leave the 
> function's scope, so it could be safely stack allocated.  Philosophically, 
> this fits with D's design.  It makes the default behavior safe, while still 
> allowing the more dangerous behavior when appropriate.
> 
> 

'volatile' is a crappy name IMO.

Consider this function:
   volatile void delegate() func(int b);
is func "heaped"(volatile), or is the return value dg type heaped? This 
may lend to some ambiguities.
Another option is for the specifier to be postfixed. Supose that NEW 
means heaped, and AUTO means stack framed:
   void delegate() AUTO func(int b) NEW;
(note AUTO is default and thus redundant)
I do not know for sure the implications in terms of grammar parsing for 
each of these alternatives, Walter should know better.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D