Repository navigation
Naming notes #77
Description
Activity
Anyway, I just want to point out that the TaskSeq naming isn't perfect
Putting aside legacy, the ideal for naming and simplicity purposes would be
- Make F# Async properly fast by getting it implemented using state machines, supporting tailcalls etc.
- Call this library AsyncSeq and get it to support tailcalls (obviously deprecating the old AsyncSeq)
Then we'd be back to the nicest position that there is just
async { .. }andasyncSeq { ... }and both support implicit cancellation token passing.That makes me wonder if we should already be deprecating/renaming FSharp.Control.AsyncSeq to make room for this. Maybe renaming to
FSharp.Control.AsyncSeqSlowor something. Or maybe this library should be even bolder and simply re-implementasyncas well, leaving us in the nicest spot of all (apart from the really tricky question of tailcalls, which I think needs a language addition to help builders know when in tailcall position).I see your point, but I'm not sold on this. F# Core has two distinct builders, one for
taskand one forasync. The hot- vs cold-started, and resumable vs non-resumable, on top of the current discrepancy on tail-call recursion (async) and non tail-call recursion (task), at least for the foreseeable future allows for distinct use cases.People have come to associate
Asyncnaming with multi-threading and parallelization, whileTasknaming is mostly associated with fast, hot-started, non-parallelized, yet asynchronous scenarios.If we want to move forward to a single library approach for asynchronous sequences, it's likely that some of the current library functions of
AsyncSeqwill need to be dropped (I'd have to investigate, but I wouldn't be surprised if some functionality is currently not (easily?) possible with the resumable state machine approach).Also, since most F# programmers that I know have typically moved from
asyncbuilders totaskbuilders "everywhere", it seems to make sense to do the same here. I.e., in a single library approach, the main building block would beTaskSeq, notAsyncSeq, in analogy with F# tasks.I realize there's no perfect solution here. I can certainly see a use-case, and definitely until
TaskSeqhas gotten enough maturity, thatAsyncSeqshould continue to exist.Also, with 250k downloads of the latest version alone, and 1.4M in total, deprecating
AsyncSeqis sure going to annoy some people out there...people thinking this is about "sequences of tasks". I'm not sure what to do about this.
PS: yes, I can see this confusion. The reason I started all of this was that in my team people were literally writing code that had
List<Task<'T>>, which, when hot-started and with side-effects, is a recipe for disaster.This prompted me, among giving some education on
task(people really don't easily get hot-start vs delay/cold-start), to createTaskSeqbased on your code, to force people using this pattern instead.Which reminds me, I should probably remove functions like
TaskSeq.ofTaskList, as they allow people to use bad practices (I added them in as one could have a list of cold tasks, but it's too easy to confuse them, unless we expand this lib into a single lib that contains all of IcedTasks as well so we can turn this into aTaskSeq.ofColdTaskListor something, without adding a dependency)...Current F# AsyncSeq
Noticed something else:
AsyncSeqdoes not implementIAsyncEnumerable<'T>from the BCL. Probably because it simply didn't exist at the time:let x = asyncSeq { yield 1 } x :> IAsyncEnumerable<_> // not possible
We could also implement that interface, though it'll be confusing, as the internally used interface is same-named, they only differ in the naming of getting the enumerator:
GetAsyncEnumerator(CancellationToken)vsGetEnumerator().I know there's
AsyncSeq.toAsyncEnumandAsyncSeq.ofAsyncEnum, which were introduced for interoperating, but altogether it furthers my believe that it's probably better to continue on the path of using a different name altogether. Having twoAsyncSeqs in the wild that implement different interfaces may just add to the confusion.Not saying there isn't any confusion now. But I just think that having the two disparate yet seemingly equal worlds: tasks and asyncs in the F# ecosystem maybe the best of all the bad choices we have ;).
- locked and limited conversation to collaborators
on Oct 31, 2023 - pinned this issue
on Mar 18, 2024
I do notice the name "TaskSeq" is confusing some people - people thinking this is about "sequences of tasks". I'm not sure what to do about this.
While thinking about this I included some general notes on naming in this space, see below
F# IEnumerator
HotSynchronousFastEnumeratorIEnumerable<T>F# IEnumerable = Seq
ColdSynchronousFastEnumerableunit -> IEnumerable<T>.NET/F#/C# Task = C# async/await
HotAsynchronousFastValueTask<T>IcedTask ColdTask
ColdAsynchronousFastValueFactoryunit -> Task<T>IcedTask CancellableTask
ColdAsynchronousFastCancellableValueFactoryCancellationToken -> Task<T>Async = F# async
ColdAsynchronousCancellableValueFactoryCancellationToken -> Task<T>Current F# AsyncSeq
ColdAsynchronousCancellableEnumerableCancellationToken -> IAsyncEnumerator<T>Current F# TaskSeq
ColdAsynchronousHalfCancellableEnumerableCancellationToken -> IAsyncEnumerator<T>I'm leaving the question of tailcalls off the list, as much as I'd like to address that.
It's worth noting that at a high level there's no real logical difference between
CancellableTaskand F#Async<_>. Nor between F#TaskSeqand F#AsyncSeq.The sweet spot for F# is really Cold+RunMany+Asynchronous+Fast+Cancellable+Tailcalls, which is what TaskSeq is close to being technically (except tailcalls, sadly).