"heap" syntax

[Johan Granberg]

Russ Lewis wrote:
> * You can't detect if the delegate will outlive the function that 
> created it (the Halting Problem bites you, even if you have access to 
> all of the source).
Ok thats bad it rules out possible optimization and it become a question 
of of how efficient the delegates is going to bee.

If the copy performance is bad maybe an explicit syntax is needed (i 
would propose the extra syntax is applied to the delegate instead of the 
data thou (bad example: have two types delegate and copying_delegate) as 
data can come from many different places but the function or literal is 
only made into a delegate once)

Other idea:

void foo(){}
auto a=&foo;//works like now
auto b=@foo;//creates a heap copy of all variable the delegate uses (and 
each delegate gets its own instance (in the case of references it is of 
course the references that is copied not the data))


> * It is sometimes ambiguous whether a given delegate wants a copy of the 
> stack variables, or the original.  Consider this snippet:
 >
> ...
>
> Now, in the code above, is each delegate supposed to get its own copy of 
> i?  Or do they share it?
My proposal was that every delegate got its own copy. (it still may bee 
a bad proposal)

> I'm in favor of an explicit syntax because it explicitly makes clear 
> what the programmer intended to happen.
I also like explicit syntax until i tried to program in sml. If you 
haven't used sml try it I became a much better programmer only by using 
it a few weeks at a university course.

/Johan