Cloning coroutines

[simonbyrne]

A colleague recently requested the ability to clone coroutines. Is this something we can or want to support?

cc: @StefanKarpinski @vtjnash @yuyichao @one-more-minute @malmaud

[jakebolewski]

Can you outline your colleagues use case?

[simonbyrne]

From what I understand, they want to do something similar to this
http://arxiv.org/pdf/1403.0504.pdf

[jakebolewski]

Using fork to lazy evaluate infinite tree's is a bit crazy.

[StefanKarpinski]

Which is probably why they want to clone coroutines instead.

[vtjnash]

cloning a coroutine is fork. why aren't they just using a simple work queue with explicit state?

[simonbyrne]

@vtjnash They want to apply this to arbitrary programs, so were using coroutines to capture the state. But then they want to be able to fork at certain points in time and let both branches develop independently from then on (corresponding to the resampling step in SMC).

BTW If anyone wants to collaborate on this, I can put you in touch.

[vtjnash]

That sounds like they want a full implementation of process fork, not just the task state.

[StefanKarpinski]

The use case is somewhat irrelevant here. Is there any reason we can't have this feature? Cloning a coroutine strikes me as a useful operation, eg for implementing a backtracking algorithm. While there may be more efficient ways to do that on a case by case basis, why not allow this? The implementation seems to be as simple as copying a stack.

[vtjnash]

The use case is somewhat irrelevant here

au contraire, without a use case, it is a lot of work to add and maintain a feature that will always be suboptimal relative to using a closure or explicit work queue. I suspect this feature may interfere with stack-allocating objects, gc-frame elision, and other allocation-scope optimizations since it destroys the assumption that a stack frame is non re-entrant. Also, this does not strike me as a good way to implement backtracking, except as an academic exercise or toy demo.

[StefanKarpinski]

I suspect this feature may interfere with stack-allocating objects, gc-frame elision, and other allocation-scope optimizations since it destroys the assumption that a stack frame is non re-entrant.

Those are legitimate reasons not to implement this – the first ones presented so far.

[JeffBezanson]

dup of #4085

[malmaud]

@yebai It's better if you post in the open issue for this #4085 instead of commenting on closed issues.

For what it's worth though, I'm in Tenenbaum's lab and there are students here also interested in having this functionality for prob prog.