Computational Theology Gilad Bracha's Sun Weblog

class ClosureTest {
    /** Implementing C#'s "using" construct */
    public static void using(Closeable clos, void() commands) {
        try {
            commands();
        } finally {
            try { clos.close(); } catch (IOException ex) {ex.printStackTrace();}
        }
    }
    
    public static void main(String[] args) {
        Connection conn = ...;
        using (conn) {
            RecordSet rset = ...;
            using (rset) {
                rset.next();
            }
        }
    }
}

/**
 * Alias for a function type for methods that
 * receive a single double parameter and returns
 * a double
 */
public alias double(double) function; 

Posted by Edson Watanabe on August 18, 2006 at 01:57 PM PDT #

Posted by Jerry Boetje on August 18, 2006 at 02:54 PM PDT #

Yes! Closures are a wonderful thing. But so is call/cc. With call/cc one can program in comfortably in a procedural or functional style and be able to write event-driven code without having to turn one's code into spaghetti.

Check out OKWS, libasync for a taste of what resourceful people do with C++ to get closures and write event-driven applications in C++ in continuation passing style... No call/cc there...

Here's a question though: how does one make closures thread-safe? By making captured variables read-only?

Posted by Nico on August 18, 2006 at 06:01 PM PDT #

Posted by kishore on August 20, 2006 at 01:40 AM PDT #

Posted by Daniel Yokomizo on August 21, 2006 at 05:55 AM PDT #

Not quite. Since you mention C, for a flavour check out the GNU C extensions, specifically nested functions, and labels as values.

Specifically a closure is a really a {pointer to function, pointer to captured variables} tuple. The captured variables should be part of what you think of as the function call frame on the stack, so really this is {pointer to function, frame pointer}. GNU C nested functions do that, but the compiler/runtime constructs a function on the stack so as to not have to pass the frame pointer explicitly with the function pointer. Of course, these things can go out of dynamic scope! LISP closures, Perl5 closures, etc... can't go out of scope because they captured variables are on the heap, rather than on the stack. A program might consist entirely of heap-stored call frames, and some Schemes, etcetera are indeed implemented this way. See call-with-current-continuation (or "call/cc").

Also, think callbacks, on steroids.

Posted by Nico on August 21, 2006 at 03:00 PM PDT #

Posted by Gilad Bracha on August 21, 2006 at 05:48 PM PDT #

Posted by Karsten Wagner on August 22, 2006 at 06:40 PM PDT #

I am in the camp that thinks inner classes are a superior concept. There advantages are:

• You have one concept; a class
• You can extend abstract classes, i.e. partial implementations, as well as interfaces
• You can pass multiple methods and state as one object

Therefore I have logged a request for an enhancement to Java for shorter syntax for common operations. One of these common operations is anonaymous inner classes. Which as many people have pointed out have much in common with closures and first class functions. The aim of the proposed syntax changes are to remain backwards compatible with existing Java and provide a natural progression towards shorter syntax.

You can vote for and see detail of the proposal at:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6389769

The example from Neil's blog:

public static void main(String[] args) {
     int plus2(int x) { return x+2; }
     int(int) plus2b = plus2;
     System.out.println(plus2b(2));
 }

public static void main(String[] args) {
     var plus2b = Object() int e(int x) return x+2;
     System.out.println(plus2b.e(2));
 }

Which seems competative in terms of syntax and is a much less radical proposal and yet also has many other usage examples, including every variable delaration! Another example is, closure, instead of the current:

textField.addActionListner( new ActionListener() {
    public void actionPerformed( ActionEvent notUsed ) {
        textArea.append( textField.getText() );
    }
});

You could write with my proposal:

textField.addActionListner( ActionListener() ( notUsed ) textArea.append( textField.getText() ); );

Posted by Howard Lovatt on August 23, 2006 at 12:15 AM PDT #

Posted by Euxx on August 23, 2006 at 08:40 AM PDT #