Channels ▼

Christopher Diggins

Dr. Dobb's Bloggers

Old version - What's the next big feature after closures?

June 19, 2008

Everyone seems to be talking about closures nowaday. Inclusion of closures in the Java standard appears to be inevitable, and the C++ committee has recently voted on closures in the upcoming C++ 0x standard.

So what is going to be the next big feature for mainstream languages? I believe the answer is list-based primitive operations built into languages.

Closures, are anonymous functions created at run-time which can refer to variables that are visible from the declaration point. Closures can be emulated with some extra work in Java and C++ using local function objects.

Closures are particularly useful when performing operations over elements in a collection. The simplest collection operation is probably the "map" function which allows the creation of a new same-sized collection by applying a transformation function (e.g. a closure) to each element in the original collection, to get the corresponding element in the new collection.

Using closures the map function can be incredibly powerful, allowing us to perform very sophisticated calculations in a single line of code. This technique of programming has long been known to user of the Lisp programming language.

The problem though, is that the computing model used by languages like Java and especially C++ is too fine-grained. These languages require that programmers define precisely how the operations over collections are computed. In order for compilers to effectively perform the heavy lifting of optimizing code for multiple-cores, the most effective path is for languages to provide list-based primitives built-into the language. 

In order to illustrate this lets consider C++. The new closure syntax (which is  described in this post by Herb Sutter) is syntactic sugar for using function objects (functors).  

Now lets consider the example of scaling a vector. Using the new C++ syntax for closures we could write this as:

template<typename Iter_T>
void scale_vector(Iter_T begin, Iter_T end, double factor) {
  std::transform(begin, end, [factor](const double& x) { return x * factor; })};

This is nice compared to the original version of As a side note, the generic version still has as horrible syntax as ever:

template<typename Iter_T, typename Factor_T>
void scale_vector(Iter_T begin, Iter_T end, Factor_T factor) {
  std::transform(begin, end, [factor](decltype(*w.begin()) x)  {  return x })}

While the syntax is getting better, there is a fundamental problem with the scale_vector function: it is sequential. We are expressing a solution a common problem which may be acceptable for a sequential machine, but does not scale to multiple-core machines. This map function to a human observer has not order-dependance, but there is no way to express that while retaining the simplicity of the solution. Of course we can resort to using threads, but that wastes a programmer's time.

What I really want is an operation that is not order-dependent, and that scales well to multiple cores:

template<typename Iter_T, typename Functor_T>
transform_noorder(Iter_T begin, Iter_T end, Functor_T functor) ;

With a fair amount of  work a competent programmer could write a version of this function which is heavily optimized, portable, and that scaled well to multiple platforms.

The reason that we need array-based operations like this built directly into the language, rather than defined in a library, is that array-based operations can be combined and re-ordered by the compiler's optimizer for really interesting effects. A programmer can optimize one version of the function, but writing an entire library with a built-in optimizer, is not an easy task.  

These kinds of optimizations that apply to lists, and equivalently to tree structures, is known as deforestation and is well-known to the functional programming community. It is currently not possible in C++, Java, or C# for the compiler to perform deforestation because of the order-dependent nature of the primitives currently available. The problem is especially grave in C++ due to the low-level nature of memory access primitives. Java and C# however do have hopes to introduce collection-based primitives into the virtual machine and allowing compilers to leverage them effectively.


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.