Lazy eval -- an example issue

[Walter Bright]

kris wrote:
> Walter Bright wrote:
> 
>> I've been thinking a lot about the escape problem. I'm pretty sure that:
>>     char[] delegate() { return "foo"; }
>> can be detected and so I can assure you it won't cause the enclosing 
>> function's variables to be allocated on the heap.
> 
> And what about those cases where the expression is somewhat more 
> complex? Will you revert all this ambiguity when a bogus heap-frame is 
> demonstrated? One where the intent was never to create a delegate, but 
> simply to evaluate an argument expr instead? Or will you insist that a 
> smarter detector is the solution?

It's straightforward at one level - if a delegate does not reference any 
variables on the enclosing functions stack frame, there's no reason to 
allocate it on the heap. Something very similar is done now: variables 
referenced by nested functions are marked so they are not allocated into 
registers.

> One has to suspect that there are far more productive ways to take risks 
> with a language than this one:
> 
> # somefunk (++i);
> #
> # vs
> #
> # somefunk ({++i});
> 
> the latter is not only unambiguous, it even /looks/ like a delegate. The 
> former? Who knows what it does anymore

Without knowledge of what somefunc() does by looking at the declaration 
for it and the documentation, there's no way to know what it does 
anyway. If one does look at the function declaration, it's pretty 
obvious if it has a delegate parameter.

I expect function writers to use this in a way that makes sense, not in 
a way to pull the rug out from under client code. At some level, you 
have to trust them, with or without this feature. For example, doesn't 
it make sense that dotimes(int n, void delegate() exp) evaluates exp n 
times?