[Feature]: concat function

[gusty]

Background and motivation

A generalization of F# collection's concat function.
Here's a possible generic definition let inline concat x = bind (toSeq >> ofSeq) x.

But we have to define its expected behaviour with different types, and what are the constraints for the input types.
For instance, the above definition would require 'M<'F<'T>> when M should be a monad (support for >>=) and F a foldable (support for toSeq) but it also should be a Collection (support for ofSeq).

Tricky types are options, dictionaries. For instance a dictionary of options won't work with the above definition.

Alternative Concerns

What is the expectation forL

• concat (dict [ (1, [1;2;3]); (3, [6;7;8]) ])
• concat (Some [1; 3])

Are you willing help with a pull-request?

Maybe

[gusty]

A possible specification would be a function equivalent to:

let concat x = x |>> map result |>> sum |> join which could be further simplified to

let concat x = x >>= (map result >> sum)

With this definition the above questions result in:

• concat (dict [ (1, [1;2;3]); (3, [6;7;8]) ]) = dict [(1, 6); (3, 700)]
• concat (Some [1; 3]) = Some 4

which is kind of what makes more sense in my mind

If you think about it, this function is like a generic choose id:

• concat [Some 1; None; Some 3] = [1; 3]
• concat (dict [1, Some 100; 2, None; 3, Some 300]) = dict [(1, 100); (3, 300)]
• concat dict [1, Ok 100; 2, Error "No"; 3, Ok 300])= dict [1, Ok 100; 2, Error "No"; 3, Ok 300])

and if we create a concatBy counterpart, it will generalize both choose and collect, which makes it kind of interesting.

But what is really interesting about this function, is that in order to make it work (at least over the mentioned examples) it needs to add/fix lot of things in the library, like:

• folds for all types, including Result, and Map-likes operating only on the element (not KeyValuePairs).
• join for some missing types like IDictionary<_,_>
• empty for Map-likes fixed
• empty for Results
• last but not least, it should be able to deal with (at least internally) infinite dictionaries. Because of the result function. Either that, or have some specific overloads for them as in the end the internally generated infinite dictionaries collapse, but not sure if will type check in this case as there would be no overload for Return.

Conclusion: it would be desirable to implement, at least privately in principle, the above proposed function and write tests, in order to enforce consistency across the whole library.