"Walter Bright" <newshound1@digitalmars.com> wrote in message news:fggfqq$sh5$1@digitalmars.com...
> How do D closures work?
>
> 1) The compiler makes a distinction between a nested function that 'escapes' the scope, and one that does not. It uses a very simple, but conservative, heuristic - did someone take the address of the function? If yes, it assumes the function escapes.
>
> It's not an optimal solution because the "does the function escape" heuristic captures too many functions.

Indeed.. of course there might not be any other way to really check it..

One source of false positives is the @#*(%@# restriction where you can't forward reference nested functions, and instead have to put their addresses in local delegates.  Get rid of that, and there's one problem gone..

Walter Bright wrote:
> D 2.007 brings full closures to D. I was tired of D being denigrated for not having "real" closures.

Yay!! I still can believe it. It's certainly the feature that I wanted to see in the language the most.

Thank you Walter.


-- 
Julio César Carrascal Urquijo
http://jcesar.artelogico.com/

> It's not an optimal solution because the "does the function escape" heuristic captures too many functions.

You could let the programmer specify explicitly whether or not to make a function a closure or not, maybe with a key word or something.

Craig Black wrote:
>> It's not an optimal solution because the "does the function escape" heuristic captures too many functions.
> 
> You could let the programmer specify explicitly whether or not to make a function a closure or not, maybe with a key word or something.
> 
> 

I would have thought 'scope' would have some role in this. It currently means 'allocate on the stack', and (is this implemented yet?) when used as a storage class for function parameters, it is supposed to mean, "I won't escape this variable". You could extend the "does the function escape" heuristic to say, "the function escapes if it is assigned to a non-scope variable, or is used as a non-scope argument."

This would behave correctly for what I believe is one of the major uses of functions: sort/search/etc with a predicate. These things almost never escape the predicate, so they can be written:

T find(T)(ref T[] array, scope bool delegate(T t) matches)
{
    ...
}


    -- Reiner

Reiner Pope wrote:
> Craig Black wrote:
>>> It's not an optimal solution because the "does the function escape" heuristic captures too many functions.
>>
>> You could let the programmer specify explicitly whether or not to make a function a closure or not, maybe with a key word or something.
>>
>>
> 
> I would have thought 'scope' would have some role in this. It currently means 'allocate on the stack', and (is this implemented yet?) when used as a storage class for function parameters, it is supposed to mean, "I won't escape this variable". You could extend the "does the function escape" heuristic to say, "the function escapes if it is assigned to a non-scope variable, or is used as a non-scope argument."
> 
> This would behave correctly for what I believe is one of the major uses of functions: sort/search/etc with a predicate. These things almost never escape the predicate, so they can be written:
> 
> T find(T)(ref T[] array, scope bool delegate(T t) matches)
> {
>     ...
> }
> 
> 
>     -- Reiner

Oh, and

void foo()
{
    int n = ...;
    ...
    scope dg = { return n+2; };
    ...
}

gives you a way to tell the compiler, "dg doesn't need to be a lexical closure".


    -- Reiner

Walter Bright Wrote:

> D 2.007 brings full closures to D. I was tired of D being denigrated for
> not having "real" closures.
> ...

OK, I get the full closure thing, but can someone come up with a typical example of its use please?

Steve Teale:
> OK, I get the full closure thing, but can someone come up with a typical example of its use please?

You are right, this may help: http://en.wikipedia.org/wiki/Closure_%28computer_science%29

Bye,
bearophile

Craig Black wrote:
>> It's not an optimal solution because the "does the function escape" heuristic captures too many functions.
> 
> You could let the programmer specify explicitly whether or not to make a function a closure or not, maybe with a key word or something.
> 
> 

First,  great job Walter!  I have been just lurking for some time but you are polishing and improving things nicely.  Long live D!

As far as closures go,  would it have been possible to just copy the whole stack frame to the heap and update the references?  GC would eventually reclaim it, no?

-David

David Medlock wrote:
> Craig Black wrote:
>>> It's not an optimal solution because the "does the function escape" heuristic captures too many functions.
>>
>> You could let the programmer specify explicitly whether or not to make a function a closure or not, maybe with a key word or something.
>>
>>
> 
> First,  great job Walter!  I have been just lurking for some time but you are polishing and improving things nicely.  Long live D!
> 
> As far as closures go,  would it have been possible to just copy the whole stack frame to the heap and update the references?  GC would eventually reclaim it, no?
> 
> -David

Oops scratch that,  you still need to determine *when* to do it..

Denton Cockburn schrieb:
> On Fri, 02 Nov 2007 14:03:59 -0700, Walter Bright wrote:
> 
>> D 2.007 brings full closures to D. I was tired of D being denigrated for not having "real" closures.
>>
> 
> Nicely Done.  Lisp is looking less special everyday.

Awesome. Seems it's time to update

http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD

and the next big thing may be first class continuations which has an interesting application in GUI code, see

http://citeseer.ist.psu.edu/fuchs95escaping.html