Delimited Generators – A more natural API for JS generators

They work really well for reusing encapsulated logic in predictable ways. If you yield generators from within generators, it’s very easy to anticipate the flow of how they will execute, even if it’s conditional. It’s also very easy to do it asynchronously.

Apart from that, you can write logic which is agnostic of the flow it’s in, which makes it so you can yield it from any flow as long as the logic suits it. This makes it so something like a request and retry flow can use the same generators as an exponential back off version of the same logic, or you could drop the retry generator into database access logic, file upload or retrieval, and so on. If the retry logic is generic enough, it’ll be totally reusable.

Another use case is creating enormous or potentially infinite data structures which you can easily read and even manipulate. You can generate a deck of cards with just the suits and ranks, for example. If you add orders of magnitude to that scale factor, it still works just as well.

You can also easily wrap generators in a class or otherwise to make the app-facing logic nicer to look at. For personal projects I don’t bother, but I’ve done this at various jobs where I knew a dead-simple wrapper would dramatically clean up and simplify working with the generator while providing the same capability. It really depends on how much or how little can be abstracted and if it’s worthwhile.

I know you could say “but I can do this with promises” or similar, and in some cases you can (definitely not massive or infinite data traversal), but the control of the flow with a generator is remarkably powerful. Sometimes that’s very useful.

I think the ball example (https://github.com/manuel/delimgen/blob/main/demo/balls.html) is maybe the most helpful to look at. It provides an abstraction over the wrapped generator which allows you to inject events into the generator. You could do this with generators alone, but this syntax lets you write it more like synchronous code (and has the added benefit of not being "coloured" by async/await). The `run` method essentially allows you to pass of handling of a continuous process so you don't need to worry about the orchestration of concurrent tasks. In this case, ball is able to move itself around the document as soon as it's yielded, and the implementation details of that behaviour are totally hidden from where the event is injected.

I'm still trying to wrap my head around how I'd use delimited continuation in more practical ways, so I might be misunderstanding quite badly. It seems to me that generators themselves are a form of continuation, and we often create delimited continuations when we implement programs with generators. In this case, the library essentially ties the loose ends by reifying the continuation as a function. In this case, the function is what provides the synchronous-like syntax as well.