Consider finding a cooler name?

[tpetricek]

I suppose the code here is partly from my old FSharp.AsyncExtensions project and partly new stuff that has been added to FSharpX. That said, I don't think that either of these is a good brand for the new stand-alone project.

Although I used the "FSharp.XYZ" naming in the past, I think it is actually better to avoid that (as it incorrectly implies that a project is part of the core) and I feel that "FSharpX" is such a general collection of things that it does not give the project clear identity.

So, I was wondering if we could come up with a cooler name for this? (Especially now that it looks like there is a lot of activity here and this can become pretty useful component.) Unfortunately, I'm completely out of ideas when it comes to finding anything better! Any thoughts?

[rodrigovidal]

AsyncX?

[eulerfx]

HyperF? I used it for a repo which I don't maintain anymore.

[tpetricek]

The name could be somehow inspired by The Hollywood Principle "don't call us, we'll call you", which is what async is about :-)

[kasperhj]

FSharp.SugarLoaf is obviously the right choice here :) https://www.youtube.com/watch?v=St9Zy8PUhBc

[ToJans]

Fsharp.MoshiMoshi? :smile:

[dsyme]

I'd say that "AsyncSeq" needs to be isolated out as an independent package, whose name would logically be FSharp.Control.AsyncSeq, with nothing else in it except what's definitely needed to support that core type. Many emerging upstack libraries need to depend specifically on that component, which will need to be source + binary compatible. We won't be doing anyone any favours if we hide AsyncSeq in with a bunch of other functionality.

The rest of the things are less fundamental but note the existence of FSharp.Control.Reactive and please be careful about overlap with that. "Hollywood" sounds like a good name, so does "Sugarloaf", perhaps "Frankie" as in this song about reactive v. non-reactive programming :) However if you're going to use a name like that, please don't put "FSharp." on the front :) Putting "Fs" on the front is OK.

[dsyme]

That is, FSharp.Control.AsyncSeq should be considered part of the "core" set of FSharp.* types. It may need to be evolved over time w.r.t. performance (even occasionally breaking binary compat), but the basic abstraction should be something that upstak library authors build on with total confidence.

[forki]

I started by trying to extract only AsyncSeq from Fsharpx (see https://github.com/fsprojects/FSharpx.Async/commit/8e231c2ed96c3781bc9eb5446e3c10e400724b3e) and basically ended up with *Async* to make it compile.

[rikace]

I would like to move AsynSeq into the core.

FastFuture ? :)

[forki]

That's something that needs to be discussed with visualfsharp team. /cc @latkin On Mar 3, 2015 5:49 PM, "Riccardo" notifications@github.com wrote:

I would like to move AsynSeq into the core.

FastFuture ? :)

— Reply to this email directly or view it on GitHub https://github.com/fsprojects/FSharpx.Async/issues/17#issuecomment-76984107 .

[eulerfx]

WRT moving AsyncSeq out, a current implementation of AsyncSeq.groupBy and variants, as well as AsyncSeq.bufferByTimeAndCount and a few others have a few of dependencies that might be worth having on their own:

• IVar - this is much like the ResultCell in the core. It behaves much like TaskCompletionSource but designed specifically for Async. If AsyncSeq were part of the core it could just use ResultCell, but regardless, it would be nice to have this type exposed.
• Ch - a CML-style synchronous channel. This can be implemented using MailboxProcessor or directly as seen here. The only issue with MBP is that it requires disposal which can be inconvenient at times. A direct implementation can be slightly more efficient too.

[dsyme]

@eulerfx @forki - I think all those dependencies can be internalized. For example, the FSharp.Core implementation of Seq.groupBy and Seq.distinct use some internal types, which are better not exposed in order to achieve a cleaner, simpler, more stable API.

So I don't mind some internalized duplication if it gives us true independence and usability as a foundational building block.

@rikace - I see AsyncSeq as an optional core building block that is converging towards stability. When people need it, they should be able to build on it. The component may evolve further w.r.t. performance, or inspire new, similar components with different performance tradeoffs.

[eulerfx]

HollaBack https://www.youtube.com/watch?v=Kgjkth6BRRY

(You)ContinueMe https://www.youtube.com/watch?v=0GWFDYZi2hc

Suggestions without an accompanying YouTube video should be considered less seriously :)

[exercitusvir]

I don't like (meaningless) cool names. When I see FSharpx.Async I at least know what the library is about and I can probably remember its name. All these "cool" names that seem so common for new libraries are usually so meaningless that they defeat the purpose of names.