Add a Distributive instance for Solo

[RyanGlScott]

Inspired by a similar patch on the main branch from #65.

Fixes #67.

[treeowl]

I ... guess? It's really awkward though.

distribute :: Functor f => f (Solo a) -> Solo (f a)

The only way to implement this is

distribute = Solo . fmap getSolo

fmap getSolo is a troubling concept when considering how Solo is used. It's not that the instance is wrong (it's not), but it's just really hard to think of a legitimate use for it.

[phadej]

@treeowl I'm confused, you wrote #65? Isn't that needed after all? One needs this instances to write current Representable Solo instance (in adjunctions).

[treeowl]

@treeowl I'm confused, you wrote #65? Isn't that needed after all? One needs this instances to write current Representable Solo instance (in adjunctions).

I don't remember. I hope I too am allowed to be of two minds, change my mind, and learn over time.

[phadej]

I don't remember. I hope I too am allowed to be of two minds, change my mind, and learn over time.

Sure. That's why a nitpick on many changes for the motivation or the reasoning is there, so it's possible to remember.

The motivation here is to allow writing instance Representable Solo. To be fair, you added that instance in #65, not Distributive Solo, as Distributive is gone from the main of distributive. I hope it's easier to think for legitimate use of Representable Solo.

[treeowl]

Representable Solo seems equally problematic to me. Then again, one could argue the same problems occur for any sort of "vector-like" type, so why make a fuss about this one? Sigh.

[phadej]

Then again, one could argue the same problems occur for any sort of "vector-like" type,

So Representable V2 from linear is problematic. How? Or is it fine because it has bangs? Please explain.

[treeowl]

It's all contextual, isn't it? Any Functor with strict fields in its parameter's type is automatically problematic because it doesn't strictly obey the functor laws. However, a Representable instance for a functor with lazy fields should generally be used for lazy memoization and not just filling in values; it can leak for the latter purpose. Maybe there's some missing abstraction for "things that can be filled eagerly"? That could have a method like

tabulateNow :: (Rep f -> Solo a) -> f a

but I have no idea if reasonable laws could be formulated for such a thing.

[phadej]

Are you saying that Representable shouldn't be used for "parallel computing" like in APLicative Programming with
Naperian Functors, or if it does then the functors should have strict fields?

It feels I lack a lot of background knowledge, so I guess I should not comment more.

@RyanGlScott you may drop this instance, and apparently the one in main as well. Especially if you understand what David is talking about and agree.

[treeowl]

@phadej , @RyanGlScott , I want to be very clear that I'm not saying the instance shouldn't be added. I'm just saying I have misgivings about it.

[RyanGlScott]

I don't have strong feelings about this at all—I was merely submitting this to achieve parity with the main branch. If you have misgivings about the instance, I'd be happy to remove it from the main branch.

[aaronvargo]

I think #69 (which I've created in the context of the main branch, but also applies to the released one) may be what's bothering @treeowl, though I'm not sure