Split the library ?

[gusty]

I'm normally not in favor of splitting the library.

This library was split before, with FsControl being the core but at that time the design was a bit different, as there was the intention to present a way to the user to create its own polymorphic functions (similar to typeclasses but with a single method) with less syntax.

Still, from time to time people say that it would be nice to split out some functionality and I would like to hear more voices and specially, reasons why this is a good idea.

One advantage of having everything together is that it simplifies a lot the release process, making sure nothing breaks.

If we had different libraries, it would be way more complicated as we would have to make sure that version x of library A works with version y of library B.

[wallymathieu]

I'm unsure about it. I think it makes sense to keep things together in F#+. Having fewer deliverables simplifies things.

[cartermp]

Is there a part of the library that's super useful and independent of everything else? Might be worth it, but at the same time it's a big cost to expect users of that component to install a separate package.

[wallymathieu]

Yes, there isn't any big parts that have dependency on anything other than F# Core lib and type provider (in v2).

[gusty]

What would a split F#+ looks like?

I can think of:

• Extensions: the basic extensions for core types, this will be almost 100% Fable 2 compatible.
• Generic: all generic functions and operators, plus .Data, .Math, CEs and polyvariadic utilities like tuple and scanf related functions.
• Lenses
• Type Level: Including our type safe Vector and Array types.

Some stuff is tricky to split, for instance .Control and .Data now are a bit dependent as the recently added NonEmptySeq is an interface and needs to be declared before .Control as it can't have static methods. Unless until @dsyme implements the ext functionality (maybe for V2 it is already implemented, who knows).

[gusty]

UPDATE: with upcoming F# 8 supporting static members in interfaces, there won't be interdependency between .Control and .Data anymore, which means we're one step closer to achieve this separation.

[cmeeren]

Personally I prefer a single library for simplicity. Regarding extensions, I'm comfortable with having to open FSharpPlus.Extensions even if I have already opened FSharpPlus.