Comments (28)
+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
from fsharpx.collections.
I'd vote for:
fsprojects/FSharpx.Collections
orfsprojects/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
.
from fsharpx.collections.
I'd vote for FSharp.Collections. Would also be good to merge the collections from ExtCore into the same project
from fsharpx.collections.
Actually I'm not even sure if we should keep the f# in the name since (like deedle) they are also optimized for C#.
from fsharpx.collections.
+1 for merging with the extcore collections and picking whatever is faster
from fsharpx.collections.
// cc @jack-pappas
from fsharpx.collections.
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).
from fsharpx.collections.
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.
from fsharpx.collections.
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.
from fsharpx.collections.
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.
from fsharpx.collections.
Actually I would like to have something like Immutable.Collections, but that's taken by MS
Any other ideas?
from fsharpx.collections.
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.
from fsharpx.collections.
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.
from fsharpx.collections.
-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.
from fsharpx.collections.
fsharp/FSharp.PersistentCollections?
from fsharpx.collections.
-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.
from fsharpx.collections.
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.
from fsharpx.collections.
I started to add performance tests:
- http://forki.github.io/FSharpx.Collections/PersistentHashMap.html
- http://forki.github.io/FSharpx.Collections/PersistentVector.html
from fsharpx.collections.
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.
from fsharpx.collections.
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.
from fsharpx.collections.
Hi, what's coreeng-wg
? Is it a new mailing list? Can't seem to find it on google groups.
from fsharpx.collections.
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.
-
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.
-
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.
-
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".
-
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.
-
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.
-
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".
-
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).
-
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?)
-
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.
-
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.
-
Overlap among map-like structures: FSharpx.Experimental.IntMap (needs clean-up) and ExtCore.IntMap. New PersistentHashMap by @forki and ExtCore.HashMap.
-
I haven't looked at ExtCore.FSharpBimap and ExtCore.IntBimap yet, so I'm not sure what they do.
-
PowerPack.HashMultimap is sui generis, mutable, and I think worthwhile to carry forward.
-
I support maintaining a sub-namespace for mutable collections. A first class F# collections namespace should be purely functional by default.
-
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.)
-
What is the place of extension methods? I'm inclined to recommend carrying forward existing and new extensions in a new library/package/namespace.
-
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.
from fsharpx.collections.
Is this mailing list public? Where can I browse its messages? Thanks.
from fsharpx.collections.
No, it's private.
from fsharpx.collections.
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
from fsharpx.collections.
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.
from fsharpx.collections.
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
from fsharpx.collections.
I think this naming issue has been settled.
from fsharpx.collections.
Related Issues (20)
- unique overload for CircularBuffer method 'Enqueue' could not be determined HOT 6
- Circular buffer does not enque arrays properly
- RandomAccessList is not serializable.
- Add LazyList.consLazy HOT 1
- Add static members for F#+ generic operators HOT 1
- Potential net45 support
- AppVeyor builds are not shown as PRs checks. HOT 5
- Travis build sometimes fails on downloading deps via Paket. HOT 3
- Namespaces used by the package and the approach to extending types already present in core lib are not consistent across the package.
- Align Collection Module functions with FSharp.Collections
- Is FSharp.Core >= 4.3.4 still desirable/necessary? HOT 4
- Add conversion of enum value to its string name HOT 1
- Fable compatibility HOT 6
- build fails, need to update FSharp.Formatting HOT 4
- Heap.Tail slow
- Fill gap of functions between `List` and `NonEmptyList`
- Can't use pre-release nuget packages? HOT 10
- Include source files in the Nuget package HOT 5
- Welcome gdziadkiewicz as co-maintainer! HOT 5
- Code style guidance for new structure HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fsharpx.collections.