Interoperating with CancellableTasks

[dsyme]

While writing #77 I realised it would be logical to allow this TaskSeq thing to interoperate with a standard CancellableTask, that is

taskSeq {
    let! res = cancellableTask { ... }
    ...
}

which would pass the CancellationToken governing the iteration of the TaskSeq to the Cancellable task. This would give robust cancellation token passing through the overall computation.

Under the alternative long term strategy in #77 this would be the same as

asyncSeq {
    let! res = async2 { ... } // re-implemented F# async
    ...
}

because F# cancellableTask and async2 are more or less the same thing.

This would mean bringing a CancellableTask into this library from IcedTasks, which may be a good thing.

[abelbraaksma]

This would mean bringing a CancellableTask into this library from IcedTasks, which may be a good thing.

Hmm, yes. But then the top lib name of TaskSeq should be reconsidered, as the namespace will be hosting tasks and task sequences.

Maybe just FSharp.Control.Tasks and turn it into a collection of all of our wishlist in one place? I.e., cancellable task, parallel task and delayed tasks from IcedTasks and TaskSeq, perhaps later AsyncSeq as well? And then should we include the extremely useful FsToolkit taskResult and taskOption and the like?

Many questions and strategies possible... Though the idea of a "single stop shop" for all (or most) of task/async related stuff is appealing.

[dsyme]

Yes for the project and nuget something like FSharp.Control.TaskExtras may make sense

We can think it over a bit more but I guess it's OK to go for task/cancellableTask/taskSeq for now.

I'll think about whether it's possible to do an overall revamp for F#8, tailcalls etc too. If we did there would be no harm in a rename then.

[abelbraaksma]

@dsyme, see linked issue by @bartelink, #128. It's now a good time as any to discuss the scope of Task extensions and landing it. It appears that other libraries also yearn for a small, useful extension library.

Not exactly the same as what we discussed here, but this could be a precursor to unifying these efforts at some point.

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for raising this, @dsyme. Here is a current-state analysis:

Current status

The library now supports let! x = someTask inside taskSeq { }, so a CancellableTask (one that accepts a CancellationToken) can already be consumed with a small adaptor:

taskSeq {
    // manually pass the CT if you have it in scope
    let! res = cancellableTask { ... } someCancellationToken
    yield res
}

However there is no built-in mechanism to forward the sequence's own CancellationToken (the one passed to GetAsyncEnumerator) into a cancellableTask expression automatically.

What would it take?

To support let! res = cancellableTask { ... } with implicit CT forwarding, the taskSeq builder would need a Bind overload that:

1. Captures the CT stored in the builder's state at call time.
2. Invokes the CancellableTask with that CT.

The CT is currently accessible via CancellationToken.None in the enumerator, but there is no way for the CE to implicitly inject it without a dedicated overload.

Related

• The discussion in Add better support for cancellation tokens passing #133 on making CancellationToken-passing ergonomic is closely related — the consensus there is to add optional ?ct overloads to TaskSeq module functions. The CancellableTask interop here is a complementary angle for the CE itself.
• Bringing CancellableTask in from IcedTasks (as mentioned above) remains a possible longer-term direction, but would widen the scope considerably.

This is a tractable feature to add at the builder level; it just needs a design decision on naming and priority relative to other 0.6.x / vNext work.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f

[dsyme]

I'm closing as this library focuses on TaskSeq. There's IcedTasks for more