Jump to page: 1 28  
Page
Thread overview
Let's get the semantic around closure fixed.
May 18, 2021
deadalnix
May 18, 2021
Max Haughton
May 18, 2021
Paul Backus
May 18, 2021
deadalnix
May 18, 2021
deadalnix
May 19, 2021
Max Haughton
May 19, 2021
Walter Bright
May 19, 2021
Walter Bright
May 19, 2021
Walter Bright
May 19, 2021
deadalnix
May 19, 2021
Walter Bright
May 19, 2021
deadalnix
May 19, 2021
deadalnix
May 19, 2021
Walter Bright
May 19, 2021
deadalnix
May 19, 2021
deadalnix
May 19, 2021
deadalnix
May 19, 2021
deadalnix
May 19, 2021
Walter Bright
May 19, 2021
Adam D. Ruppe
May 19, 2021
Adam D. Ruppe
May 20, 2021
Walter Bright
May 20, 2021
deadalnix
May 20, 2021
Walter Bright
May 19, 2021
deadalnix
May 19, 2021
deadalnix
May 19, 2021
Paul Backus
May 19, 2021
deadalnix
May 20, 2021
Paul Backus
May 20, 2021
Adam D. Ruppe
May 20, 2021
deadalnix
May 20, 2021
deadalnix
May 21, 2021
TheGag96
May 21, 2021
Max Haughton
May 28, 2021
Q. Schroll
May 28, 2021
Adam D. Ruppe
May 28, 2021
deadalnix
May 28, 2021
Paul Backus
May 28, 2021
Max Haughton
May 30, 2021
deadalnix
May 31, 2021
deadalnix
May 21, 2021
Adam D. Ruppe
May 19, 2021
Jesse Phillips
May 19, 2021
Paul Backus
May 18, 2021

Long story short: https://issues.dlang.org/show_bug.cgi?id=21929

Closure do not respect scope the way they should. Let's fix it.

May 18, 2021

On Tuesday, 18 May 2021 at 16:47:03 UTC, deadalnix wrote:

>

Long story short: https://issues.dlang.org/show_bug.cgi?id=21929

Closure do not respect scope the way they should. Let's fix it.

Time to consider by-value captures? Closures (specifically the way they interact with the GC) seem problematic in general, not just here.

May 18, 2021

On Tuesday, 18 May 2021 at 17:40:17 UTC, Max Haughton wrote:

>

On Tuesday, 18 May 2021 at 16:47:03 UTC, deadalnix wrote:

>

Long story short: https://issues.dlang.org/show_bug.cgi?id=21929

Closure do not respect scope the way they should. Let's fix it.

Time to consider by-value captures? Closures (specifically the way they interact with the GC) seem problematic in general, not just here.

Does a delegate do anything more than retaining a pointer to the stack record?
Anyway, it should not escape the scope it references. So escape analysis is your friend.

May 18, 2021

On Tuesday, 18 May 2021 at 17:53:20 UTC, Ola Fosheim Grostad wrote:

Forget all that... Mixed up with local functions... :P

May 18, 2021

On Tuesday, 18 May 2021 at 16:47:03 UTC, deadalnix wrote:

>

Long story short: https://issues.dlang.org/show_bug.cgi?id=21929

Closure do not respect scope the way they should. Let's fix it.

Btw, javascript is irrelevant. "var" always binds names to the outmost scope at the beginning of the function, where it appears in the text is only to be more reader friendly.

May 18, 2021

On Tuesday, 18 May 2021 at 17:53:20 UTC, Ola Fosheim Grostad wrote:

>

Does a delegate do anything more than retaining a pointer to the stack record?
Anyway, it should not escape the scope it references. So escape analysis is your friend.

The compiler does escape analysis and pre-emptively allocates any variables that escape through closures on the GC heap.

The bug here is that, for variables declared in loop bodies, the compiler should allocate a new copy on the heap for each loop iteration, but instead it only allocates one copy that's reused across all iterations.

May 18, 2021

On Tuesday, 18 May 2021 at 18:51:40 UTC, Paul Backus wrote:

>

On Tuesday, 18 May 2021 at 17:53:20 UTC, Ola Fosheim Grostad wrote:

>

Does a delegate do anything more than retaining a pointer to the stack record?
Anyway, it should not escape the scope it references. So escape analysis is your friend.

The compiler does escape analysis and pre-emptively allocates any variables that escape through closures on the GC heap.

The bug here is that, for variables declared in loop bodies, the compiler should allocate a new copy on the heap for each loop iteration, but instead it only allocates one copy that's reused across all iterations.

Yes, absolutely. I dont use delegates much (well, I did in D1 but that is a long time ago), but the difference between point 3 and point 7 in the language reference is tricky to grasp. So if you bind a local function to a delegate parameter you dont take a closure, but if you assign to a delegate variable you get a closure?

"7. Delegates to non-static nested functions contain two pieces of data: the pointer to the stack frame of the lexically enclosing function (called the context pointer) and the address of the function."

May 18, 2021
On 5/18/21 3:04 PM, Ola Fosheim Grostad wrote:
> On Tuesday, 18 May 2021 at 18:51:40 UTC, Paul Backus wrote:
>> On Tuesday, 18 May 2021 at 17:53:20 UTC, Ola Fosheim Grostad wrote:
>>>
>>> Does a delegate do anything more than retaining a pointer to the stack record?
>>> Anyway, it should not escape the scope it references. So escape analysis is your friend.
>>
>> The compiler does escape analysis and pre-emptively allocates any variables that escape through closures on the GC heap.
>>
>> The bug here is that, for variables declared in loop bodies, the compiler *should* allocate a new copy on the heap for each loop iteration, but instead it only allocates one copy that's reused across all iterations.
> 
> Yes, absolutely. I dont use delegates much (well, I did in D1 but that is a long time ago), but the difference between point 3 and point 7 in the language reference is tricky to grasp. So if you bind a local function to a delegate parameter you dont take a closure, but if you assign to a delegate variable you get a closure?
> 
> "7. Delegates to non-static nested functions contain two pieces of data: the pointer to the stack frame of the lexically enclosing function (called the context pointer) and the address of the function."

There's also the issue that if you have a scoped variable that has a destructor, the value will be destroyed (and probably unusable) if you call the delegate from outside the scope.

-Steve
May 18, 2021
On Tuesday, 18 May 2021 at 19:20:55 UTC, Steven Schveighoffer wrote:
> On 5/18/21 3:04 PM, Ola Fosheim Grostad wrote:
> There's also the issue that if you have a scoped variable that has a destructor, the value will be destroyed (and probably unusable) if you call the delegate from outside the scope.

Ouch. Ok, so in OO languages like Simula, all scopes are heap-closures and there is no stack, which kinda changes the game. I guess Javascript does the same conceptually but the JIT perhaps extracts uncaptured variables and puts those on a stack as an optimization? (My guess)

But how does a function with a delegate parameter know if it is safe to store the delegate or not?


May 18, 2021

On Tuesday, 18 May 2021 at 17:53:20 UTC, Ola Fosheim Grostad wrote:

>

On Tuesday, 18 May 2021 at 17:40:17 UTC, Max Haughton wrote:

>

On Tuesday, 18 May 2021 at 16:47:03 UTC, deadalnix wrote:

>

Long story short: https://issues.dlang.org/show_bug.cgi?id=21929

Closure do not respect scope the way they should. Let's fix it.

Time to consider by-value captures? Closures (specifically the way they interact with the GC) seem problematic in general, not just here.

Does a delegate do anything more than retaining a pointer to the stack record?
Anyway, it should not escape the scope it references. So escape analysis is your friend.

Yes, they allocate the closure on head.

« First   ‹ Prev
1 2 3 4 5 6 7 8