Tried and true co routine transform framework

1

Hi

I am looking around to start benefiting of Haxe compile time powers in the form of virtual coroutines.

In the past I was using jsawait/jsasync for javascript, was patching it with sync code for other targets, it was not the best, after all sync has its problems and most platforms support callbacks, but not all are supporting syntax level async functions, even javascript doesn’t yet have promises for everything.

I found GitHub - nadako/haxe-coroutines which seems to be very flexible with almost no special syntax rules, transformers are normal functions.
There is also pecan GitHub - Aurel300/pecan: Macro-based coroutines for Haxe with a nice website, and even goto support (from outside), it seems to be more constraining the syntax, and harder for spliting the code in multiple files.
There is GitHub - profound7/moon-core: moon-core library for haxe with @async and @yield, but requires everywhere.

GitHub - RealyUniqueName/Coro: Async/await, generators, and arbitrary coroutines for Haxe seems the most simple syntax, however requires compiler plugins which are not so standard (I d not know yet how to use it)

There is also GitHub - haxetink/tink_await: Haxe async/await that requires @await everywhere

Did I miss something?

Can anyone point out any of above, as a great or succesfull solution in general or in a specific domain?

I also understand that possibly some of these might be officially abandoned, superceded by something else and even the owner is using something else and do not even recommand anymore to use it.

1 Like
2

Looks like there is an active coroutine branch on the official Haxe: [work in progress] Coroutines for Haxe by Simn · Pull Request #11554 · HaxeFoundation/haxe · GitHub

It looks like @nadako is the person behind it so it would seem that starting with the first library you mentioned would be a good bet which would be officially supported in the future.

3

So far I see that @nadako s proposal is only POC, for example for in is still missing, and cannot be used as a value, I belive it was meant to show the idea in preperation to the built in fork.

For now I settled with pecan.

It required me to wrap all my utility functions in @:pecan.accept wrapper, but I preferred this over the others where I need to modify the calling site.

I’ve also found that the called functions must really be async functions, otherwise pecan will silently work out of order at runtime, there is a easy workaround, I see that @nadako already mentioned it in a github issue.

So regarding my title, tried and true, I’ve tried pecan and it was good for the job.

VSCODE is showing the code as this code has no effect, not sure exactly why.

4

I’m not entirely sure, but I think it’s because it moves the expressions into different place via a macro. I have the same issue in my library that does that (although in my case it moves the expression into entirely new type and the original module isn’t actually used).