Replies: 4 comments 2 replies
-
Is there any reason why we can't just go |
Beta Was this translation helpful? Give feedback.
-
@disruptek That basically sums it up. I think our conclusion also was that it is pretty much ok if CPS itself is a pain to use - the pain is felt by library implementors only, because end-users will typically not build on top of CPS directly. If this pain leads to greater control and flexibility, it should be worth it. |
Beta Was this translation helpful? Give feedback.
-
CPS can do the parentage dance itself; the dispatcher doesn't need to know about it. This is what you want as a library author because you cannot fathom the garbage your users will write, and you really have nothing to gain from trying to second-guess CPS when it comes to control-flow. That said, the dispatcher can perform parentage hackery via magic/voodoo, so it's just as accessible as ever. This feature necessarily starts with correctly handling the control-flow, then adds in return values, and finally ends with the shims for scoped resolution of the result. |
Beta Was this translation helpful? Give feedback.
-
For those who do not know what this is about: https://github.com/disruptek/cps/blob/master/stash/lua_coroutines.nim#L48 |
Beta Was this translation helpful? Give feedback.
-
Some definitions we should probably standardize on:
Consider Zevv's channels:
https://github.com/disruptek/cps/blob/master/stash/channels.nim
What he wants is to
...wherein
recv
is a CPS call.We talked about this (what else, it's all talk) and the general take-away is that we should be comfortable with bulking up the responsibilities of the dispatcher provided by the library author, but that the app author should still be able to use CPS without exposing the continuation in the procedure signature or environment.
To restate, CPS should, uh, continue to focus on the most rudimentary elements of control-flow and we can make the library author write
.cpsMagic
and such in order to access the variable predefined in the continuation type.The best (read: only) idea for doing this, so far, and without involving the dispatcher, is to have a
parent
continuation which we will resume when the current one is complete. CPS could probably manage this entirely, but if we instead push it into dispatcher-space, then that might be fine, too.Pushing it to the dispatcher means a little more boilerplate for the library author, because they need to handle the rendezvous themselves. Leaving it in CPS might mean less implicit overhead but more API surface because dispatchers need to know about unwinding the continuation stack.
@zevv is that about right?
Beta Was this translation helpful? Give feedback.
All reactions