On 26 Jan 2005, at 11:48, Martin C. Martin wrote:
>
>
> Russel Winder wrote:
>> On Tue, 2005-01-25 at 15:51 -0500, Mike Spille wrote:
>> [ . . . ]
>>> If it were up to me, a closure in Groovy would look very much like a
>>> super-stripped-down anonymous inner class:
>>>
>>> 2.times (def() { println ($it);});
>>> c = def(params) { body };
>>>
>>> But it's pointless to argue this because I'll be voted down. So,
>>> like I said, I could live with:
>> Not necessarily.
>> Given that this example of closure syntax has been such a big issue, I
>> have been thinking about the syntax and my own reactions. I think I
>> am
>> changing my ideas about this. In particular I wonder if the syntax
>> for
>> a closure (which is after all an unnamed function definition) should
>> be
>> the same as a function. (OK very Algol68 and not very Ruby but then
>> this
>> is Groovy
>
> The simple and common uses of closures resemble statement blocks more
> than functions, and people relate to them that way. Compare:
>
> for (x in mylist) {
> println x
> }
>
> and
>
> mylist.each { x |
> println x
> }
>
> In fact, I suspect it's easier to explain a closure as a delta of a
> block than a function, because of the scoping rules: a closure is a
> block that returns a value, and where "return" plays the role of
> "break." The last one causes enough confusion to be in the FAQ.
Agreed.
> As for arguments: in a block, it's the enclosing context that
> introduces variables (e.g. x in the for loop above), whereas in
> closures, it's the closure syntax itself that introduces the variable.
> When the closure is only used once there's not a lot of difference.
>
> What about changing blocks to be closures? So that the two examples
> above compile to the same thing?
Agreed - I the semantics of the language should imply they're the same
thing, even if the implementation may decide to do different things in
the bytecode.
James
-------
http://radio.weblogs.com/0112098/