pecan vs nadakoroutines

[nadako]

since pecan is the currently the most promising macro implementation for coroutines and its idea is pretty close to what we have in mind in this proposal, we can use it (or its fork) as a proving ground before moving the implementation into the compiler.

here I outline the current key differences between pecan and the proposed design (calling it nadakoroutines for brevity):

starting

pecan

• coroutine "function references" are actually instances of macro-generated CoroutineFactory classes
• CoroutineFactory instances have run method that receives arguments and return an ICo instance

nadakoroutines

• suspend function references are of Suspend<TFunc> type
• Suspend<TFunc> have start method that receives arguments and continuation and has Void return type

suspending

pecan

• every coroutine has "magic" methods for use within coroutine, like "suspend", "terminate", "yield", "accept", etc.
• starting the coroutine returns the coroutine instance (ICo) which can be passed around and provides methods for suspending, resuming and terminating the coroutine
• calling methods marked with @:pecan.action or @:pecan.accept will automatically pass coroutine instance (ICo) as an argument to those methods, allowing for the same control as in the previous variant

nadakoroutines

• there's no direct access to coroutine, coroutines are automatically suspended when another coroutine is called
• there's a "magic fake coroutine" method in the stdlib called suspendCoroutine that can be called to explicitly suspend the current coroutine. this method receives a function to be called immediately after the coroutine is suspended and this function receives the continuation for resuming the coroutine

resuming

pecan

• resuming is normally done using coroutine instance (ICo) methods, like tick, give, take, etc.
• @:pecan.accept methods receive a "return value" callback, calling it will automatically resume the coroutine and give the value to it

nadakoroutines

• coroutines are resumed when their continuations are invoked. normally this is done implicitly by inner coroutines, however in case of suspendCoroutine, the continuation is exposed to the function given to it and must be explicitly called

passing values

pecan

• coroutines have access to accept() and yield() "magic" methods to receive or give values to the outside world. the outside world operates through ICo which has corresponding give and take methods
• @:pecan.action methods can take any arguments
• @:pecan.accept methods can take any arguments and return the value back to coroutine with a special callback

nadakoroutines

• coroutines pass arguments and return values to each other like normal functions
• communication to the outside world is done via continuations:
  • coroutine's start method receives a continuation along with the other arguments, this continuation will be invoked when the coroutine terminates, passing the return value to the outside world
  • the magic suspendCoroutine method receives a continuation that is used to both resume the coroutine and pass the "accepted" result to it

extra features

pecan

• has built-in labels+goto support :)

[francescoagati]

hi @nadako,
another important feaure for coroutine shoud be serialization in this mode a coroutine can be saved and restored

[nadako]

I have to think how coroutines play with serialization. I don't think you can serialize coroutines in general, since there are function pointers binding them together and such and I'm not even sure that's something that should be supported by the coroutine mechanism itself rather than a framework on top, but we should look into enabling such frameworks to do that, yeah :)

[francescoagati]

some language and framework like racket(scheme) and seaside/smalltalk support continuation serialization

https://docs.racket-lang.org/web-server/stateless.html#%28part._.Serializable_.Continuations%29
https://defn.io/2019/04/07/web-continuations/

[francescoagati]

in general the serialization isn't for the pointer functions but only for the internal data

[nadako]

I made a separate issue here #16

[nadako]

I'm going to close this as it's not really an actionable issue. There's an experimental branch now here HaxeFoundation/haxe#10128 where we can discuss and refine API.