On Mon, Feb 8, 2010 at 8:03 PM, Neal Gafter <ne...@gafter.com> wrote:

done

A quick and dirty pretend syntax (didn't really spend too much time thinking about concurrency, but I'm assuming that any issues can be address within the macro construct).

I'm assuming some kind of name-mangling for the names introduced by the macro, except for the ones supplied by the caller which are simply inserted at the obvious places.

public macro <T> forEachConcurrently(T retT : Iterable<T> iter, ExecutorService threadPool) {void} block { final Collection<Callable<Object>> tasks = new ArrayList<Callable<Object>>(); final Collection<Future<Object>> futures = new ArrayList<Future<Object>(); for(final T t : iter) { tasks.add(Executors.callable(new Runnable(){public void run() { try { retT = t; block; } continue { //Noop } break { for(Future<Object> f : futures) f.cancel(); } return { for(Future<Object> f : futures) f.cancel(); } }})); } try { futures.addAll(threadPool.invokeAll(tasks)); } catch (InterruptedException ex) {} }

Hmm. I don't think I see the problem.

I guess you are right. But I still feel uneasy about it. The current closure semantics of java allows me to think (am I wrong?) that the stack frame and everything related to it will be completely forgotten once the method returns. What happens to stack frames to which we can return from closures that has been saved away? Is it saved away as a continuation? Are they garbage collected? Will lots of deeply nested calls pollute my heap if I don't allow the lambdas to get garbage collected? Do I need to worry about these things?

For writings about the expressive power of transparent lambdas, one

Thanks for the pointer!

BR, John