Perhaps use Void from Data.Void?

[dalaing]

There is a Void in base now, and if generics-eot used this it would make interoperability with other things that use Void easier. I'm mostly thinking of the Decidable typeclass from the contravariant package here.

I'm happy to do this in a PR, just thought I'd check and see if it was a welcome change first.

[soenkehahn]

I like the idea. Currently generics-eot supports ghc-7.10.2 (that's also the default stack file and tested on CI). Would we have to drop support for that compiler version?

[dalaing]

I think I could probably do it by depending on the void package, which provided the functionality before it was folded into base and now has the appropriate CPP in it to handle different GHC versions.

I can have a go at this on Monday.

[soenkehahn]

@dalaing: That sounds good. Thanks for looking into this.

This package was developed with TDD so far and I'd like to keep it that way. This issue is a bit weird in that way, because it just swaps out one implementation of Void for another. But you do have a usecase in mind, which is being able to use Decidable. So maybe you can add a test-case for that, e.g. it 'allows to use contravariant's Decidable with Void' $ do .... Or something like that. Let me know if you need help with that.

[dalaing]

I've got something I can use as a test for this here, so that shouldn't be a problem.

There's a comment in there that hints at the next thing I'm likely to play with on this front, which would involving nesting the tuples and eithers to the left rather than to the right, in order to be able to build left associative operators for Divisible / Decidable similar to <*> and <|>. I might play around with that for a while before it becomes a legitimate suggestion though :)

[dalaing]

Actually, that test would be pretty large and what bring in a dependency on contravariant - are you sure you want that? If so, I'm happy to add it - it partly comes from the contravariant docs, but it looks like that is under the same license as generics-eot and so is likely to be a non-issue.

I'm not quite sure what kind of smaller test is appropriate, but the hspec string would probably be something like is 'compatible with Void in the haskell ecosystem' :)

[soenkehahn]

Ideally we would have the smallest possible test-case that forces us to use the new Void -- while still illustrating why that is a relevant use-case. So a boiled down version of something from the contravariant module you linked to might work -- although I confess I haven't looked at it much and don't fully understand what it'd be useful for. But I also think that we might be able to come up with an example that relies on Data.Void.absurd that is smaller and simpler.

For example you could try to implement generic instances for Hashable and then have

instance GHashable Void where
  gHashWithSalt salt void = Data.Void.absurd void

Would that work?

Apart from that I wouldn't mind the additional dependency on contravariant, since that's only for the test-suite.

[soenkehahn]

Oh, and I like your hspec test string. :)

[dalaing]

If you don't mind the extra dependency, then I'll probably go for that, since it'll keep things relatively simple.

[soenkehahn]

Done in #12.

[soenkehahn]

@dalaing: Released to hackage as 0.3.