Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve generic1Laws #59

Open
chessai opened this issue Oct 2, 2018 · 0 comments
Open

improve generic1Laws #59

chessai opened this issue Oct 2, 2018 · 0 comments

Comments

@chessai
Copy link
Collaborator

chessai commented Oct 2, 2018

@andrewthad from PR #58:

For the most part, this [PR] looks good. Currently, generic1Laws will be exceeding unpleasant to use since it requires (Eq1 (Rep1 f), Show1 (Rep1 f), Arbitrary1 (Rep1 f)). I think that in this case, for the sake of usability, it is probably better to just nail down the type to something like Bool or Integer:

generic1Laws :: (Generic1 f, Eq (f Bool), Arbitrary (f Bool), Show (f Bool), Eq (Rep1 f Bool), Show (Rep1 f Bool), Arbitrary (Rep1 f Bool)) => proxy f -> Laws

As much as I hate FlexibleContexts, the only other option here would be to add Eq1 and Show1 instances to all the generics machinery in base and then to get Arbitrary1 instances for all the same types added to QuickCheck. This would take a while.

Actually, there's another way that involves replicating all the generics machinery and then writing a type family to marshal from the types in GHC.Generics to the copies of the types in this library. Then, we could have our instances. But this would be miserable.
If this [PR] builds, I think I may go ahead and merge this, and then Generic1's laws function could be worked out on a separate PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant