It does, the second section tries to address this area. But there, it depends on what are the primitives you work with. If these are callbacks, then I think you can't really talk about structured concurrency.
If you are working with Futures/Promises, then a function which returns a promise will satisfy the structured concurrency requirements, if after the promise completes, there are no other "dangling" promises waiting to be completed, "escaping" the scope of the creating function (which is now fully complete - taking into account the promise that it returned).
It is a Task based on continuations, that is merely a description of an async computation. However, when I actually invoke it, the async effect is unleashed and I am not in the pure realm of my application anymore. Why would I bother keeping it structural concurrent if I am already in an impure context?
This seems to be an interesting idea but I quite don't get it yet.
I think purity isn't a binary property but can be considered in multiple contexts. Do you write to disk? Do you do network I/O? Do you print to the console? Do you rely on system time? Do you read env configuration? And finally - do you spawn threads?
Running an async Task might have side effects, but it's one thing if you know that once the task completes (you usually can schedule a callback or a subsequent computation when that happens) that some logging will happen, or that a network request will be sent (and complete!); it's another to have a runaway computation running concurrently, even though the calling one completed. That's the guarantee that structured concurrency can give you.
It does, the second section tries to address this area. But there, it depends on what are the primitives you work with. If these are callbacks, then I think you can't really talk about structured concurrency.
If you are working with
Futures/Promises, then a function which returns a promise will satisfy the structured concurrency requirements, if after the promise completes, there are no other "dangling" promises waiting to be completed, "escaping" the scope of the creating function (which is now fully complete - taking into account the promise that it returned).It is a
Taskbased on continuations, that is merely a description of an async computation. However, when I actually invoke it, the async effect is unleashed and I am not in the pure realm of my application anymore. Why would I bother keeping it structural concurrent if I am already in an impure context?This seems to be an interesting idea but I quite don't get it yet.
I think purity isn't a binary property but can be considered in multiple contexts. Do you write to disk? Do you do network I/O? Do you print to the console? Do you rely on system time? Do you read env configuration? And finally - do you spawn threads?
Running an async
Taskmight have side effects, but it's one thing if you know that once the task completes (you usually can schedule a callback or a subsequent computation when that happens) that some logging will happen, or that a network request will be sent (and complete!); it's another to have a runaway computation running concurrently, even though the calling one completed. That's the guarantee that structured concurrency can give you.Agreed. Thanks for taking the time!