MacResearch

While not quite "anonymous functions", Python does support "lambdas":


def Caller():
const = 3.445
EvalFuncOnGrid(lambda x: 0.5 * const * x * x)


Yuck. The C syntax is understandably horrid. But the adding of closures to Objective-C should make us think about the other parent of the language: Smalltalk. It is desirable to make the language closer to Smalltalk than to C.

There are multiple things that this article slightly gets not quite right. Not that anything is strictly wrong (tho the term "block" is potentially misleading), it just seems to conflate a number of things.

My first issue is that the article conflates two or three issues: first-class functions, and closures, and possibly C lambdas.

First-class functions are functions that can be used as data, passed too functions as arguments, and returned from functions as values, and stored in variables. The ability to do this in the new system is convenient (more so than using function pointers) because of the flexibility that closures and lambdas provide.

Closures, which aren't related to first-class functions except only very tenuously, are functions that have variables bound outside the definition of the function, in the scope that they were defined in. These are already present in C, for instance any global function (all, prior to this, if I'm not mistaken), form a closure with all global variables. The benefit of closures comes from when you can define a variable in a non-global scope, and also define a function within that same scope, so that the function itself has access to that variable but nothing outside that scope has access. An example that makes this clear, using Python, might be this.

Closures are incredibly easy to construct if you're using a lexically scoped language, in which variables in a function body that are not formal parameters of the function are looked up by inspecting the environment in which the function was created. Dynamically scoped languages, however, have a much harder time creating closures, required special constructs for passing the variable bindings along with a function. Any lexically scoped language with both functions and variables outside the function that can be viewed from within the function (e.g. C prior to this modification, as noted earlier) technically has closures. Whether or not they're useful depends heavily on the ability to used functions as first-class objects, thus allowing the closure to be passed around with the function.

Finally, lambdas, are what make this possible in C. Without lambdas, you can still have closures, as in the def-ed Python examples, and in a fictional version of C that allows function definitions within other functions. Lambdas are convenient because they allow functions to exist without requiring that they have names, and making the definition itself an expression (whereas a function definition in C, being a statement, has no value). This makes it easy to create functions on the fly.

The ability to have closures in C, as demonstrated above, is currently more a result of lambdas, and to a lesser extent first-class functions, than anything else. As I noted, C already had closures, you just couldn't define functions anywhere other than in the global scope, and so only global variables could be closed over. The real innovation here is that functions can now be created within other functions, as this is what allows closures to have the really useful properties.

Some examples of things that can now be done in C, thanks to all of this, are class-like behavior without the shadey C-with-Classes methodology: A class can instead be defined as a closure-generating function, like so:

In your function body, declare and initiate private variables, and private functions. Then, return a struct with public variables, and public and private methods. The methods, being functions with closure over the private variables and functions, can still access those variables after the constructor function returns, but nothing else can access those variables and functions.

Also interesting is that along with first-class functions, these modifications to C provide the ability require certain types of first-class functions. In duck-typed languages, and with function pointers in C, you have no way of specifying the type of the function you want to have as an argument. So for example, from the above example, Python just has EvalFuncOnGrid(f) and the equivalent C function pointer version might be EvalFuncOnGrid(float* f), while the new version has EvalFuncOnGrid( float^(float) ). With the Python and C function pointer versions, any function can be passed, which makes it possible that you might not have the appropriate argument number, or return value. The new version is much more like Haskell's type system, where this EvalFuncOnGrid function would have the type (float -> float) -> nil or something similar. The type signature float -> float is a type signature for a function that takes a single float argument to float value. These new typed function arguments provide for some interesting, and confusing, type signatures, such as these ones in C:

void SomeFn( float^(float^(float^(float))) )
(its equivalent in Haskell being roughly (((float -> float) -> float) -> float) -> nil)

or

float^(float^(float^(float))) SomeFn()
(in Haskell: nil -> (((float -> float) -> float) -> float))

This is obviously an enormously confusing type signature, but it's not uncommon when dealing with higher order functions. Consider an imaginary function that, when given some function A, creates another function B that uses A to sort an array. This might have the type signature void^(void*) Sorter( void^(void*) ) (Haskell: (float -> float) -> (float -> float)). The C type system is now a whole lot more interesting. :)

Nobody seems to have mentioned the actual use of this new blocks-featurette.

I can tell you why Apple is going this route right now: Check out the 'Multicore' section of Apple's Snow Leopard preview page:

"Grand Central takes full advantage by making all of Mac OS X multicore aware and optimizing it for allocating tasks across multiple cores and processors."

Now substitute 'blocks' for 'tasks'. Yeah, like that. Neat, huh?

So, ultimately, you have a machine with n cores. You run a computation, but instead of putting code in a plain ol' C loop, you use blocks to implement the logic. You hand off that block either to something like a block-aware enumerator on an Objective-C object, or directly to the block dispatch routines of the Grand Central API. Now, because your loop code is block-based, Grand Central can run n loop iterations at a time — even when the blocks access local variables belonging to the function which defined the block. Because you're writing block-based code, you've arranged things such that each block is completely independent of those either side (otherwise, you're probably not suited to blocks).

Oh, and the best thing? Because Grand Central Dispatch is sitting on top of the mach thread/processor management APIs, once a block gets assigned to a processor/core it stays on that core, even when the current task/process is swapped out and back in by the mach task scheduler. That means that it is highly unlikely that the code within the block will ever need to touch main memory or swap data between each CPU core's level 1 caches. Which means that the code in the block can potentially run at the CPU/core's full processing speed, with no blocking for memory IO. It also means that performance will scale in a close-to-linear manner with the number of cores available, whereas currently as you add more cores, you get more overhead in synchronizing memory and cache access between all those cores. By separating everything and locking code blocks to a single specific core with its associated cache, Grand Central Dispatch can sidestep that problem really quite nicely.

To psygnisfive: can global functions accessing global variables really considered closures? could you clarify the behavior of this (assuming the following in defined in the global scope):

int some_global_var = 1;

void some_global_function ()
{
   printf("%d\n", some_global_var);
}

some_global_function();
some_global_var = 2;
some_global_function();

I thought closures meant that both calls would give the same output, and that the closures would somehow 'save' the values of higher scope variables at the point where the function is defined. But I believe the above will print 1 then print 2?

Sorry I have not had much formal education in programming, so I am just trying to make sure I understand these concepts :-)

Another interesting perspective is that of the Portable Object Compiler team. They have a paper on the topic of Objective-C Blocks penned in 1998 in which they go over the design and implementation of Smalltalk like blocks in their compiler. It's a really detailed and interesting perspective on how to add blocks to the language and get as close to Smalltalk blocks as possible without interfering with their C underpinnings.

______________________________________________

Christopher Roach
http://christopherroach.com