Per, thanks for your input.

Per Bothner <xxxxxx@bothner.com> schrieb am Sa., 30. Sep. 2017 um 07:58 Uhr:
It's not required, but I think it would be a good idea to mention the issues with efficient implementation
in a multi-threaded environment.  As far as I can tell the reference implementation doesn't
help much in that respect.

SRFI 154 can be implemented as a light-weight layer upon already existing infrastructure that deals with call/cc and dynamic-wind (the reference implementation does this for Chibi). In other words, implementing SRFI 154 is no more costly than implementing dynamic-wind, which is already mandated by the RnRS. (The semantics of dynamic-wind in multi-threaded environments are defined by SRFI 18. A note on how to implement that efficiently would belong to SRFI 18, I would think.)
 
I think it is unlikely Kawa will support either 154 or 155 in the foreseeable future,
because it uses "native" ThreadLocal objects, and that may be more valuable than the
arguable-cleaner semantics of these SRFIs.  (That may change if I see actual code, of course.)

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?
 
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 am asking because we are also still waiting for TCO in Java, aren't we?
 
Marc

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