Add IsSumType

[michaelpj]

I found myself wanting this, and it seems like an obvious complement to the tools already in this library. I'm not all that good with generics-sop yet, so quite possibly this has a nicer implementation!

The test might also be problematic, since it uses DerivingVia (but illustrates the usecase I have for this). I don't know whether the test suite runs on versions of GHC from before DerivingVia.

[michaelpj]

Ah well, that answers my question about the CI. I could stick it in some CPP, I guess.

[kosmikus]

Interesting, thanks. Yes, I think this would be useful to have.

[kosmikus]

I'd much rather have the conversion functions be applications of trans_NS.

This is simple enough for sumTypeFrom:

sumTypeFrom :: IsSumType a xs => a -> NS I xs
sumTypeFrom = to . SOP . trans_NS (Proxy :: Proxy IsSingletonOf) (:* Nil)

However, we need the flipped constraint for sumTypeTo:

sumTypeTo = trans_NS (Proxy :: Proxy (Flip IsSingletonOf)) hd . unSOP . from

This requires the obvious class/instance definition of Flip, but also means we have to add AllZip (Flip IsSingletonOf) (Code a) xs to the constraints for IsSumType.

This is a general annoyance with trans_NP and AllZip, the GHC cannot prove one constraint from the other. There are different options here:

• add a version of AllZip that expands to both directions,
• add a variant rtrans_* to the trans_* family of functions which works on the reversed constraint,
• use explicit dictionary manipulation to turn one constraint into the other.

I'm not sure what's best.

[michaelpj]

I haven't forgotten about this, but it'll take me a while to try either of those, and I certainly don't feel like I have the judgement to say which of your suggested alternatives is better.

[michaelpj]

I found myself wanting this PR again. I know that the conversion functions don't work the way you'd like, but I wonder if you'd consider accepting the suboptimal version anyway, since it seems like it's not obvious how to make it nicer.

[michaelpj]

In case it's motivating: in this case the usecase is someone adding structured logging to HLS, where there is a lot of "this log type is the sum of the log types for all the sub-components, and now I'm going to write a bunch of tedious type class instances that just delegate to each individual type", i.e. exactly the kind of boilerplate that this lets us avoid.