Add genericArbitrary and genericCoarbitrary

[LiamGoodacre]

Someone in IRC was asking about these a little while ago, I thought it was a good idea to have them. Thoughts?

[paf31]

Looks great, although one possible downside is that this might make it difficult to remove (Co)Arbitrary later.

[LiamGoodacre]

Oh are there plans to remove these classes?

[paf31]

It's been brought up in the past. Like IsForeign, the issue is that there is rarely a single canonical implementation for a given type.

Generic deriving picks a default implementation for each type, which I think is fine, but we need a class which we can use to implement it.

So I'm not sure what the best solution is yet. One option could be to only use (Co)Arbitrary for deriving purposes, and I'd be fine with that, but it would need to be documented.

[paf31]

One slight problem here is that this will not be evenly distributed if there are more than two constructors. The first would get chosen with 50% probability.

[LiamGoodacre]

Ooh, yes, interesting.

[paf31]

I think if we can fix this, we should merge this. Whether we decide to remove Arbitrary or not later, we'll need to keep some class to support generic deriving anyway.

[LiamGoodacre]

I have an idea for solving this which I'm about to try now. Do we have the same problem with coarbitrary for product types?

[LiamGoodacre]

Sum never nests on the left, yeah? and would only ever contain Constructor?

[paf31]

Looks great, thanks!

[LiamGoodacre]

@paf31 will we need to do anything similar for any of the coarbitrary instances?

[paf31]

I don't think that's as big of a concern, as long as the generator gets perturbed somehow. But we could add it to the list of TODO items for later, perhaps.

[paf31]

Since this adds a new dependency, I've marked it as breaking, and I think we should merge it in the next major release.

[paf31]

This is only breaking because of the new dependency, which we've now decided is not breaking, so could you please rebase this one, and I'll release it? Thanks!

[garyb]

Aren't we avoiding dependencies on either of the generics in the core libraries until there's a clear winner?

[paf31]

My strong preference would be to deprecate generics in favor of generics-rep at this point.

[LiamGoodacre]

Rebased and updated.

[paf31]

@garyb Do you think there is a reason to keep generics around? I'm fairly sure the only benefit generics has is that you can reify a Generic instance more easily from a data structure without some sort of constraint kind trickery. However, I've never seen anyone use that technique, and it's very cumbersome to do so. I closed my PR which implemented it.

I also have a PR open which defines and derives a class like the old Generic using the new Generic. It might be possible to add the reifySignature function there instead, which would answer this nicely.

Anyway, I suggest we merge this, since I think it could be very useful. What do you think?

[garyb]

Do you think there is a reason to keep generics around?

I'm maybe not the right person to ask, since I don't use either variety of generics for anything concrete; I've written a few instances for old-style and not touched new-style at all even. 😕

Given my indifference, I'm all for just choosing one at this point and deprecating the other, it's less confusing for everyone that way. 😄

[paf31]

Ok, in that case I'm going to merge this then, and we can try to make a plan for deprecating generics or merging generics-rep in at some point.

[paf31]

Thanks @LiamGoodacre!