Replace these with data-or

[fosskers]

Hi! I'm one of the maintainers of original non-empty-containers, and I'm very impressed with the breadth of your library's API. non-empty-containers should most likely be deprecated in favour of this.

I recently needed partition behaviour for a non-empty Set, and noticed that that exact function exists here. So I pulled the dependency, and to my surprise, lens started being compiled as a dep. Surprised, I looked deeper, and noticed that these pulls in a vast web of dependencies, too many for the project I'm working on. I noticed also that these advertises the data-or library as a light-weight alternative.

So, this PR replaces usage of these in this library with data-or. You use the These type strictly for its constructor behaviour, not for any of the fanciness that its library's large dependency graph offers, so this was a straight-forward change.

Here is the dependency graph of nonempty-containers with these:

... and here it is with data-or:

Hopefully you find this useful.

[mstksg]

Thank you for the sizable contribution! :)

I am also unhappy with all of lens being pulled in, and I too consider this to be pretty excessive. data-or seems to be a good substitute.

One potential downside to data-or over these is that Or does not have a Semigroup instance, which is pretty central to the design/usage of this library. But users who need an Semigroup instance will be able to define either an orphan instance, or a newtype wrapper with a Semigroup instance, or even pull in these if they don't care about the lens dependency.

Overall, LGTM. Thank you so much again, I really appreciate it!

[fosskers]

Thanks for the merge!

My own concern was that data-or hasn't been updated in a while. Perhaps we could patch it as well, or barring that, try to convince the these author to create a these-core that exposes only the core data type and none of the fanciness, and then have nonempty-containers move back to that. these also has more "market share" in general.

[fosskers]

Thanks also for the quick Hackage release. I'll be using this right away.

[mstksg]

I don't think, from an end-user standpoint, the choice of data-or or these should be of major consequence, since it's simple enough to write a one-off converter, I feel. It would be nice (but not particularly urgent, though) if data-or had Semigroup, Bifunctor, Functor, Traversable, MonadChronicle, etc. instances, though, and it probably would be worth sending over a PR at some point eventually maybe :)