related link

[John Nilsson]

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

> If you want to continue this discussion, please join the closures-dev
> mailing list.
>
done


> Inlining at compile-time only works for very restricted kinds of APIs,
> and excludes many interesting and useful APIs that could be written
> using transparent lambdas.  See, for example, my blog post on
> concurrent loops
> <
> http://gafter.blogspot.com/2006/10/concurrent-loops-using-java-closures.html
> >,
>

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) {}
}


> which has been implemented by Mark Mahieu
> <http://markmahieu.blogspot.com/2008/08/for-eachconcurrently.html>.
> That is just not possible with the approach you suggest.  Inlining
> also undermines binary compatibility, which is one of Java's
> strengths.
>
Hmm. I don't think I see the problem.


> FYI, experience with languages that support "non-local return" (Scala,
> Ruby, etc) has resulted in a remarkable absence of scary things
> happening.  They're really quite boring and ordinary once you try
> them.
>
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
> place to start would be Steele and Sussman's 1970's "Lambda the
> Ultimate..." papers
> <
> http://en.wikipedia.org/wiki/History_of_the_Scheme_programming_language#The_Lambda_Papers
> >.
>
Thanks for the pointer!

BR,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100208/b7483539/attachment.html