What project name should we use?

[forki]

Hi,

I extracted all the collectections (including FSharpx.Collections.Experimental) from fsharpx and put them into this project.
I think it hsould be as easy as possible to use them and a dependency on FSharpx (the whole project) is often a big no-no.

This project has already > 1700 unit tests and some API documentation (will add FSharp.Formatting build task).

But what name/namespace should it get?

Here are some ideas:

• fsharp/Fsharpx.Collections
• fsharp/Fsharp.Collections
• fsharp/Fsharp.Data.Collections
• forki/Fsharpx.Collections
• ??

// cc @dsyme @ovatsus @mausch @tpetricek @mausch @jackfoxy @panesofglass

[tpetricek]

I'd vote for:

• fsprojects/FSharpx.Collections or
• fsprojects/FSharp.Collections

... depending on whether you want to use the FSharpX brand or not (both options sound good to me). Once it has documentation, we can move it to fsharp/???.Collections.

[ovatsus]

I'd vote for FSharp.Collections. Would also be good to merge the collections from ExtCore into the same project

[forki]

Actually I'm not even sure if we should keep the f# in the name since (like deedle) they are also optimized for C#.

[forki]

+1 for merging with the extcore collections and picking whatever is faster

[forki]

// cc @jack-pappas

[tpetricek]

+1 for looking at ExtCore
+1 for thinking about alternative non-FSharp namespace to encourage C# users (but finding a nice name is hard!) - even that can still live happily in fsprojects and later fsharp though

[ovatsus]

Somewhat off-topic, what do you think about considering the x in FSharpx to mean experimental and treat it as an incubation project?

I think we should do the same with @tpetricek async extensions, which were originally a separate project, and are now both in fsharpx and extcore, they should be in its own package FSharp.AsyncExtensions ( I'm refering to the AsyncSeq + extensions to add Async variants to .Net streams, etc., and the several agents).

[forki]

what do you think about considering the x in FSharpx to mean experimental and treat it as an incubation project?

That's how I see it.

[panesofglass]

That all sounds good to me. You will note that I also tried to start doing this with the CE's. I think those should also be in a separate project, possibly even a project for each.

[ghost]

Good to see this.

I'm not too keen on FSharp.Collections, since it squats on a two-word DLL name that's very important.

Recall the guidelines discussed on the "coreeng" working group - choose a name which is unlikely to conflict with other future incubations and canonical libraries.

[forki]

Actually I would like to have something like Immutable.Collections, but that's taken by MS

Any other ideas?

[jackfoxy]

I think this should be an interim step until FSharpx.Collections and ExtCore.Collections can be merged into a top-tier library (FBase.Collections?) I would caution against mixing the current FSharpx.Collections and FSharpx.Collections.Experimental. The experimental really are "experimental", and with the exception of 2 or 3 that should be cleaned-up for "FBase.Collections", most should never be in a top-tier library.

I also like the idea of naming a separate sub-namespace for any mutable collections (FBase.Collections.Mutable?). F# collections should be assumed immutable unless otherwise specified.

+1 for the remainder of FSharpx becoming an experimental library, perhaps in the github.com/fsprojects space.

[mausch]

For a name that doesn't include "FSharp", maybe consider something around "persistent collections". (are all of the collections here immutable and persistent?)

-1 for considering the "x" in FSharpx as "experimental", that was never the intention of the project's name.

[forki]

-1 for considering the "x" in FSharpx as "experimental", that was never the intention of the project's name.

I know, but I think we have to extract everything that's not really core. Atm there is a lot of stuff in it.

[forki]

fsharp/FSharp.PersistentCollections?

[mausch]

-1 for considering the "x" in FSharpx as "experimental", that was never the intention of the project's name.

I know, but I think we have to extract everything that's not really core. Atm there is a lot of stuff in it.

That's ok... what I didn't like is the change in the meaning of the project name.

[ghost]

We've been reviewing the ExtCore and FSharpx space recently. Obviously collections tend to dominate though there is other stuff too.

After doing this I'm unconvinced of the "canonicity" of any set of batteries-included functional collections. That is, I'm not yet convinced that there is one canonical view on the right set of battries-included collections that balances the various criteria. There are many variations on existing collections too (LongMap, index-tagged collections, various trees, hash v. compare etc.)

So the quesiton is not really utility - it's canonicity.

Because of this one I'd say we probably still need a code name in the DLL/project name. Something like this:

MojoCollections.*

Re the FSharp.Collections.* namespace: we could perhaps select 3-5 of them over time, but I'd want to hear more stories about them being useful in production code. The FSharp.* namespace is a precious resource.

And also a design review, e.g.

• don't use the name Vector which is far too likely to collide with math libraries.
• don't put anything directly under the primary namespace (e.g. put things under MojoCollections.Immutable rather than MojoCollections). I see a consistent tendency for "batteries included" libraries using namespace paths that are just one name too short.

[forki]

I started to add performance tests:

• http://forki.github.io/FSharpx.Collections/PersistentHashMap.html
• http://forki.github.io/FSharpx.Collections/PersistentVector.html

[jack-pappas]

Hi @forki, thanks for cc'ing me. I've been really busy this week, so this is the first chance I've had to read through the discussion and think it all over. It seems like there are multiple topics being discussed here -- why don't we move this conversation over to fsharp-opensource or coreeng-wg? I'd like to address a few of the points raised above, some of which are relevant not only to this specific project but to the whole F# ecosystem, and I think the mailing lists are better suited for that kind of discussion.

[jackfoxy]

I'm posting a message to coreeng-wg tonight that covers this and other related threads I've been intending to comment on. Anyone interested who is not on that mailing list let me know.

[mausch]

Hi, what's coreeng-wg? Is it a new mailing list? Can't seem to find it on google groups.

[jackfoxy]

It's the core-engineering working group in fsharp.org. You can register as a "founder" and then request membership in the working group. Here's the full text of the message I just sent:

This is my answer to several threads about collection libraries across GitHub issues, the Google F# group, and Core Engineering mailing list.

I haven't studied the Basis.Core or FSharp.Enterprise libraries yet, and my knowledge of ExtCore is not deep. My comments below are mostly about the linear and map-like collections in FSharpx, ExtCore, and PowerPack.

1. I don't think any other functional data structures are canonical in the way List and Map are canonical. All other linear and map-like functional data structures are useful in that they make up for performance shortfalls in specific use cases.

2. Alternate functional linear data structures enable functional solutions otherwise not practical with List alone. These possibilities are not well known in part because these structures are usually not in a high-profile library, and the literature usually treats them individually, rather than as different facets of the same sequence structure. For these reasons most people overlook supplemental linear data structures as a functional programming alternative.

3. This is a small thing, but it is another small thing F# can do better than libraries in the other languages. Supplementary (non-canonical) collection data structures should have a prominent (first-class) library or other "targeted mega-package".

4. A semantically coherent API across all linear structures in the F# library enhances its usefulness and the ability for newcomers to learn the structures' underlying unity and uses. (head, tail, last, initial, cons, snoc or conj, append, etc.) A similar unity of the map-like API is desirable.

5. I'm conflicted about using the name "conj" for adding a single element at the end of a sequence. Perhaps "snoc" is better. Now is the time to change it if there is consensus one way or the other.

6. I want to change the name "Heap" to "OrderedQueue" and retain aliases of "Heap" and "PriorityQueue". "OrderedQueue" is more descriptive for newcomers who may have never heard of "Heap" or "PriorityQueue".

7. So far the naming standard within FSharpx has reserved "List" in a name for "list-like" linear structures that provide for single element construction and deconstruction at the beginning of the sequence (head, tail, cons). I think this contributes to the semantic coherence of the library. The exception is FlatList (which is in the experimental collection, not the main collection).

8. ExtCore.Vector appears to be similar to FX.Experimental.FlatList, with additional functionality like Parallel. So I think it may be the better alternative to carry forward, after reviewing linear data structure naming coherence. And Don has requested we not reuse "Vector", so it needs a name. I would prefer to NOT use "List" in the name for the reasons I outlined in (7). (FlatArray?)

9. FSharpx.Vector also needs a new name. "PersistentVector" is too long. Some synonyms for "List" I found (don't really like any of them): catalogue, roster, series.

10. Remaining overlap among linear structures between ExtCore and FX: ExtCore.Queue / FSharpx.DList (the ExtCore.Queue signature is closer to DList than FSharpx.Queue) and LazyList (which also has an implementation in PowerPack). The Queue/DList performance comparison should be fairly straight forward. I think figuring out which LazyList performs better is a lot trickier, and maybe static code analysis is more appropriate.

11. Overlap among map-like structures: FSharpx.Experimental.IntMap (needs clean-up) and ExtCore.IntMap. New PersistentHashMap by @forki and ExtCore.HashMap.

12. I haven't looked at ExtCore.FSharpBimap and ExtCore.IntBimap yet, so I'm not sure what they do.

13. PowerPack.HashMultimap is sui generis, mutable, and I think worthwhile to carry forward.

14. I support maintaining a sub-namespace for mutable collections. A first class F# collections namespace should be purely functional by default.

15. FSharpx.CircularBuffer is a mutable structure (as is RingBuffer in FX.Experimental). I think it is worthwhile to carry forward. (It would be an interesting exercise to create an immutable circular collection, but I'm aware of no demand for it right now. I would consider such a structure to belong to the family of linear data structures and should follow the linear API conventions.)

16. What is the place of extension methods? I'm inclined to recommend carrying forward existing and new extensions in a new library/package/namespace.

17. Benchmarking. I've dusted-off DS_Benchmark, https://github.com/jackfoxy/DS_Benchmark. It supports benchmarking about 50 different collections across FSharp.Core, FSharpx, PowerPack, ExtCore, System.Collections, System.Collections.Immutable, and Solid. It's well documented, but it was the first non-trivial thing I wrote in F# and has many faults. It could use integration with PerfUtil, https://github.com/eiriktsarpalis/PerfUtil, to capture GC deltas.

I should have some benchmarks ready in a few days.

[mausch]

Is this mailing list public? Where can I browse its messages? Thanks.

[jackfoxy]

No, it's private.

[mausch]

Is there any particular reason why it's private? Would the managers consider making it public? As described in "Producing Open Source Software", it's a huge mistake to discuss open source software development in private.
I apologize for this off-topic, if necessary we can take this discussion to some mailing list.
Cheers

[jackfoxy]

It's not specific to any particular OS project. The fsharp.org working groups stratagize about many things regarding the direction of F#, including what kind of projects should be under github/fsharp (which is "owned" by the F# Foundation). So it's more than just talking about any particular OS project, but the direction of the F# eco-system. It's not a Cabal. http://fsharp.org/foundation.html I'm actually surprised you aren't involved.

[ovatsus]

I agree with @mausch that we should keep the discussion on github if it started here, so everybody can follow along. That mailing list is not public, has no archiving like the f# open source google group, and is not easily linkable like a github issue. Actually I find github issues have several advantages over mailing lists for these kind of discussions

[jackfoxy]

I think this naming issue has been settled.