After much pain, I've finally got nested closures working correctly. All nested closures share the outer-most method's cvars. Another thing I decided to do was treat closure parameters like other local variables such that they can't duplicate any other local variables within their scope.
brianTue 28 Nov 2006
Originally we had talked about using & as a "curry" operator, for example:
Void doSomething(Int a, Int b) {}
&doSomething
The above code would create a Method reference typed as |Int,Int->Void| as a convenient way to create callbacks. But after some thought, I'm thinking that this is already so easy to do with closures, that it isn't worth the complication (at least at this point in time):
|Int a, Int b| { doSomething(a, b) }
If there are no parameters then it is just an extra four characters, but duplicating all the parameters could be busy work. We'll have to see is future use cases really scream for the extra syntax sugar.
brian Sun 26 Nov 2006
After much pain, I've finally got nested closures working correctly. All nested closures share the outer-most method's cvars. Another thing I decided to do was treat closure parameters like other local variables such that they can't duplicate any other local variables within their scope.
brian Tue 28 Nov 2006
Originally we had talked about using & as a "curry" operator, for example:
Void doSomething(Int a, Int b) {} &doSomethingThe above code would create a Method reference typed as |Int,Int->Void| as a convenient way to create callbacks. But after some thought, I'm thinking that this is already so easy to do with closures, that it isn't worth the complication (at least at this point in time):
|Int a, Int b| { doSomething(a, b) }If there are no parameters then it is just an extra four characters, but duplicating all the parameters could be busy work. We'll have to see is future use cases really scream for the extra syntax sugar.