Apple Blocks added to C++?

Reimer Behrends behrends at gmail.com
Thu Sep 3 02:04:06 PDT 2009


Walter Bright wrote:
> Nested functions do closures in a straightforward way, so by leaving off 
> nested functions they were forced to make an ugly syntax <g>. This is 
> why I shake my head in just not understanding the process that led to 
> their design.

That is because nested functions and block closures have different purposes.

Block closures avoid delocalization of code. For example, in Smalltalk, 
you could write something like the following to calculate the sum of the 
first 100 integers:

	s := 0.
	1 to: 100 do: [ :i | s := s + i ].


Packaging the 's := s + i' block inside a nested function instead would 
(aside from unnecessarily having to also pass 's' by reference or by 
value-result to the function) require you to move back and forth between 
the piece of code above and the nested function in order to comprehend 
it. More generally, it allows you to write custom control structures, 
such as map, fold, and filter to generate more compact an coherent code. 
This is especially prevalent in functional languages (Scheme, LISP, 
Haskell, the whole ML family) and Smalltalk or Ruby.

Research seems to indicate [1] that there is indeed a measurable 
readability benefit to this style of programming.

The benefit of nested functions is something different. In essence, a 
nested function allows you to share state with the parent function 
(absent shared state, there is little reason to not make the nested 
function a top-level function instead). However, nested functions are 
hidden inside their parent, which means that they are not reusable; on 
top of that, object-oriented languages already have means to share state 
between multiple methods (which is sometimes imperfect, but so are 
nested functions).

So, there are perfectly good reasons to have block closures, but not 
nested functions. Obviously, there are trade-offs, which may not appeal 
to everybody, but the design is still a rational one.


			Reimer Behrends


[1] http://infoscience.epfl.ch/record/138586



More information about the Digitalmars-d mailing list