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

Arbitrary instances for fixed-length vectors? #72

Open
kozross opened this issue Feb 22, 2019 · 5 comments
Open

Arbitrary instances for fixed-length vectors? #72

kozross opened this issue Feb 22, 2019 · 5 comments

Comments

@kozross
Copy link
Collaborator

kozross commented Feb 22, 2019

Given that a fixed-length vector's size is... well, fixed, it makes Arbitrary instances very easy. This would also assist me greatly with writing QuickCheck tests for vector-sized-extra, which I'd like to do before it hits Hackage.

However, this will involve dragging QuickCheck in as a dependency, and I'm not sure if this is something we want. So, in short, is it?

@mstksg
Copy link
Collaborator

mstksg commented Feb 25, 2019

I'm going to defer to @expipiplus1 here, I think. But I'm somewhat slightly opposed to adding new deps that might incur other transient dependencies.

For what it's worth, test suites are usually implemented by applications and standalone test executables, which negates most of the downsides of orphan instances. (The problems mostly arise if library code ever imports a module with orphans) So having this functionality as an orphan instance lib (or also as an orphan instance defined every time someone wants to test it) wouldn't be too bad, considering that the instance is relatively simple to write; it's just:

arbitrary = replicateM arbitrary
shrink = mapM shrink

and any test suite or application that needs it can just drop those two lines (plus the instance ... where) and not have to worry about anything else. People would just need to take care that the instances are never imported in their library modules.

@kozross
Copy link
Collaborator Author

kozross commented Mar 6, 2019

@mstksg Yeah, I think I agree. Based on what you've said, I'll close this issue (and not attempt to PR this), unless @expipiplus1 indicates otherwise by reopening.

@kozross kozross closed this as completed Mar 6, 2019
@turion
Copy link

turion commented Mar 10, 2022

But I'm somewhat slightly opposed to adding new deps that might incur other transient dependencies.

Can we reopen? I think this would make a lot of sense to add this, guarded by a cabal flag. That way, there are no new dependencies by default, but people can easily get the instances without incurring orphan instances.

@kozross
Copy link
Collaborator Author

kozross commented Mar 10, 2022

@turion I think that could be OK. I wouldn't mind implementing that functionality, as long as @expipiplus1 OK's it.

@expipiplus1
Copy link
Owner

Yeah, definitely uncontroversial under a flag. How I wish Haskell had a better solution for this problem...

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

No branches or pull requests

4 participants