• Frank Benoit <keinfarbton googlemail.com> Nov 27 2007
• Michel Fortin <michel.fortin michelf.com> Nov 27 2007
• "Kris" <foo bar.com> Nov 27 2007
• Walter Bright <newshound1 digitalmars.com> Nov 27 2007
• bearophile <bearophileHUGS lycos.com> Nov 28 2007

Frank Benoit <keinfarbton googlemail.com> writes:

I often use local functions and lambdas. I also often pass their
address. And most of the time, i do this in environments, where i don't
want use heap allocations.

In my cases i know, that the function/method I call will not store the
delegate address for later use. It will use it immediately.

Is there a way to not heap allocate the stack frame?
Is there a language feature missing to tell this to the compiler?

For me, those local functions and lambdas are a really valueable and
perfomant language feature. With the implied heap allocation this
feature dies for me.

Not taking the address or not referencing local variable is not an
option for me.

Michel Fortin <michel.fortin michelf.com> writes:

On 2007-11-27 13:59:25 -0500, Frank Benoit <keinfarbton googlemail.com> said:

 I often use local functions and lambdas. I also often pass their
 address. And most of the time, i do this in environments, where i don't
 want use heap allocations.
 
 In my cases i know, that the function/method I call will not store the
 delegate address for later use. It will use it immediately.
 
 Is there a way to not heap allocate the stack frame?
 Is there a language feature missing to tell this to the compiler?
 
 For me, those local functions and lambdas are a really valueable and
 perfomant language feature. With the implied heap allocation this
 feature dies for me.
 
 Not taking the address or not referencing local variable is not an
 option for me.


Perhaps D needs "scope" inner functions.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

"Kris" <foo bar.com> writes:

"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:fiinll$1ju8$1 digitalmars.com...
 On 2007-11-27 13:59:25 -0500, Frank Benoit <keinfarbton googlemail.com> 
 said:

 I often use local functions and lambdas. I also often pass their
 address. And most of the time, i do this in environments, where i don't
 want use heap allocations.

 In my cases i know, that the function/method I call will not store the
 delegate address for later use. It will use it immediately.

 Is there a way to not heap allocate the stack frame?
 Is there a language feature missing to tell this to the compiler?

 For me, those local functions and lambdas are a really valueable and
 perfomant language feature. With the implied heap allocation this
 feature dies for me.

 Not taking the address or not referencing local variable is not an
 option for me.


 Perhaps D needs "scope" inner functions.



Seem reasonable that there should be some way (any kind of way) to tell the 
compiler "hey, I know what I'm doing here; step away from the heap!".  After 
all, heap allocation (and subsequent GC load) is one of the more expensive 
things a chunk of generic code can do. It's the#1 underlying cause for why 
many people feel Java is slow :p 

Walter Bright <newshound1 digitalmars.com> writes:

Frank Benoit wrote:
 I often use local functions and lambdas. I also often pass their
 address. And most of the time, i do this in environments, where i don't
 want use heap allocations.
 
 In my cases i know, that the function/method I call will not store the
 delegate address for later use. It will use it immediately.
 
 Is there a way to not heap allocate the stack frame?
 Is there a language feature missing to tell this to the compiler?
 
 For me, those local functions and lambdas are a really valueable and
 perfomant language feature. With the implied heap allocation this
 feature dies for me.



It's a significant problem. I hope to address it in the future by using 
'scope' to tag function parameters that do not escape, coupled with some 
interprocedural analysis.

bearophile <bearophileHUGS lycos.com> writes:

Walter Bright:
 It's a significant problem. I hope to address it in the future by using 
 'scope' to tag function parameters that do not escape, coupled with some 
 interprocedural analysis.


The closures for Java may give some ideas:
http://www.javac.info/

bearophile