|
Jun 29
2008
|
The next big programming language feature after closuresPosted by Christopher Diggins in Programming Languages, Functional Programming, concurrency   |
 |
Closures are the current hot feature for programming languages. The inclusion of closures in Java appears to be around the corner, and the C++ committee has recently voted on closures in the upcoming C++ 0x standard.
The introduction of closures into many mainstream languages indicate to me that the logicial next big features is going to be primitive aggregate operations. Those are operations that operate on collections such as lists or arrays.
Closures, are anonymous functions created at run-time which can refer to variables that are visible where the function is declared.
Closures are especially useful when performing operations over elements in a collection. The most common collection operations (aggregate operations) in functional programming are map, filter, fold, and unfold operations.
A map operation transforms a list into a new same-sized list by applying a transformation function (such as a closure) to each element in the original list. A common example of a map operation is when performing a vector scaling operation.
A filter operation creates a list from another list using only those items for which a predicate function returns true.
The fold operation combines values in a list using a binary function and an initial value. A summation function is a simple example of a fold operation.
The unfold operation creates a list from an initial value and by successively applying a generator function, until a terimination predicate returns true.
The introduction of closures into C++ and Java make aggregate operations (operations that operate on collections) easier to write and will make their usage more frequent.
Aggregate operations like unfold, fold, filter, and "map" have the characteristic that they can be combined allowing significant reduction in the number of intermediate operations and data-structures created. This technique is called deforestation and is well-known when applied to pure functional programming languages such as Haskell.
In order for a C++ or Java compiler to take full-effect of deforestation, the compiler would need to know when a particular aggregate operation is occuring and whether or not there are side-effects. This is a very hard task for a compiler, unless the language has a predefined notion of aggregate operation.
Providing aggregate operations directly in programming languages have the additional advantage that it is easier for compilers to generate code that exploits multiple cores.
A testament of how effective aggregate operations is demonstrated by the success of the array-oriented languages APL, J, and K. These are usually implemented with interpreters which have excellent performance characteristics.
There are already some basic predefined operations on arrays in the Java virtual machine (JVM) and Common Intermediate Language (CIL) [Edit: replaced CLR with CIL, I meant to refer to .NET byte-code] for indexing and computing the size. The introduction of more sophisticated aggregate operations like map, filter, fold and unfold would be a logical extension to the CLR and the JVM. The performance benefits would not only be significant for single processors but there would also be benefit for code running on multiple processirs.
Subscribe to this comment's feed
Show/Hide comments
written by Frank Hileman, June 29, 2008
written by Jocelyn Paine, June 30, 2008
I always liked the ease with which Pop-11 gave us closures.
written by Nicolas Buduroi, June 30, 2008
using System;
namespace Test
{
using BigFunkyType =
Func;
class Test
{
public static void Main()
{
BigFunkyType compose = (f, g) => (x => f(g(x)));
int n = 3,
result = compose(x => x + 1,
x => x * 2)(n);
Console.WriteLine(result);
}
}
}
which print out 7.
written by Nicolas Buduroi, June 30, 2008
using System;
namespace Test
{
using BigFunkyType =
Func
class Test
{
public static void Main()
{
BigFunkyType compose = (f, g) => (x => f(g(x)));
int n = 3,
result = compose(x => x + 1,
x => x * 2)(n);
Console.WriteLine(result);
}
}
}
written by Nicolas Buduroi, June 30, 2008
A little help button somewhere would certainly... help.
written by Frank Hileman, June 30, 2008
A compose function would be a generic function taking two generic delegates (each with a type parameter), and returning a new delegate consisting of their composition.
You have to restrict each delegate to a certain number of parameters. C# is not as elegant as lisp and C# is probably not the correct language to use with these techniques. For example, look at this nastiness:
Func On(this Func f, Func g)
{
return t => g(f(t));
}
This is from the following post:
http://aabs.wordpress.com/2008...functions/
The beauty of functional composition is obscured by type parameters.
written by Frank Hileman, June 30, 2008
I won't try again, just go to the link to see the example. Anyone know how to get around the code posting problem?
written by Frank Hileman, June 30, 2008
I don't see C# morphing into a language that recognizes pure versus unpure easily; it is more likely we will use other languages to get these advantages.
Show/Hide comment form
In any case, are the proposed C++, Java closures to be "first class". I don't believe .Net closures (delegates) are first class, are they?
Bill