@dom96 > From what I can see you have effectively extracted the closure iterator code > from the compiler into a macro.
Well yes, except I haven't done it, but intend to do so :) > I don't think this invalidates your work, like I said above I think putting > this in a macro is a win anyway and would let us make the core language > smaller. As you noticed, my solution implies reimplementing a significant chunk of the compiler, so that alone is already questionable. I surely see potential benefits in it, as described above, but of course there are drawbacks too, such as functionality duplication and worse compile times. So it's tempting to reuse compiler-provided closureiters transformation here, like @PMunch suggests, if only we had more control over closure environments... > Btw I see your code generates objects which inherit from each other, doesn't > Nim require those are put on the heap? Inheritance on its own doesn't require the objects to be heap allocated. In my case I use inheritance merely to avoid code bloat, to define some primitives akin to `FutureBase`. @mratsim Heh, as always, I'll need some more time to study what you wrote :). @arnetheduck > lifetimes are awful If I remember correctly it's fixed in both chronos and lately asyncdispatch by nullifying the future (or reusing the future variable to be precise) after reading it. If cycles are still there, I believe they could easily be fixed by nullifying callbacks after fire. But TBH it's been a long time since I last looked at that code :) > lots of extraneous copying being done Right, that one was also on my list. In terms of closure iterator transformation it boils down to lambda-lifting optimization that would not lift a variable if it only is used in a single state. So not only it reduces the number of copies, but also leaves some stack variables on the stack, leading to better performance. But again, it's a relatively simple optimization which doesn't affect semantics in any way. > The last thing I'd really like to do is to force an annotation on anything > that goes into the closure Though does it have anything to do with closure iterators (and thus async functions)? They are kinda different from closures as their primary purpose is not to capture surrounding variables, but their owns :)
