FSharpPlus
FSharpPlus copied to clipboard
fsprojects
Collection types
This is a long standing design issue, however it doesn't seem to have any impact in usability, but the real impact seems to be that it's a bit confusing how to organize the source code.
The question arise on how can we unify List, Array, Seq and so on.
Foldable concentrates most operations but not all of them, for example singleton is not a Foldable operation, it seems to be exactly the opposite of a Foldable.
Then we have some stuff that falls in the middle, typically operations that take a "CollectionX" as input, do something and return the same type of "CollectionX".
There is lot of confusion because normally these collection types are required to be Foldable, but that requirement is not enough, they must belong at the same time to another abstraction.
Collection and Unfoldable abstractions seems to provide an answer, here's an explanation from a Haskell implementation and here's a Purescript implementation of Unfoldable
Reflecting over this, we can conclude (among many other things) that placing Filter in Foldable.fs is simply wrong. Filter seems to be one of the only functions from Collection, which means that is a Foldable and an Unfoldable at the same time.
So I propose to start organizing our functions accordingly. Starting to move to Foldable everything that is specific to Foldable but doesn't require Unfoldable, and what doesn't fall there should be moved into Collection.fs for now (later we can decide to partition it into Unfoldable.fs and Collection.fs).
I have the feeling that ofSeq (ofList as well) belongs to Unfoldable, see also: http://hackage.haskell.org/package/unfoldable-0.9.6/docs/Data-Unfoldable.html
If my memory serves me right, it was moved to Foldable because intersperse (which requires foldable and monoid as showed in purescript implementation) had a generic default overload that use ofSeq but this is an optimization, not a requirement. An optimization for Unfoldables, now we would have to move it to Collection.fs because of this which is more a technical limitation.
