On 20 Oct 2009, at 07:37 , Stephen J. Turnbull wrote:
Nick Coghlan writes:
For myself, I don't actually agree it's a valid design rule - I think anonymous blocks have legitimate use cases (see Ars Technica's writeup of the Apple's new Grand Central Dispatch and C-level anonymous block system in OS X 10.6).
That doesn't look like what "anonymous block" means to me. It looks like a lambda.
An anonymous block and a lambda are the exact same thing.
The difference is that an block resolves all its non-argument references in the calling context Are you talking about forming closures here?
Now, the cases that Ruby programmers I know always propose to me as use cases for anonymous blocks rely on conventions for naming certain objects used by their blocks (typically iteration variables) Please forgive my disbelief but "what?" Ruby's blocks take arguments (they're fundamentally nothing more than anonymous functions), I've never encountered a case where "anonymous blocks [relied] on conventions for naming certain objects used within their blocks".
thus avoiding the need to specify arguments for them. See above. Some languages (Scala for instance) have "magical placeholders" to avoid having to name arguments (`_*3` is equivalent to `i => i*3`) but that's pretty much the extent of it.
So a block seems to be a conventional way of currying a more general function to the context of a specific suite. And I don't know what to make of that one either. Blocks don't have any more to do with currying than functions in general do.