On 09/30/2017 12:39 AM, Marc Nieper-Wißkirchen wrote:

> How do you deal with call/cc (as far it can be supported by Kawa)? Every continuation created by call/cc needs to save its current map of parameter bindings, so how can this be done without copying?

Normal Kawa only supports call/cc for exits/returns.  When it isn't inlined by the compiler, it is implemented
by throwing a special exception.  When the exception passes through a 'parameterize' the latter's exception
or finally handler will revert the parameter binding.

Andrea Bernardini implemented full call/cc support as a Google Summer of Code project in 2015.
It is in Kawa's 'callcc' branch.  It has not been merged.  It is inherently expensive, though
I believe some optimization are possible.

>     If Project Loom (http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html) becomes
>     part of Java, then it would be reasonable to revisit this.
>
>
> That's in interesting project! Do you have an estimate how it will take to become a part of Java?

I have no idea.  It could be a decade or never.  It could be much sooner.  It depends on how
much support it gets by people like John Rose at Oracle.

> I am asking because we are also still waiting for TCO in Java, aren't we?

Yes.  Though Kawa's implementation of tail-calls (using a trampoline when it can't be optimized away)
isn't too bad.

A major feature of Kawa 3.0 is a re-write of the calling convention used (when not calling a known
function), to use Java 7 MethodHandle objects.  I think this helps with tail-calls, though I haven't
done as much measuring as I should.

--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/